From ghc-devs at haskell.org Thu Sep 1 04:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 04:57:56 -0000 Subject: [GHC] #12491: ghc-iserv pattern match failure with no command line arguments In-Reply-To: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> References: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> Message-ID: <059.108664f6c5504cb5f163783d5ad9763f@haskell.org> #12491: ghc-iserv pattern match failure with no command line arguments -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | 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:D2494 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as aa6da1174b6f6f52aff9cae5a8492aa3cd0ecdb4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 04:58:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 04:58:24 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.e64eea6abdf95c7eb1788963f27a0f7e@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 7053019e7b04842dd7364039381d8c4c069489a2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 04:58:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 04:58:57 -0000 Subject: [GHC] #12206: No exposed API to get full text of ErrMsg In-Reply-To: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> References: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> Message-ID: <057.e0cefcee5b1fc4fb7f51ea243566f816@haskell.org> #12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHC API | 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:D2491 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 99bb8ffe85ab135b3928b790818c0d5bbbb747a4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 04:59:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 04:59:42 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.b76ce83975e6d1fd96545afb9b96b023@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 76286af5c621f032c4afab1f26b992e8ffa7f84d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 05:00:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 05:00:21 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.15db9987efb05abcc88b2c8a3febf2a8@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.11 checker) | 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: #9939, #9973, | Differential Rev(s): Phab:D2498 #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 49672659113371c3bee691e6d913df8e6f60a1d8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 05:03:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 05:03:53 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.281853717615e290822d09124eab9cb4@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 661d140a198d941e3a1eaec13fbf7bd4406fa3e5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 05:04:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 05:04:14 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.7901337ccaf2c7ff42f3d7765d758673@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: fixed | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 09:21:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 09:21:41 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.58607648f7e31ba75adb6b589a5f0ec9@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: #9557 | Differential Rev(s): Phab:D2502 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: D2502 => Phab:D2502 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 10:58:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 10:58:32 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.b2ca51dcf99122d120c3123f41d6cbea@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2473 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Given that it doesn't solve the whole problem, and the problem that it does solve needs `unsafeCoerce` to trigger it, I don't think we should merge it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 11:49:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 11:49:15 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.02b862a1819426b8ef8bdb8e7a40405e@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I think I added them in 8.0.2 because it was the next release in sight. mboes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 12:31:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 12:31:12 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.77358413f74b87ac8ebf64bee94fce77@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): This should affect the StaticPointers mostly. I don't think it is of high risk, but it is not risk-free either and we don't have an urgency to include it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 12:59:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 12:59:18 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.139f32a518384954e8f723612c89ede3@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | 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: #12000, #9878 | Differential Rev(s): Phab:D2504 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2504 Comment: I have the beginnings of an implementation of this in Phab:D2504. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 13:33:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:33:04 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.5cc45a40744c1ec0f019fe67b8a26cbe@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: #9557 | Differential Rev(s): Phab:D2502 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 13:35:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:35:51 -0000 Subject: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient In-Reply-To: <059.876fe881e6bc9b43ab179d4b6da29ec1@haskell.org> References: <059.876fe881e6bc9b43ab179d4b6da29ec1@haskell.org> Message-ID: <074.0cf6c4cf6ada5d3258ecafce81dd0224@haskell.org> #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient -------------------------------------+------------------------------------- Reporter: jcpetruzza@… | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: deriving-perf 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 Thu Sep 1 13:36:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:36:13 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.08b9ecb0800e0197a71961458b6de21b@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: #8731 #10858 | 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 Sep 1 13:37:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:37:11 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.77ecfd9d62d79f655e85e3cdceefc9c2@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 13:37:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:37:35 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.c6d23e34999334d84d933f08f94afdf8@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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): Phab:D1012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 13:37:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:37:49 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.959adc291de1cdb86ea4bfc49713cc90@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) 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 Thu Sep 1 13:38:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:38:10 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.ed5286005003a15a312d4cb78099d691@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 13:46:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 13:46:54 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.e5d33ebcc6f60bb2992ecfd9c642a3ce@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | 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: #12000, #9878 | Differential Rev(s): Phab:D2504 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One particularly hairy problem that arises here is that of breakpoint ticks interacting with FloatOut. Currently we disallow any floating through breakpoint ticks. However, static pointer support requires that we float out static expressions to the top level. I can see two options here, 1. Allow floating of `StaticPtr` values through breakpoints as a special case. 2. Disable breakpoint production while `-XStaticPointers` is enabled. Given that (1) may give rise to some rather surprising behavior in the face of recursive groups (e.g. a recursive group with one `StaticPtr` and a bunch of other bindings; the whole group will need to be floated, killing breakpoint support for all floated code), I suspect that (2) is the only sensible option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 14:02:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 14:02:12 -0000 Subject: [GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' In-Reply-To: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> References: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> Message-ID: <061.dc26df88a978734c158041a8bcc37694@haskell.org> #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: merge Priority: normal | 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): Phab:D2492 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` with aedb41292d042963ad281641f85c26e5c9ea4d4d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 14:03:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 14:03:27 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.2c310ef6c78df914cf4a0d58af07aa9b@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Oh dear, that boat may have already sailed as I just merged it in 062b462ba88a493fa12377a11960e8bed2f56781 ;) Simonmar, do you think think this warrants a revert or should we just leave it be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 14:48:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 14:48:32 -0000 Subject: [GHC] #12559: Don't ignore addTopDecls in addModFinalizer Message-ID: <056.d891faa710239ad090c2d102b89973c3@haskell.org> #12559: Don't ignore addTopDecls in addModFinalizer -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: template- | Operating System: Unknown/Multiple haskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11832 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program fails to compile because `f` is not found. {{{ -- main.hs import M main = print (f 0) }}} {{{ -- M.hs {-# LANGUAGE TemplateHaskell #-} module M where import Language.Haskell.TH.Syntax g :: IO () g = $(do addModFinalizer (do d <- [d| f x = (2 :: Int) |]; addTopDecls d) [| return ()|] ) }}} {{{ $ runghc main.hs main.hs:3:15: Not in scope: ‘f’ }}} This bug is problematic to produce top-level declarations which depend on the output of `reify` for local variables, which can only run in `addModFinalizer`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 14:55:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 14:55:45 -0000 Subject: [GHC] #12559: Don't ignore addTopDecls in addModFinalizer In-Reply-To: <056.d891faa710239ad090c2d102b89973c3@haskell.org> References: <056.d891faa710239ad090c2d102b89973c3@haskell.org> Message-ID: <071.6d85f789cb7acc8827f9dc78a9f97f63@haskell.org> #12559: Don't ignore addTopDecls in addModFinalizer -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template- | haskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11832 | Differential Rev(s): Phab:D2505 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D2505 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 15:42:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 15:42:31 -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.9dea0b2148846a70d38e9234e3f8473e@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Thank you for your detailed response! I can't think of a better way of handling things, so I'm fine with just making it a bit more clear in the documentation. I didn't make the leap from understanding how shadowing is handled to how it impacts the expected order of `-package-db` flags. I shall make the test case not `expect_broken`, but expect the current behaviour. I believe it's useful to keep it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 16:08:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 16:08:32 -0000 Subject: [GHC] #12559: Don't ignore addTopDecls in module finalizers (was: Don't ignore addTopDecls in addModFinalizer) In-Reply-To: <056.d891faa710239ad090c2d102b89973c3@haskell.org> References: <056.d891faa710239ad090c2d102b89973c3@haskell.org> Message-ID: <071.f755590e31252d70d090ef565ef85042@haskell.org> #12559: Don't ignore addTopDecls in module finalizers -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template- | haskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11832 | Differential Rev(s): Phab:D2505 Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -29,2 +29,2 @@ - the output of `reify` for local variables, which can only run in - `addModFinalizer`. + the output of `reify` for local variables, which can only run in a + finalizer. New description: The following program fails to compile because `f` is not found. {{{ -- main.hs import M main = print (f 0) }}} {{{ -- M.hs {-# LANGUAGE TemplateHaskell #-} module M where import Language.Haskell.TH.Syntax g :: IO () g = $(do addModFinalizer (do d <- [d| f x = (2 :: Int) |]; addTopDecls d) [| return ()|] ) }}} {{{ $ runghc main.hs main.hs:3:15: Not in scope: ‘f’ }}} This bug is problematic to produce top-level declarations which depend on the output of `reify` for local variables, which can only run in a finalizer. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 16:25:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 16:25:20 -0000 Subject: [GHC] #12476: Error building HList In-Reply-To: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> References: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> Message-ID: <070.929d9aced5a363fabc7c61787e6248d1@haskell.org> #12476: Error building HList -------------------------------------+------------------------------------- Reporter: DanielWaterworth | Owner: Type: bug | Status: infoneeded Priority: normal | 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 => infoneeded Comment: Well, this doesn't quite compile yet but then again it also doesn't compile with 7.10. DanielWaterworth, can you confirm that this is expected? {{{ Data/HList/Dredge.hs:78:27: error: • Ambiguous type variables ‘x1’, ‘k1’, ‘l1’ arising from a use of ‘dredge’ prevents the constraint ‘(EnsureLabel x1 (Label l1))’ from being solved. Relevant bindings include label :: x1 (bound at Data/HList/Dredge.hs:78:9) dredge' :: x1 -> p1 a1 (f1 a1) -> p1 s1 (f1 s1) (bound at Data/HList/Dredge.hs:78:1) Probable fix: use a type annotation to specify what ‘x1’, ‘k1’, ‘l1’ should be. These potential instances exist: instance forall k (x :: k). EnsureLabel (Label x) (Label x) -- Defined at Data/HList/Labelable.hs:204:10 instance forall k (x :: k). EnsureLabel (Proxy x) (Label x) -- Defined at Data/HList/Labelable.hs:207:10 ...plus one instance involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘isSimple’, namely ‘(dredge label)’ In the expression: isSimple (dredge label) In an equation for ‘dredge'’: dredge' label = isSimple (dredge label) Data/HList/Dredge.hs:90:29: error: • Ambiguous type variables ‘x0’, ‘k0’, ‘l0’ arising from a use of ‘dredgeND’ prevents the constraint ‘(EnsureLabel x0 (Label l0))’ from being solved. Relevant bindings include label :: x0 (bound at Data/HList/Dredge.hs:90:11) dredgeND' :: x0 -> p0 a0 (f0 a0) -> p0 s0 (f0 s0) (bound at Data/HList/Dredge.hs:90:1) Probable fix: use a type annotation to specify what ‘x0’, ‘k0’, ‘l0’ should be. These potential instances exist: instance forall k (x :: k). EnsureLabel (Label x) (Label x) -- Defined at Data/HList/Labelable.hs:204:10 instance forall k (x :: k). EnsureLabel (Proxy x) (Label x) -- Defined at Data/HList/Labelable.hs:207:10 ...plus one instance involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘isSimple’, namely ‘(dredgeND label)’ In the expression: isSimple (dredgeND label) In an equation for ‘dredgeND'’: dredgeND' label = isSimple (dredgeND label) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 16:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 16:26:15 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.6fece4b0c562676694fe5674e98bb8b0@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: merge Priority: normal | 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): Phab:D2499 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 17:09:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 17:09:26 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.b52ffe528b2f3ad03daf43a215976926@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"a48de37dcca98e7d477040b0ed298bcd1b3ab303/ghc" a48de37/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a48de37dcca98e7d477040b0ed298bcd1b3ab303" restore -fmax-worker-args handling (Trac #11565) maxWorkerArgs handling was accidentally lost 3 years ago in a major update of demand analysis commit 0831a12ea2fc73c33652eeec1adc79fa19700578 Old regression is noticeable as: - code bloat (requires stack reshuffling) - compilation slowdown (more code to optimise/generate) - and increased heap usage (DynFlags unboxing/reboxing?) On a simple compile benchmark this change causes heap allocation drop from 70G don to 67G (ghc perf build). Signed-off-by: Sergei Trofimovich Reviewers: simonpj, ezyang, goldfire, austin, bgamari Reviewed By: simonpj, ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2503 GHC Trac Issues: #11565 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 17:13:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 17:13:47 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.1597254fb5549b3a3f8fce4c9353b715@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => closed * failure: None/Unknown => Runtime performance bug * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 18:13:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 18:13:21 -0000 Subject: [GHC] #12443: DEFAULT_TMPDIR is documented, but doesn't exist In-Reply-To: <047.edde35b3f67cb5f9ea6388079fa88a02@haskell.org> References: <047.edde35b3f67cb5f9ea6388079fa88a02@haskell.org> Message-ID: <062.fabaf4a1cff339790b1b26d5ec35c852@haskell.org> #12443: DEFAULT_TMPDIR is documented, but doesn't exist -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 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:D2493 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1e39c29ab55b9df83df142ad50e7a79e22f47f9e/ghc" 1e39c29/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e39c29ab55b9df83df142ad50e7a79e22f47f9e" Kill vestiages of DEFAULT_TMPDIR It was removed long ago in cf403b50900648063d99afa160d2091a7d6f58c1. Thanks for @rwbarton for catching this. Updates nofib submodule. Test Plan: Validate Reviewers: austin, rwbarton Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2493 GHC Trac Issues: #12443 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 18:25:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 18:25:48 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.c83efe0c553d69e8ac2a286dc47000b8@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: merge Priority: normal | 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): Phab:D2499 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 44755a0cbcb77aea1c28aeba994a4514aec87904. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 18:25:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 18:25:53 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.5eafaf7d7e8a339f562debaecf65fad8@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2499 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 18:29:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 18:29:48 -0000 Subject: =?utf-8?b?W0dIQ10gIzEyNTYwOiDigJg6aW5mbyBUWVBF4oCZIG1lbnRpb25z?= =?utf-8?q?_any_instance_that_includes_=E2=80=98Type=E2=80=99?= Message-ID: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> #12560: ‘:info TYPE’ mentions any instance that includes ‘Type’ -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Unexpected behaviour {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :i TYPE type role TYPE nominal data TYPE (t1 :: RuntimeRep) -- Defined in ‘GHC.Prim’ }}} Importing `Data.Proxy` gives me some of its instances, {{{ Prelude GHC.Types> import Data.Proxy Prelude GHC.Types Data.Proxy> :i TYPE type role TYPE nominal data TYPE (t1 :: RuntimeRep) -- Defined in ‘GHC.Prim’ instance Monad Proxy -- Defined in ‘Data.Proxy’ instance Functor Proxy -- Defined in ‘Data.Proxy’ instance Applicative Proxy -- Defined in ‘Data.Proxy’ instance Foldable Proxy -- Defined in ‘Data.Foldable’ instance Traversable Proxy -- Defined in ‘Data.Traversable’ Prelude GHC.Types Data.Proxy> }}} because they mention `*` {{{ Prelude GHC.Types Data.Proxy> :set -fprint-explicit-kinds Prelude GHC.Types Data.Proxy> :i TYPE type role TYPE nominal data TYPE (t1 :: RuntimeRep) -- Defined in ‘GHC.Prim’ instance Monad (Proxy *) -- Defined in ‘Data.Proxy’ instance Functor (Proxy *) -- Defined in ‘Data.Proxy’ instance Applicative (Proxy *) -- Defined in ‘Data.Proxy’ instance Foldable (Proxy *) -- Defined in ‘Data.Foldable’ instance Traversable (Proxy *) -- Defined in ‘Data.Traversable’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 18:32:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 18:32:05 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.5b3b944a9f0ec1b80979ac5568c45274@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rename/should_compile/T12533 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The trouble with merging comment:3 is that it requires d2958bd08a049b61941f078e51809c7e63bc3354, which fixes #12220 but which we were thinking on not merging as it causes #12466. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 18:59:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 18:59:26 -0000 Subject: [GHC] #4239: -ddump-minimal-imports vs. type operators In-Reply-To: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> References: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> Message-ID: <061.746418782ae6dc1128ef121eeb0150ba@haskell.org> #4239: -ddump-minimal-imports vs. type operators -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4239 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2480 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8d35e18d885e60f998a9dddb6db19762fe4c6d92/ghc" 8d35e18/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d35e18d885e60f998a9dddb6db19762fe4c6d92" Fix startsVarSym and refactor operator predicates (fixes #4239) startsVarSym used isSymbol which does not recognize valid operators beginning with OtherPunctuation generalCategory (e. g. (·)). Move it to ghc-boot-th for reducing duplication. This patch fixes template-haskell pretty printer, which is used by -ddump-minimal-imports. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2480 GHC Trac Issues: #4239 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:05:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:05:43 -0000 Subject: [GHC] #4239: -ddump-minimal-imports vs. type operators In-Reply-To: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> References: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> Message-ID: <061.e21b4472e23ed6427e5385dc994e6a85@haskell.org> #4239: -ddump-minimal-imports vs. type operators -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4239 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2480 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f233f00b1915ac6c0a200b8017a9f07deefd401e/ghc" f233f00/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f233f00b1915ac6c0a200b8017a9f07deefd401e" Fix startsVarSym and refactor operator predicates (fixes #4239) startsVarSym used isSymbol which does not recognize valid operators beginning with OtherPunctuation generalCategory (e. g. (·)). Move it to ghc-boot-th for reducing duplication. This patch fixes template-haskell pretty printer, which is used by -ddump-minimal-imports. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2480 GHC Trac Issues: #4239 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:05:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:05:43 -0000 Subject: [GHC] #4239: -ddump-minimal-imports vs. type operators In-Reply-To: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> References: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> Message-ID: <061.27b8f58ced9f7bd665e5bdfda64f8c75@haskell.org> #4239: -ddump-minimal-imports vs. type operators -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4239 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2480 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b946cf3f5d6fd273a79b008472e8cb0ad1432be1/ghc" b946cf3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b946cf3f5d6fd273a79b008472e8cb0ad1432be1" Revert "Fix startsVarSym and refactor operator predicates (fixes #4239)" This reverts commit 8d35e18d885e60f998a9dddb6db19762fe4c6d92. arc butchered the authorship on this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:11:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:11:14 -0000 Subject: [GHC] #4239: -ddump-minimal-imports vs. type operators In-Reply-To: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> References: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> Message-ID: <061.ae29187e6c6aa530fe2759f2dfe6f676@haskell.org> #4239: -ddump-minimal-imports vs. type operators -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4239 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2480 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks Malo! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:14:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:14:02 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.34e12d7492a660c3b747054e432259d2@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: None | Version: 8.0.1 Resolution: fixed | Keywords: runghc 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 * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` with d7cb24d1c482bffd8ba509b7e364dc8e40bc14d7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:18:57 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.dea342c82d20deb382108dc3d84f645e@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Let's punt on it in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:28:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:28:10 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.65b8f4fea50b834e892b13ea2427df30@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): Huh, I think the title of this issue was actually too narrow. We need the same barrier on array writes as well as MutVar writes, don't we? Re-open? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:28:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:28:48 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM (was: Memory fence on writeIORef missing on ARM) In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.7c08635fd3ed98d23f7e1a8112375aac@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:39:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:39:41 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.add5b962206217e43df96b492ca131ec@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc 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 harendra): * status: closed => new * owner: harendra => * resolution: fixed => Comment: I wrongly attached that commit with this bug. I am reopening it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 19:40:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 19:40:44 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.d0d0ac256fb618a6d0a953563b13261f@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc 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 harendra): * owner: => harendra -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 20:27:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 20:27:53 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.0722c24ce29fc3632f737629730607b9@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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 dfeuer): Replying to [comment:26 simonpj]: > I agree with your reasoning, but it's quite painful to implement the positive/negative distinction (given the way the constraint solver works). Anything is possible, but this all seems a bit exotic, so I'm inclined to look for a simple solution. > > I think it would be simple to: > > * Not complain about inaccessible code in instance methods > > Would that do? That doesn't seem likely to solve the problem in general, and leads to an odd inconsistency. Unfortunately, I don't know enough about type checking to understand the problem with the positive/negative approach. If you can't make that work, I would personally prefer dialing back the inaccessible code error to a warning and being stingier about emitting it. Having to manually defer GHC's checking using `Dict` and such always struck me as unnatural and potentially fragile. If I state ex falso, I'm usually doing it on purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 20:31:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 20:31:56 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.e2d11f734ff99c903cd35cc08ba3f010@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12497 | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/ghc" e5ecb20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0" Added support for deprecated POSIX functions on Windows. Summary: With the introduction of 8.0.1 We've stopped supporting in GHCi the use of POSIX functions under their deprecated names on Windows. This to be compatible with object and libraries from the most popular compilers on the platform (Microsoft and Intel compilers). However this brings a confusing disparity between the compiled and interpreted behavior since MingW-W64 does support the deprecated names. Also It seems clear that package writers won't update their packages to properly support Windows. As such I have added redirects in the RTS for the deprecated functions as listed on https://msdn.microsoft.com/en-us/library/ms235384.aspx. This won't export the functions (as in, they won't be in the symbol table of compiled code for the RTS.) but we inject them into the symbol table of the dynamic linker at startup. Test Plan: ./validate and make test TEST="ffi017 ffi021" Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd Reviewed By: simonmar, bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2500 GHC Trac Issues: #12209, #12497, #12496 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 20:31:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 20:31:56 -0000 Subject: [GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs In-Reply-To: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> References: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> Message-ID: <056.6d3b6e8c1e72b1a200829d7bacd7c6f7@haskell.org> #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs -------------------------------------+------------------------------------- Reporter: pl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/ghc" e5ecb20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0" Added support for deprecated POSIX functions on Windows. Summary: With the introduction of 8.0.1 We've stopped supporting in GHCi the use of POSIX functions under their deprecated names on Windows. This to be compatible with object and libraries from the most popular compilers on the platform (Microsoft and Intel compilers). However this brings a confusing disparity between the compiled and interpreted behavior since MingW-W64 does support the deprecated names. Also It seems clear that package writers won't update their packages to properly support Windows. As such I have added redirects in the RTS for the deprecated functions as listed on https://msdn.microsoft.com/en-us/library/ms235384.aspx. This won't export the functions (as in, they won't be in the symbol table of compiled code for the RTS.) but we inject them into the symbol table of the dynamic linker at startup. Test Plan: ./validate and make test TEST="ffi017 ffi021" Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd Reviewed By: simonmar, bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2500 GHC Trac Issues: #12209, #12497, #12496 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 20:31:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 20:31:56 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.63693044a412ad3ca4a171de560fc0ce@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12209 | Differential Rev(s): Phab:D2500 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/ghc" e5ecb20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0" Added support for deprecated POSIX functions on Windows. Summary: With the introduction of 8.0.1 We've stopped supporting in GHCi the use of POSIX functions under their deprecated names on Windows. This to be compatible with object and libraries from the most popular compilers on the platform (Microsoft and Intel compilers). However this brings a confusing disparity between the compiled and interpreted behavior since MingW-W64 does support the deprecated names. Also It seems clear that package writers won't update their packages to properly support Windows. As such I have added redirects in the RTS for the deprecated functions as listed on https://msdn.microsoft.com/en-us/library/ms235384.aspx. This won't export the functions (as in, they won't be in the symbol table of compiled code for the RTS.) but we inject them into the symbol table of the dynamic linker at startup. Test Plan: ./validate and make test TEST="ffi017 ffi021" Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd Reviewed By: simonmar, bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2500 GHC Trac Issues: #12209, #12497, #12496 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 20:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 20:33:54 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.9a73368848bb473613f978b3e1f5116f@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12209 | Differential Rev(s): Phab:D2500 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 20:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 20:41:05 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.6ac14c5197b183525609cd195c125eb0@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2473 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, let's leave it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 1 21:05:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Sep 2016 21:05:59 -0000 Subject: [GHC] #12193: Include target versions of unlit and hsc2hs when cross-compiling In-Reply-To: <047.70c7f34a854dd4d3e899f2d863451090@haskell.org> References: <047.70c7f34a854dd4d3e899f2d863451090@haskell.org> Message-ID: <062.1a8e877e739135987fb511945d184c7c@haskell.org> #12193: Include target versions of unlit and hsc2hs when cross-compiling -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: | Keywords: cross-compile 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 erikd): * keywords: => cross-compile * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 06:29:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 06:29:12 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.e52cacce41f8c7096a667e3c31a490c8@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => MacOS X * related: => #12198 Comment: Also reported as #12198. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 06:54:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 06:54:27 -0000 Subject: [GHC] #12555: bindist configure checks involving the compiler are broken In-Reply-To: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> References: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> Message-ID: <062.636c7dd556916823d1535b09592a4403@haskell.org> #12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new 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 thomie): * cc: bgamari, hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 07:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 07:37:00 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.12ca80c95411616aeb495ebb8615547c@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | 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): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"0cc3931bd7831fa8d042f968a5a9114534a656e4/ghc" 0cc3931b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0cc3931bd7831fa8d042f968a5a9114534a656e4" configure.ac: fix --host= handling The following command fails as: $ ./configure --prefix=/usr \ --build=x86_64-pc-linux-gnu \ --host=x86_64-pc-linux-gnu \ --target=x86_64-pc-linux-gnu configure: error: You've selected: BUILD: x86_64-unknown-linux HOST: x86_64-unknown-linux TARGET: x86_64-unknown-linux BUILD must equal HOST; 18f06878ed5d8cb0cf366a876f2bfea29647e5f0 changed native configure $build/$host/$target checks to ghc-mangled ones, but not completely. Signed-off-by: Sergei Trofimovich Reviewers: rwbarton, erikd, austin, hvr, bgamari, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2508 GHC Trac Issues: #12487 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 08:35:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 08:35:20 -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.e7de86207868c72244ceccac64740f4a@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: | -------------------------------------+------------------------------------- Comment (by simonmar): So I think this tells us that it is not memory bandwidth saturation, right? Because running individual GHC processes scales better than a single parallel GHC. To be sure, you should also use the larger heap settings with the `make -jN` runs. So there is still extra contention in `ghc -jN`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 08:42:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 08:42:30 -0000 Subject: [GHC] #10923: GHC should recompile if flags change In-Reply-To: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> References: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> Message-ID: <060.94fd605a0c380c47cf770ea2ef5c4a14@haskell.org> #10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"818760d68c0e5e4479a4f64fc863303ff5f23a3a/ghc" 818760d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="818760d68c0e5e4479a4f64fc863303ff5f23a3a" Fix #10923 by fingerprinting optimization level. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin, bgamari, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2509 GHC Trac Issues: #10923 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 08:44:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 08:44:58 -0000 Subject: [GHC] #10923: GHC should recompile if flags change In-Reply-To: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> References: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> Message-ID: <060.a320ed92e6c95b153aebaa52151e7454@haskell.org> #10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: low | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => merge Comment: bgamari, do you think we should merge this? I'm happy either way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 08:51:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 08:51:26 -0000 Subject: [GHC] #12557: Regression in type inference with ImpredicativeTypes (was: Regression in type inference with RankNTypes) In-Reply-To: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> References: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> Message-ID: <062.5f4404550fed9b8c6aeb721a82d993bc@haskell.org> #12557: Regression in type inference with ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | ImpredicativeTypes 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 thomie): * keywords: => ImpredicativeTypes * priority: high => low @@ -4,0 +4,3 @@ + {-# LANGUAGE ImpredicativeTypes #-} + module Test where + New description: Consider the following code: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} module Test where foo :: ((forall a.f a) -> f r) -> f r foo g = undefined }}} In GHC 7.10.3: {{{ *Main> :t \g -> foo g \g -> foo g :: ((forall a. f a) -> f r) -> f r }}} In GHC 8.0.1: {{{ *Main> :t \g -> foo g :1:11: error: • Couldn't match expected type ‘(forall a. f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of it :: t -> f r at :1:1 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at :1:2) }}} -- Comment: Your example relies on `-XImpredicativeTypes`. Please note that this language extension is entirely [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html #impredicative-polymorphism unsupported]. That said, you can make you example work by running `:set -XImpredicativeTypes` on the GHCi prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 09:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 09:15:12 -0000 Subject: [GHC] #12557: Regression in type inference with ImpredicativeTypes In-Reply-To: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> References: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> Message-ID: <062.d36c678aea8f1192524dcc44ad5dc541@haskell.org> #12557: Regression in type inference with ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | ImpredicativeTypes 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: This is a bug in 7.10. Basically, a lambda-bound variable like `\g` above can never get a higher rank type (one involving a forall), unless there is an enclosing type signature so that it's clear ''at the binding site'' what its type should be. I don't know any way to fix this. Do not rely on `-XImpredicativeTypes`; it is an incomplete, inconsistent and generally broken feature that I should probably remove. I just don't know how to do a better job, sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 09:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 09:45:49 -0000 Subject: [GHC] #12427: Type inference regression with RankNTypes (GHC 8.1) In-Reply-To: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> References: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> Message-ID: <060.88a62981bbceff0acf4c08f398979bd5@haskell.org> #12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox, osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 09:53:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 09:53:13 -0000 Subject: [GHC] #12427: Type inference regression with RankNTypes (GHC 8.1) In-Reply-To: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> References: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> Message-ID: <060.2d3580f797c6ccd376d139acf32217ff@haskell.org> #12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): ghc-HEAD from Feb 2016: {{{ commit 62d1888ff45bd817409be2c3eacdc86cfef4bed8 Date: Thu Feb 11 11:00:24 2016 +0000 }}} typechecked the example above. I'll try to bisect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 09:54:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 09:54:00 -0000 Subject: [GHC] #12561: Scope extrusion in Template Haskell Message-ID: <046.4a487143b8d0a703e22cc324a57ee11d@haskell.org> #12561: Scope extrusion in Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With typed quotes `[|| e ||]` and splices `$$(e)`, Template Haskell is supposed guarantee to generate type-correct code. But a conversation with Oleg following my talk at the Cambridge Metaprogramming Summer School (Aug 16) made me realise that it isn't. The problem is that {{{ [|| e ||] :: Q (TExp ty) }}} So a typed quote is still monadic. That is useful because it means that a function returning code can fail gracefully: {{{ f :: Int -> Q (TExp Bool) f n | n < 0 = fail "Argument less than zero" | otherwise = .... }}} yielding a civilised error in the type checker's monad. But giving ALL the power of Q is too much. Below is a program cooked up by Oleg that demonstrates the problem concretely. {{{ {-# Language TemplateHaskell #-} module T where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Language.Haskell.TH.Ppr import Data.IORef show_code cde = (runQ . unTypeQ $ cde) >>= putStrLn . pprint t1 = do c1 <- [|| (1::Int) + 2 ||] c2 <- [|| 3 + $$(return c1) ||] return c2 t2 :: Q (TExp Int) t2 = do r <- runIO $ newIORef undefined c1 <- [|| \x -> (1::Int) + $$(do xv <- [||x||] runIO $ writeIORef r xv return xv) ||] runIO $ readIORef r t1s = show_code t1 ts2 = show_code t2 }}} ----------------------- Possible solutions. * Give typed quotes access to only an emasculated Q monad, thus {{{ [[| e ||] :: QQ (TExp ty) }}} where `QQ` has more limited effects. This would work, and has the merit of simplicity. We can read stuff (reification), report errors, and even catch those exceptions -- provided that we don't include `TExp` values in exceptions (not sure how we prevent that!). * Do what Meta OCaml does. Oleg writes "But you can go all the way and allow any effects. Q becomes no special (and possibly redundant). The stress is not on precluding scope extrusion statically but catch it immediately when it occurs (and report it with detailed error information: which variable has escaped, on which line of the source code was its intended binder, etc). This is what MetaOCaml does. I should stress it reports the scope extrusion even for open code, if one (of many) free variables in that code cannot eventually be bound. So the problem is not a scope extrusion per se: it is waiting until the whole code is generated to report it, at which time lots of information is already lost and it becomes very difficult to find the error. But reporting the error requires quite a bit of internal changes, to track free variables in any TH code fragment. Anyway, if you want to write the Wiki page, you can refer to my BER MetaOCaml paper, which describes the process." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 09:55:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 09:55:31 -0000 Subject: [GHC] #12427: Type inference regression with RankNTypes (GHC 8.1) In-Reply-To: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> References: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> Message-ID: <060.91d66877d393879c405c94d468168155@haskell.org> #12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): No don't bother, thank you! I'm on this: `wip/spj-tc-branch`. (But I'm heavily distracted at the moment.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 09:58:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 09:58:23 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.95262d4ffdd700043a72c1f60eeef95a@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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): Hmm. Maybe just report when it arises from a GADT pattern match. That is the primary use-case: {{{ data T a where T1 :: T Int T2 :: T a T3 :: T Bool f :: T Int -> Bool f T1 = ... f T2 = ... f T3 = ... -- We want to report this case as inaccessible }}} I'll think on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 11:46:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 11:46:33 -0000 Subject: [GHC] #12555: bindist configure checks involving the compiler are broken In-Reply-To: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> References: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> Message-ID: <062.ed2929ebea64d19b71b8e118ea69d6ed@haskell.org> #12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch 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): Phab:D2510 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2510 Comment: Oh dear, thank you Reid. I suppose the test plan also should have included testing with a sufficiently new libdw as well. Silly me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 11:50:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 11:50:58 -0000 Subject: [GHC] #12557: Regression in type inference with RankNTypes (was: Regression in type inference with ImpredicativeTypes) In-Reply-To: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> References: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> Message-ID: <062.b793ffe657b8b29342fca2ae73463acf@haskell.org> #12557: Regression in type inference with RankNTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | ImpredicativeTypes 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: | -------------------------------------+------------------------------------- @@ -4,1 +4,1 @@ - {-# LANGUAGE ImpredicativeTypes #-} + {-# LANGUAGE RankNTypes #-} New description: Consider the following code: {{{#!hs {-# LANGUAGE RankNTypes #-} module Test where foo :: ((forall a.f a) -> f r) -> f r foo g = undefined }}} In GHC 7.10.3: {{{ *Main> :t \g -> foo g \g -> foo g :: ((forall a. f a) -> f r) -> f r }}} In GHC 8.0.1: {{{ *Main> :t \g -> foo g :1:11: error: • Couldn't match expected type ‘(forall a. f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of it :: t -> f r at :1:1 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at :1:2) }}} -- Comment (by slindley): My example doesn't require `-XImpredicativeTypes` only `-XRankNTypes`! As I understand it the 'bug' in 7.10 was that it did infer polymorphic types for lambda-bound variables even with `-XImpredicativeTypes` disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 12:04:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 12:04:09 -0000 Subject: [GHC] #12557: Regression in type inference with RankNTypes In-Reply-To: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> References: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> Message-ID: <062.6ad46f58223f9b2446a87001051d6980@haskell.org> #12557: Regression in type inference with RankNTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | ImpredicativeTypes 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 slindley): It does look like there's a bug in the error message. The message I want to see here is that t must be monomorphic, not that it is rigid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 13:56:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 13:56:56 -0000 Subject: [GHC] #10923: GHC should recompile if flags change In-Reply-To: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> References: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> Message-ID: <060.d79cf34d7931a61bf60ee64e4da443df@haskell.org> #10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: low | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Shouldn’t you be fingerprinting all optimization-related flags, and not just the level? If I add `-fapply-fancy-transformation` the arguments, I would expect the compiler to rebuild the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 14:46:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 14:46:07 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.84fe58086e14974c92b4c6ac2390581e@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Recall that type families don't really have a kind because they must always appear saturated. I'll write `~>` for a function argument that must always be provided. (In the language of my [https://github.com/goldfirere/thesis dissertation], `->` used in a kind is ''matchable'' and I will use `~>` for ''unmatchable''. Currently, unmatchable functions in types must always appear saturated. Type families are the only way to write an unmatchable function in a type.) So, with {{{ class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u }}} I would expect {{{ Domain :: forall u. Type ~> Sig u -> Type Internal :: forall u. Type ~> u }}} Having the `forall` out front does matter, because it means the type family can branch on the choice of `u`. (It should really be a `pi`. And be unmatchable.) If Jack wants things to be different, then he can specify {{{ class Syntactic' a where type Domain' a :: forall u. Sig u -> Type type Internal' a :: forall u. u }}} yielding {{{ Domain' :: Type ~> forall u. Sig u -> Type Internal' :: Type -> forall u. u }}} These `forall`s describe arguments that ''cannot'' be matched against in the type family instances and so are seemingly less useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 14:53:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 14:53:34 -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.ce0dcd051de4fbd35b6c72d60b72d555@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new 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:D2490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. Let's do the easy thing now (no scoped type variables) and then we can revisit the harder thing in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 15:16:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 15:16:55 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.fd89b43aeac384a4562291d0bbc77a53@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: ak3n => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 16:23:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 16:23:14 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjU2MDog4oCYOmluZm8gVFlQReKAmSBtZW50?= =?utf-8?q?ions_any_instance_that_includes_=E2=80=98Type=E2=80=99?= In-Reply-To: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> References: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> Message-ID: <066.ef0fb286f94ae9ffde193c2f2c4fc624@haskell.org> #12560: ‘:info TYPE’ mentions any instance that includes ‘Type’ -------------------------------------+------------------------------------- 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 goldfire): I'm sorry: What's the unexpected behavior? What would you expect instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 16:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 16:51:04 -0000 Subject: [GHC] #11740: RFC kind synonyms In-Reply-To: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> References: <051.0e72c4f1c3d54cad33a28cc5a9b7fcc3@haskell.org> Message-ID: <066.426549aee348a248f51959e0b56f36ce@haskell.org> #11740: RFC kind synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): {{{#!hs type Monadish = Type -> Type type Transformer = Monadish -> Monadish }}} with many examples from Edward's work on [https://www.reddit.com/r/haskell/comments/50rxci/edward_kmett_monad_homomorphisms_google_tech_talk/d76tmnm monad morphisms] {{{#!hs newtype Tensor :: Transformer -> Transformer -> Transformer where Tensor :: s (t m) a -> Tensor s t m a class MonadTrans (t :: Transformer) class Commute (s :: Transformer) (t :: Transformer) where commute :: Monad m => s (t m) a -> t (s m) a newtype StateT s :: Transformer where StateT :: (s -> m (a, s)) -> StateT s m a newtype WriterT w :: Transformer where WriterT :: m (a, w) -> WriterT w m a }}} etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:09:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:09:03 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) Message-ID: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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: -------------------------------------+------------------------------------- First of all let me apologize for the terrible testcase. I tried to find a smaller one (and am still trying) but haven’t managed to do so. The good news is that at least for me it’s reproducible === Steps to reproduce === {{{ git clone 'git at github.com:bscarlet/llvm-general.git' -b llvm-3.8 cd llvm-general cabal new-build llvm-general curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2b70a8cc1a1aed7a44b418fba04e8df4818c1237/out.patch > out.patch git apply out.patch cabal new-build llvm-general }}} The patch just adds a newline somewhere to create a rebuild. I’ve seen this panic for completely different changes (all in this project) so I don’t think the change matters. I’ve also seen this panic with stack, cabal new-build and cabal build (using sandboxes). === Output === {{{ In order, the following will be built (use -v for more details): llvm-general-3.8.0.0 Preprocessing library llvm-general-3.8.0.0... [84 of 92] Compiling LLVM.General.Internal.Module ( src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist- newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o ) [85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Module.o ) [LLVM.General.Internal.Module changed] [89 of 92] Compiling LLVM.General.Internal.PassManager ( src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general /dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): idInfo r_XsTP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} === Comments === In this case this can be resolved by running cabal new-build again. However I’ve also had cases where this didn’t fix it and I had to blow away dist-newstyle. I haven’t yet managed to find a reproducible testcase for the latter. Matthew Pickering mentioned that he encountered this (or a similar) bug while building GHC. I tried core-lint but that didn’t help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:09:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:09:45 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.af99ebb2131a1cefad7d6d60b215015a@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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 cocreature): * Attachment "out.log" added. Build log with -v3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:17:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:17:53 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.6857325e8c2f574ac3bc025f2281aa26@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | 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: #12000, #9878 | Differential Rev(s): Phab:D2504 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:37:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:37:35 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.9a7b5cf3d7851f1dbe070c034a266da2@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: | ---------------------------------+-------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:38:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:38:44 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.d618e51e1587a531d21980aad2f16eed@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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 cocreature): Switching back and forth between applying and reverting the patch causes the same panic each time (that’s a lot faster than rebuilding completely each time). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:53:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:53:06 -0000 Subject: [GHC] #12563: Bad error message around lack of impredicativity Message-ID: <047.189413f523240243492187f38831ca8b@haskell.org> #12563: Bad error message around lack of impredicativity -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- (Broken out from #12557.) Consider {{{ foo :: ((forall a. f a) -> f r) -> f r foo g = undefined x = \g -> foo g }}} Compiling this code produces {{{ Scratch.hs:24:15: error: • Couldn't match expected type ‘(forall (a :: k). f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of x :: t -> f r at Scratch.hs:24:1-15 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at Scratch.hs:24:6) x :: t -> f r (bound at Scratch.hs:24:1) }}} The code should be rejected. But, really, the problem is that the type of a lambda-bound variable can't be a polytype (unless the type is obvious at the binding site). We should improve this error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 17:53:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 17:53:26 -0000 Subject: [GHC] #12557: Regression in type inference with RankNTypes In-Reply-To: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> References: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> Message-ID: <062.2dfa9d6a3833b24da845cae1d93e92ab@haskell.org> #12557: Regression in type inference with RankNTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | ImpredicativeTypes 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): Yes, that error message is unfortunate. But I agree with 8.0 that your code should be rejected. I have filed #12563 requesting an error message improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 18:01:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 18:01:28 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjU2MDog4oCYOmluZm8gVFlQReKAmSBtZW50?= =?utf-8?q?ions_any_instance_that_includes_=E2=80=98Type=E2=80=99?= In-Reply-To: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> References: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> Message-ID: <066.5300e376d6531f4791f755ef0401e02d@haskell.org> #12560: ‘:info TYPE’ mentions any instance that includes ‘Type’ -------------------------------------+------------------------------------- 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 Iceland_jack): Maybe this is expected (please close if so), without `print-explicit- kinds` I was surprised to see many pages of seemingly unrelated instances (more than I posted in this minimal example). The information for `*` lists no instances nor does [https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Types.html#t:TYPE Hackage], I suppose I expected the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 18:49:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 18:49:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjU2MDog4oCYOmluZm8gVFlQReKAmSBtZW50?= =?utf-8?q?ions_any_instance_that_includes_=E2=80=98Type=E2=80=99?= In-Reply-To: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> References: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> Message-ID: <066.ef5a5187222c6b14402b4fa604ec4628@haskell.org> #12560: ‘:info TYPE’ mentions any instance that includes ‘Type’ -------------------------------------+------------------------------------- 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 goldfire): By mentioning `-fprint-explicit-kinds` above, do you mean to suggest `:info T` should print only those instances where the use of `T` is visible? That's plausible, but not what's done now. `:info *` won't list instances because `*` is a type synonym. Hackage doesn't list instances for `*` for the same reason. But it also doesn't list instances for `TYPE`. This last bit is because `TYPE` lives in `ghc-prim` and the instances live in `base`, so Haddock hasn't seen them yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 19:00:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 19:00:23 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.3b0efb46a4594ad449a5820598ab82c1@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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 cocreature: @@ -8,1 +8,2 @@ - git clone 'git at github.com:bscarlet/llvm-general.git' -b llvm-3.8 + -- Install llvm-3.8 + git clone 'https://github.com/bscarlet/llvm-general.git' -b llvm-3.8 New description: First of all let me apologize for the terrible testcase. I tried to find a smaller one (and am still trying) but haven’t managed to do so. The good news is that at least for me it’s reproducible === Steps to reproduce === {{{ -- Install llvm-3.8 git clone 'https://github.com/bscarlet/llvm-general.git' -b llvm-3.8 cd llvm-general cabal new-build llvm-general curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2b70a8cc1a1aed7a44b418fba04e8df4818c1237/out.patch > out.patch git apply out.patch cabal new-build llvm-general }}} The patch just adds a newline somewhere to create a rebuild. I’ve seen this panic for completely different changes (all in this project) so I don’t think the change matters. I’ve also seen this panic with stack, cabal new-build and cabal build (using sandboxes). === Output === {{{ In order, the following will be built (use -v for more details): llvm-general-3.8.0.0 Preprocessing library llvm-general-3.8.0.0... [84 of 92] Compiling LLVM.General.Internal.Module ( src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist- newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o ) [85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Module.o ) [LLVM.General.Internal.Module changed] [89 of 92] Compiling LLVM.General.Internal.PassManager ( src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general /dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): idInfo r_XsTP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} === Comments === In this case this can be resolved by running cabal new-build again. However I’ve also had cases where this didn’t fix it and I had to blow away dist-newstyle. I haven’t yet managed to find a reproducible testcase for the latter. Matthew Pickering mentioned that he encountered this (or a similar) bug while building GHC. I tried core-lint but that didn’t help. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 19:34:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 19:34:09 -0000 Subject: [GHC] #10923: GHC should recompile if flags change In-Reply-To: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> References: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> Message-ID: <060.ee3dce2f9137289f8de3c2cb5a6f65b0@haskell.org> #10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: low | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I guess that's true. (Ugh, there's certainly a lot of them.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 19:36:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 19:36:58 -0000 Subject: [GHC] #10923: GHC should recompile if flags change In-Reply-To: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> References: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> Message-ID: <060.545fe1c4edd3461ea6530b68fe98fddc@haskell.org> #10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: merge => new Comment: I think you’ll want a data structure that contains all the effective optimization flags, and not aliases like `-O`. This way, adding a flag that is implied by, say `-O`, would not cause recompilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 20:45:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 20:45:24 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.df81053c5283b6b4c28f1ef2a1111847@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"f93c363fab1ac8ce6f0b474f5967b0b097995827/ghc" f93c363f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f93c363fab1ac8ce6f0b474f5967b0b097995827" extend '-fmax-worker-args' limit to specialiser (Trac #11565) It's a complementary change to a48de37dcca98e7d477040b0ed298bcd1b3ab303 restore -fmax-worker-args handling (Trac #11565) I don't have a small example but I've noticed another discrepancy when was profiling GHC for performance cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr was specialised by 'spec_one' down to a function with arity 159. As a result 'perf record' pointed at it as at slowest function in whole ghc library. I've extended -fmax-worker-args effect to 'spec_one' as it does the same worker/wrapper split to push arguments to the heap. The change decreases heap usage on a synth.bash benchmark (Trac #9221) from 67G down to 64G (-4%). Benchmark runtime decreased from 14.5 s down to 14.s (-7%). Signed-off-by: Sergei Trofimovich Reviewers: ezyang, simonpj, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2507 GHC Trac Issues: #11565 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 20:45:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 20:45:24 -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.d79a66904b969c51a35a508c5259f433@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: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"f93c363fab1ac8ce6f0b474f5967b0b097995827/ghc" f93c363f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f93c363fab1ac8ce6f0b474f5967b0b097995827" extend '-fmax-worker-args' limit to specialiser (Trac #11565) It's a complementary change to a48de37dcca98e7d477040b0ed298bcd1b3ab303 restore -fmax-worker-args handling (Trac #11565) I don't have a small example but I've noticed another discrepancy when was profiling GHC for performance cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr was specialised by 'spec_one' down to a function with arity 159. As a result 'perf record' pointed at it as at slowest function in whole ghc library. I've extended -fmax-worker-args effect to 'spec_one' as it does the same worker/wrapper split to push arguments to the heap. The change decreases heap usage on a synth.bash benchmark (Trac #9221) from 67G down to 64G (-4%). Benchmark runtime decreased from 14.5 s down to 14.s (-7%). Signed-off-by: Sergei Trofimovich Reviewers: ezyang, simonpj, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2507 GHC Trac Issues: #11565 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 23:22:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 23:22:57 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.0b29cfaabadc98746b369bfd97f79aec@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I'll start out by saying that I seem to be missing something! == Example that failed in original question == It can be solved by specifying the kind of `a :: Type`: {{{#!hs -- Compiles fine! class Syntactic (a :: Type) where type Domain a :: Sig u -> Type type Internal a :: u desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} I believe this to be a bug. == I don't know what I'm doing == Replying to [comment:6 simonpj]: > Alas Jack has posted no fewer than four different declarations of `Internal`, so I'm not sure which one(s) you think should be accepted. My bad > Jack, what kind do you WANT `Internal` to have? None, possibly! It seems that the kind `u` is an existential kind(?) so maybe I should use `DomainInternal` directly, rather than going from `a` → `Domain, Internal` → `ASTF (Domain a) (Internal a)`... Or define an existential data type that can be converted to `ASTF _ _`. {{{#!hs data EXISTS where EX :: (Sig u -> Type) -> u -> EXISTS type family ASTify (ex :: EXISTS) :: Type where ASTify (EX dom a) = ASTF dom a }}} Both of these make certain definitions very awkward though, but figuring this out is beyond the scope of this ticket.. you go from a neat definition like: {{{#!hs instance Syntactic (a -> b) where type Domain (a -> b) = Domain a type Internal (a -> b) = Internal a -> Internal b }}} to something like this (I believe) {{{#!hs type family DomainInternalArr a b where DomainInternalArr (ASTF dom a) (ASTF dom b) = ASTF dom (a -> b) instance Syntactic (a -> b) where type DomainInternal (a -> b) = DomainInternalArr (DomainInternal a) (DomainInternal b) }}} == Non-solution == Something like this could work if #11962 gets fixed, maybe {{{#!hs class Syntactic (a :: Type) where type SyntKind a :: Type type Domain a :: Sig (SyntKind a) -> Type type Internal a :: SyntKind a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 2 23:36:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Sep 2016 23:36:22 -0000 Subject: [GHC] #12564: Type family in type pattern kind Message-ID: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to write a type family that is analogous to `!!` for lists but requires the index to be no bigger than the length of the list. Usually, in dependently typed languages finite sets are used for this purpose, here's an attempt to do so in Haskell: {{{#!haskell {-# LANGUAGE TypeInType, TypeFamilies, GADTs, TypeOperators #-} import Data.Kind data N = Z | S N type family Len (xs :: [a]) :: N where Len '[] = Z Len (_ ': xs) = S (Len xs) data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family At (xs :: [a]) (i :: Fin (Len xs)) :: a where At (x ': _) FZ = x At (_ ': xs) (FS i) = At xs i }}} It fails to compile with this error: {{{ FinAt.hs:16:3: error: • Illegal type synonym family application in instance: 'FZ • In the equations for closed type family ‘At’ In the type family declaration for ‘At’ }}} That's because the kind of the `FZ` pattern (first clause of `At`) has the kind `Fin (Len xs)` and the application of `Len` cannot reduce completely. `checkValidTypePat` then disallows the pattern, as it contains a type family application. I tried to suppress `checkValidTypePat` and the definition of `At` has compiled; however, it's of little use, since `At` doesn't reduce: {{{#!haskell x :: At '[Bool] FZ x = True }}} results in {{{ FinAt.hs:20:5: error: • Couldn't match expected type ‘At * ((':) * Bool ('[] *)) ('FZ 'Z)’ with actual type ‘Bool’ • In the expression: True In an equation for ‘x’: x = True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 00:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 00:34:31 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.8ef0c542e78cfe73aaabbbe4469791ba@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rcook): Will hsc2cs's version number need to be bumped? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 05:20:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 05:20:24 -0000 Subject: [GHC] #10161: GHC does not relink if we link against a new library with old timestamp (was: GHC does not relink if a library's code changed) In-Reply-To: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> References: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> Message-ID: <057.d64a646923f855bb640513175fb6160c@haskell.org> #10161: GHC does not relink if we link against a new library with old timestamp -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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: #10966 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 05:31:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 05:31:43 -0000 Subject: [GHC] #10161: GHC does not relink if we link against a new library with old timestamp In-Reply-To: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> References: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> Message-ID: <057.291234a9a1d3426f497e76245c5f6714@haskell.org> #10161: GHC does not relink if we link against a new library with old timestamp -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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: #10966 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I think thomie is right and the base problem is the same: the way we decide to relink is if any of the inputs to the linker are newer than the executable. In the provided test case, both libraries are built before the initial link, so there's nothing newer. A workaround is to touch the library after you do an operation like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 10:37:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 10:37:01 -0000 Subject: [GHC] #12565: unhelpful error message about enabling TypeApplications Message-ID: <044.4134d62159643bc95161b319ea8f1a1e@haskell.org> #12565: unhelpful error message about enabling TypeApplications -------------------------------------+------------------------------------- Reporter: mauke | 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: -------------------------------------+------------------------------------- {{{ % cat bug.hs }}} {{{#!hs {-# LANGUAGE TypeApplications #-} main = return (id@() ()) }}} {{{ % ghc bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) bug.hs:2:16: error: Pattern syntax in expression context: id@() Did you mean to enable TypeApplications? }}} This error message makes no sense because `TypeApplications` is already enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 10:56:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 10:56:51 -0000 Subject: [GHC] #12566: Memory leak Message-ID: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> #12566: Memory leak -------------------------------------+------------------------------------- Reporter: igloo | 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: -------------------------------------+------------------------------------- With the attached write.hs (which generates a file called "data") and read.hs (which consumes that file), if I run {{{ ghc -Wall -Werror -O write.hs -o write ghc -Wall -Werror -O -prof -auto-all read.hs -o read1 ghc -Wall -Werror -O -prof -auto-all read.hs -o read2 -DLEAK ./write ./read1 +RTS -h ./read2 +RTS -h }}} then read2's heap profile shows that it is retaining a lot of extra data. Perhaps I am missing something, but I can't see why this needs to be retained. I would expect the two heap profiles to look the same. Sources and heap profiles (using GHC 8.0.1) attached. I've copied the sources below for convenience: write.hs: {{{#!hs module Main (main) where import qualified Data.ByteString.Lazy.Char8 as L main :: IO () main = L.writeFile "data" $ L.concat $ map mkByteString [1..100000] mkByteString :: Int -> L.ByteString mkByteString i = L.concat (L.pack ("#" ++ show i ++ "\n") : replicate 100 (L.pack "Something else\n")) }}} read.hs: {{{#!hs {-# LANGUAGE BangPatterns, CPP #-} module Main (main) where import Data.List import Data.Set (Set) import qualified Data.Set as Set import qualified Data.ByteString.Char8 as S import qualified Data.ByteString.Lazy.Char8 as L main :: IO () main = do bs <- L.readFile "data" let stats = getMaybes bs s = mkSet stats print $ Set.size s mkSet :: [Maybe S.ByteString] -> Set S.ByteString mkSet ms = foldl' f Set.empty ms where f s (Just l) = Set.insert l s f s _ = s getMaybes :: L.ByteString -> [Maybe S.ByteString] getMaybes bs = if L.null bs then [] else case getMaybe bs of (stat, bs') -> stat : getMaybes bs' getMaybe :: L.ByteString -> (Maybe S.ByteString, L.ByteString) getMaybe bs = case L.uncons bs of Just ('#', bs') -> case L.break ('\n' ==) bs' of (l, bs'') -> let !l' = copy l in (Just l', bs'') _ -> case L.break ('\n' ==) bs of (_x, bs') -> #ifdef LEAK copy _x `seq` #endif (Nothing, L.tail bs') copy :: L.ByteString -> S.ByteString copy bs = S.copy $ L.toStrict bs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 10:57:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 10:57:28 -0000 Subject: [GHC] #12566: Memory leak In-Reply-To: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> References: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> Message-ID: <059.7c1978b972418873c2bb8ba836de80aa@haskell.org> #12566: Memory leak -------------------------------------+------------------------------------- Reporter: igloo | 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 igloo): * Attachment "write.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 10:57:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 10:57:36 -0000 Subject: [GHC] #12566: Memory leak In-Reply-To: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> References: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> Message-ID: <059.40559a71c717d9873051e2bf0a47e183@haskell.org> #12566: Memory leak -------------------------------------+------------------------------------- Reporter: igloo | 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 igloo): * Attachment "read.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 10:57:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 10:57:46 -0000 Subject: [GHC] #12566: Memory leak In-Reply-To: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> References: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> Message-ID: <059.b8be2ad03ca7eb4a213028f148e1250c@haskell.org> #12566: Memory leak -------------------------------------+------------------------------------- Reporter: igloo | 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 igloo): * Attachment "read1.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 10:57:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 10:57:53 -0000 Subject: [GHC] #12566: Memory leak In-Reply-To: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> References: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> Message-ID: <059.56ac34c3bc82b2cffc795dcdf129dda5@haskell.org> #12566: Memory leak -------------------------------------+------------------------------------- Reporter: igloo | 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 igloo): * Attachment "read2.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 13:33:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 13:33:37 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS Message-ID: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bare-bones module {{{#!hs {-# OPTIONS -fplugin GHC.TypeLits.Normalise #-} module A where }}} compiling it will always say {{{ $ ghc --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) [GHC.TypeLits.Normalise changed] }}} even when the module was compiled before. {{{ $ ghc A.hs -c -ddump-if-trace -ddump-hi-diffs }}} will give the reason: {{{ imported module ‘GHC.TypeLits.Normalise’ is from package ‘ghc-typelits- natnormalise-0.5’, which is not among previous dependencies }}} Which is the probable cause: when writing the `.hi` file, the used plugins' package dependencies should be also written out. AFAICS they are extracted fron the `DynFlags` but for this comparison in {{{ checkDependencies :: HscEnv -> ModSummary -> ModIface -> IfG RecompileRequired }}} but not found in the `ModSummary` that was originally written to disk. This is pretty nasty for `clash` compilations and the suspected bug is documented here: https://github.com/clash-lang/ghc-typelits- natnormalise/issues/2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 21:19:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 21:19:09 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.286f6332e7e5c0850e23c14dececf14d@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- Comment (by heisenbug): Following patch seems to fix the problem: {{{#!diff diff --git a/compiler/iface/MkIface.hs b/compiler/iface/MkIface.hs index 8115583..f6856ae 100644 --- a/compiler/iface/MkIface.hs +++ b/compiler/iface/MkIface.hs @@ -1112,6 +1112,12 @@ checkDependencies hsc_env summary iface return (RecompBecause reason) else return UpToDate + | moduleName mod `elem` pluginModNames (hsc_dflags hsc_env) + -> do traceHiDiffs $ + text "imported module " <> quotes (ppr mod) <> + text " is from package " <> quotes (ppr pkg) <> + text ", and is a plugin" + return UpToDate | otherwise -> if pkg `notElem` (map fst prev_dep_pkgs) then do traceHiDiffs $ }}} Of course I am playing fast and loose with other checks. I should e.g. make sure that it is not regularly found first. Anyway, can somebody review this, so that I know I am going in the right general direction? For example as suggested above, the plugin modules' packages could be saved into the `.hi` files. But I did not find a way to do that, as the DynFlags don't track the packages of plugins, only their `ModuleName`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 3 21:24:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Sep 2016 21:24:34 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.d1cf4df32f2e9adcb2d58e62c56b840b@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 00:14:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 00:14:00 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.1a1efbfe6c048511afbd96be705a90b8@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): If a fix for this this could be considered for 8.0.2 it would seriously improve the user experience for compiler plugins greatly! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 01:58:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 01:58:09 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.5b4699c128d294576bdeae9091fd0813@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by omefire): * cc: omefire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 06:34:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 06:34:40 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone In-Reply-To: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> References: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> Message-ID: <061.8f39e3ed0b6b343eb034d3c2fe9d8c3b@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:1 simonmar]: > Currently all `ForeignPtrs` that are unreachable get finalized at the same time. This is how it's intended to work. > > We *could* refine it so that a finalizer from a `Concurrent.ForeignPtr` can keep a C `ForeignPtr` alive. It would mean processing the two kinds of weak pointers in separate batches (and possibly keeping them in separate lists, I'm not sure). You gave me privately the tip to use `StablePtr`. So I added a `freeStablePtr` after `withForeignPtr`. This works nicely! Thus I think it is enough to add a warning to `touchForeignPtr` and `withForeignPtr` that they have no effect in a concurrent finalizer and that you should consider `StablePtr` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 11:04:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 11:04:52 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.6b3b7aa6c3ad0fd5171a63c400d96408@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Gabor Greif ): In [changeset:"f8b139fd11611694aed0bbf8e4ee009ae91ef566/ghc" f8b139f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8b139fd11611694aed0bbf8e4ee009ae91ef566" test #12567: add new testcase with expected plugin behaviour }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 11:10:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 11:10:32 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.f9d2278f57a462226bdb6141f82cecb3@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): When this issue is fixed 18057549ffebea244d9170377889d096ca9fdbcd can be simply reverted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 13:29:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 13:29:33 -0000 Subject: [GHC] #12568: Release hsc2hs new version to Hackage Message-ID: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> #12568: Release hsc2hs new version to Hackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.2 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: -------------------------------------+------------------------------------- Richard Cook recently fixed #12054 in f5ae016e5a69ebf42d612805e51afd9227df9389. This needs to be released to Hackage before the 8.0.2 GHC release -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 13:29:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 13:29:44 -0000 Subject: [GHC] #12568: Release hsc2hs new version to Hackage In-Reply-To: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> References: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> Message-ID: <061.a80bc0ae259f0787d55309774f72af2a@haskell.org> #12568: Release hsc2hs new version to Hackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | 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): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 14:18:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 14:18:17 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.3c4c09d68bdcf810143d99de94211ea4@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: bollu => Comment: Feel free to assign it back to yourself when you want to continue @bollu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 14:24:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 14:24:28 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.56664490004616472cfd830d0a3188ac@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => bollu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 14:25:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 14:25:11 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.cd9f0bcc7bfb3bd47f892fc942d6066d@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 14:26:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 14:26:17 -0000 Subject: [GHC] #12569: TypeApplications doesn't allow unticked list constructors. Message-ID: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> #12569: TypeApplications doesn't allow unticked list constructors. -------------------------------------+------------------------------------- Reporter: vagarenko | 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: -------------------------------------+------------------------------------- TypeApplications doesn't allow unticked list constructor even when it is unambiguous: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help > :set -XDataKinds > :set -XTypeApplications > :set -XScopedTypeVariables > :set -XKindSignatures > let foo :: forall (xs :: [Nat]). (); foo = () > foo @'[0] () > foo @[0] :17:6: error: * Expected kind `[Nat]', but `[0]' has kind `*' * In the type `[0]' In the expression: foo @[0] In an equation for `it': it = foo @[0] :17:7: error: * Expected a type, but `0' has kind `Nat' * In the type `[0]' In the expression: foo @[0] In an equation for `it': it = foo @[0] }}} why `[0]` has kind `*` here? However this is legal: {{{ > let foo :: forall (x :: Bool). (); foo = () > foo @True () > foo @'True () }}} and this is wierd: {{{ > :set -XPolyKinds > let foo :: forall (x :: k). (); foo = () > foo @'True :12:6: error: * Expected a type, but 'True has kind `Bool' * In the type `True' In the expression: foo @True In an equation for `it': it = foo @True > foo @True :13:6: error: * Expected a type, but 'True has kind `Bool' * In the type `True' In the expression: foo @True In an equation for `it': it = foo @True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 15:45:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 15:45:01 -0000 Subject: [GHC] #12570: Different behaviour in Linux and Mac OS when using some locale environments Message-ID: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> #12570: Different behaviour in Linux and Mac OS when using some locale environments -------------------------------------+------------------------------------- Reporter: asr | 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 reporting [https://github.com/malcolmwallace/cpphs/issues/6 this] cpphs issue, we found the following behaviour: {{{ $ echo -e '\u2200' > test $ LC_CTYPE=C ghc -e 'putStr =<< readFile "test"' }}} In Ubuntu, we get the error {{{ : test: hGetContents: invalid argument (invalid byte sequence) }}} but in Mac OS the output is {{{ ∀ }}} GHC version: 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 15:46:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 15:46:48 -0000 Subject: [GHC] #12556: `stimes` adds extra power to Semigroup In-Reply-To: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> References: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> Message-ID: <066.b038e623c68eb088a5377862c6f2f418@haskell.org> #12556: `stimes` adds extra power to Semigroup -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 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 osa1): This probably needs to be discussed in the libraries mailing list. I agree this is a bit weird. If `sconcat` takes a `NonEmpty` as argument, then maybe `stimes` should take a `NonZero`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 15:50:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 15:50:35 -0000 Subject: [GHC] #12570: Different behaviour in Linux and Mac OS when using some locale environments In-Reply-To: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> References: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> Message-ID: <057.9f375dd86e97f034026c6bb5cb252d12@haskell.org> #12570: Different behaviour in Linux and Mac OS when using some locale environments -------------------------------------+------------------------------------- Reporter: asr | 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 asr: @@ -9,1 +9,1 @@ - In Ubuntu, we get the error + In Ubuntu, we got the error New description: While reporting [https://github.com/malcolmwallace/cpphs/issues/6 this] cpphs issue, we found the following behaviour: {{{ $ echo -e '\u2200' > test $ LC_CTYPE=C ghc -e 'putStr =<< readFile "test"' }}} In Ubuntu, we got the error {{{ : test: hGetContents: invalid argument (invalid byte sequence) }}} but in Mac OS the output is {{{ ∀ }}} GHC version: 8.0.1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 15:51:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 15:51:46 -0000 Subject: [GHC] #12570: Different behaviour in Linux and Mac OS when using some locale environments In-Reply-To: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> References: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> Message-ID: <057.4313a9cb1bad2ba05f69fe986623d267@haskell.org> #12570: Different behaviour in Linux and Mac OS when using some locale environments -------------------------------------+------------------------------------- Reporter: asr | 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 asr: @@ -16,1 +16,1 @@ - but in Mac OS the output is + but in Mac OS the output was New description: While reporting [https://github.com/malcolmwallace/cpphs/issues/6 this] cpphs issue, we found the following behaviour: {{{ $ echo -e '\u2200' > test $ LC_CTYPE=C ghc -e 'putStr =<< readFile "test"' }}} In Ubuntu, we got the error {{{ : test: hGetContents: invalid argument (invalid byte sequence) }}} but in Mac OS the output was {{{ ∀ }}} GHC version: 8.0.1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 16:04:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 16:04:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjU2MDog4oCYOmluZm8gVFlQReKAmSBtZW50?= =?utf-8?q?ions_any_instance_that_includes_=E2=80=98Type=E2=80=99?= In-Reply-To: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> References: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> Message-ID: <066.d4be94d244bf3f2a76cbf68b31ae864b@haskell.org> #12560: ‘:info TYPE’ mentions any instance that includes ‘Type’ -------------------------------------+------------------------------------- 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 Iceland_jack): Yes, it would even be possible to have listed instances depend on whether `print-explicit-kinds` is enabled or not: i.e. we only list the instance if `*` appears in the output (having instances depend on flags is weird, the current behaviour may be preferable). Another idea is to treat `TYPE` as a special case and temporarily show explicit kinds when its instances are printed regardless of flags. The connection between `TYPE` and `*` may also not be obvious to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 16:39:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 16:39:15 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.32cb91d70dc2ca27793b7b25b663f7bb@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, there's actually a deeper set of bugs here. See also #7414 and #7277. It would be nice if we could get our hands on an implementation hash; then we can just record it in the interface file directly as a plugin hash and fix things more properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 18:44:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 18:44:18 -0000 Subject: [GHC] #12570: Different behaviour in Linux and Mac OS when using some locale environments In-Reply-To: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> References: <042.8afd5bf8f6b43725c94b6ba207ea4de9@haskell.org> Message-ID: <057.529f5eb45f1f18cd6afa1ef51a568e3c@haskell.org> #12570: Different behaviour in Linux and Mac OS when using some locale environments -------------------------------------+------------------------------------- Reporter: asr | 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 asr: @@ -6,1 +6,1 @@ - $ LC_CTYPE=C ghc -e 'putStr =<< readFile "test"' + $ LC_ALL=C ghc -e 'putStr =<< readFile "test"' New description: While reporting [https://github.com/malcolmwallace/cpphs/issues/6 this] cpphs issue, we found the following behaviour: {{{ $ echo -e '\u2200' > test $ LC_ALL=C ghc -e 'putStr =<< readFile "test"' }}} In Ubuntu, we got the error {{{ : test: hGetContents: invalid argument (invalid byte sequence) }}} but in Mac OS the output was {{{ ∀ }}} GHC version: 8.0.1 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 19:12:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 19:12:25 -0000 Subject: [GHC] #12571: GHC panic Message-ID: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | 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 Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I received the following error message from GHC: {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fStorableWord21 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: 8040 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When I followed the suggestion of adding `-fsimpl-tick-factor=200` the compiler proceeds normally (finding a syntax error in a file). Removing this option, strangely, also causes the compiler to proceed normally. I can no longer reproduce this bug, although several compilations in a row (before adding the option) reproduced the bug. Although I cannot reproduce this bug, the syntax error that is present came from an error of the form: {{{#!hs f :: A -> M B f a = do x <- g a let c = h a in do ... }}} The actual file is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 19:13:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 19:13:23 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.10c1922e664c5af547250a4dd843103a@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by prsteele): * Attachment "DB.hs" added. The file containing the syntax error that the compiler was eventually able to find. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 19:19:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 19:19:07 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.c4129d0f4aec8312984bbbf094c74b84@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The error is because GHC was doing too much inlining. The syntax error is completely unrelated. Maybe if you try with `-fforce-recomp` you will be able to reproduce the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 19:25:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 19:25:40 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.f170366ed137daea806a3253dfc073a5@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by prsteele): Adding {{{-fforce-recomp}}} did in fact cause the bug to resurface. I've used this to isolate the value I need for {{{-fsimpl-tick-factor}}} to cause the compiler to succeed. In particular, {{{-fsimpl-tick- factor=110}}} causes the compiler to fail, but {{{-fsimpl-tick- factor=111}}} causes the compiler to succeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 21:07:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 21:07:28 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.0b7b12ea57653ccfe5e01ab51f275d0f@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded Comment: Please provide the code which causes the inlining to happen. These kinds of reports are usually because a library author is over zealous adding inline pragmas to everything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 22:39:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 22:39:03 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated Message-ID: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- When building GHC git HEAD on Debian Testing I get: {{{ libraries/unix/cbits/HsUnix.c: In function ‘__hscore_readdir’: libraries/unix/cbits/HsUnix.c:64:3: error: error: ‘readdir_r’ is deprecated [-Werror=deprecated-declarations] res = readdir_r(dirPtr, p, pDirEnt); ^~~ In file included from libraries/unix/include/HsUnix.h:71:0: error: 0, from libraries/unix/cbits/HsUnix.c:9: /usr/include/dirent.h:183:12: error: note: declared here extern int readdir_r (DIR *__restrict __dirp, ^~~~~~~~~ }}} According to the man page: > This function is deprecated; use readdir(3) instead. > > The readdir_r() function was invented as a reentrant version of readdir(3). It reads the next directory entry from the directory stream dirp, and returns it in the caller-allocated buffer pointed to by entry. > > It is expected that a future version of POSIX.1 will make readdir_r() obsolete, and require that readdir() be thread-safe when concurrently employed on different directory streams. In order to support all of the various *nix systems, we probably need to detect if `readdir_r` is deprecated and only use `readdir` where `readdir_r` is in fact deprecated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 22:43:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 22:43:03 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.1db784a1d64d7dbf024445a9a80517e8@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 erikd): * owner: => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 4 22:44:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Sep 2016 22:44:36 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.0ed81deea3c75fef217498f1d8a48e61@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 erikd): Since the implementation already has `#if HAVE_READDIR_R` this fix mostly involves detecting whether `readdir_r` is deprecated or not and setting `HAVE_READDIR_R` appropriately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 01:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 01:01:29 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.16e7258bcd455409070509a7fb470210@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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): Doesn't unix have its own bug tracker (https://github.com/haskell/unix/issues)? But then I wonder why there is a libraries/unix component here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 03:01:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 03:01:18 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.bc2f9abdc2735c8fe764024c76300a89@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11746,#11972 | Differential Rev(s): Phab:D2189, Wiki Page: | Phab:D2512 -------------------------------------+------------------------------------- Changes (by akio): * differential: Phab:D2189 => Phab:D2189, Phab:D2512 Comment: Created Phab:D2512 for fixing the test failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 05:50:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 05:50:37 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.6f100f59863b9f11c240435b53abda11@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by prsteele): * Attachment "ghc-bug.zip" added. A snapshot of the code that can exhibit the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 05:51:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 05:51:03 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.69ba616bb104d777049492f90aec5324@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by prsteele): I have attached a ZIP file containing a snapshot of the project. The project currently can be compiled via `cabal build create-tables`. However, if you remove the `-fsimpl-tick-factor=131` in the `recipes.cabal` file (or decrease the number to 130 or below) the bug appears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 06:12:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 06:12:27 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.b450f51099c213fd6e52754d65d2b0c7@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 erikd): Lodged a ticket at https://github.com/haskell/unix/issues/70. Should we keep this here to until the fix in the unix submodule is merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 06:49:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 06:49:00 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.f972b465657afbc4c7aa65874cdd6936@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 bollu): How do I reproduce this, exactly? If I'm fixing this, I'll need to know when the bug is fixed, so I was wondering what the correct way to reproduce this is. Do I damage my package database on purpose? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 06:53:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 06:53:29 -0000 Subject: [GHC] #12569: TypeApplications allows instantiation of implicitly-quantified kind variables (was: TypeApplications doesn't allow unticked list constructors.) In-Reply-To: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> References: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> Message-ID: <063.bffd8aef8748278c82c5522c5283d3d5@haskell.org> #12569: TypeApplications allows instantiation of implicitly-quantified kind variables -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry, goldfire (added) * keywords: => TypeApplications * component: Compiler => Compiler (Type checker) Comment: I believe the ticked/unticked constructor mechanism is working as designed, but you may be on to something with your "weird" example. == To tick or not to tick == Without a tick, `[0]` as a type is in fact ill-kinded. `[0]` is syntactic sugar for `[] 0` where `[] :: * -> *` is the list type constructor. Moreover, `0` does not have kind `*`. This is why you get two errors from `foo @[0]`. With a tick, `'[0]` is syntactic sugar for `0 ': '[]` (i.e. a promoted list of one element) and has kind `[Nat]` as expected. A tick is necessary when a data constructor and type constructor have the same name, and you want to refer to the data constructor in the type namespace. In the case of `True` and `'True`, in the absence of a type constructor `True`, this is genuinely unambiguous and the tick is optional. == The actual bug == (Whether the constructor is ticked or not is irrelevant here.) When you write `let foo :: forall (x :: k). (); foo = ()`, GHC implicitly quantifies over the kind variable `k` to give `foo :: forall k (x :: k) . ()`. I would expect that `k` would not be available for instantiation via a type application, but apparently it is, because `foo @True` is rejected but `foo @Bool @True` is accepted. I think we should have `foo :: forall {k} (x :: k) . ()` instead. @goldfire, would you agree that this should be changed? In any case, we should document this case in the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 07:58:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 07:58:33 -0000 Subject: [GHC] #12566: Memory leak In-Reply-To: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> References: <044.231103b2a83a11ff01042aa643d1a0c1@haskell.org> Message-ID: <059.2f5fe80c515749a7e6c81c077eb163d7@haskell.org> #12566: Memory leak -------------------------------------+------------------------------------- Reporter: igloo | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Runtime performance bug Comment: It's unclear whether GHC is at fault or the `bytestring` library. Needs investigation. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 09:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 09:03:57 -0000 Subject: [GHC] #12571: GHC panic In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.b47d34a214680eea3d7c828e1a8f32ed@haskell.org> #12571: GHC panic -------------------------------------+------------------------------------- Reporter: prsteele | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): From initial inspection, it seems that the reason for the message is that `postgresql-simple` uses bytestrings to represent the query type. Basically every function in the bytestring library is marked inline so when the `String` is converted to a `Bytestring` using the builder function which maps over the whole string, a lot of inlining is then exposed which GHC dutifully performs. The reason this trips things up is that your strings are quite long I think and there are quite a few of them in the file. So I'm not sure what to suggest here, it seems the best would be to just keep the flag in your cabal file as the compile time didn't seem too long to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 09:15:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 09:15:37 -0000 Subject: [GHC] #12571: ByteString builder causes the optimiser to run out of ticks (was: GHC panic) In-Reply-To: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> References: <047.b264aa03e463dd3ef84d58441f36a123@haskell.org> Message-ID: <062.8b626df91b911ecbf16f3c5545b78dd6@haskell.org> #12571: ByteString builder causes the optimiser to run out of ticks -------------------------------------+------------------------------------- Reporter: prsteele | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: infoneeded => closed * resolution: => duplicate Comment: Seems like https://github.com/haskell/bytestring/issues/45 is related. so I will close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 13:34:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 13:34:09 -0000 Subject: [GHC] #12559: Don't ignore addTopDecls in module finalizers In-Reply-To: <056.d891faa710239ad090c2d102b89973c3@haskell.org> References: <056.d891faa710239ad090c2d102b89973c3@haskell.org> Message-ID: <071.3397f0c21ed8066cf1af2dc30f85d15a@haskell.org> #12559: Don't ignore addTopDecls in module finalizers -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template- | haskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11832 | Differential Rev(s): Phab:D2505 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Facundo Domínguez ): In [changeset:"71dd6e4429833238bcdaf96da8e2e41a62dacbf4/ghc" 71dd6e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71dd6e4429833238bcdaf96da8e2e41a62dacbf4" Don't ignore addTopDecls in module finalizers. Summary: Module finalizer could call addTopDecls, however, the declarations added in this fashion were ignored. This patch makes sure to rename, type check and incorporate this declarations. Because a declaration may include a splice which calls addModFinalizer, the list of finalizers is repeteadly checked after adding declarations until no more finalizers remain. Test Plan: ./validate Reviewers: bgamari, goldfire, simonpj, austin Reviewed By: bgamari, simonpj Subscribers: simonmar, mboes, thomie Differential Revision: https://phabricator.haskell.org/D2505 GHC Trac Issues: #12559 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 14:07:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 14:07:34 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.234881bbe65cf13a67843c7d2db93903@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | 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): * priority: normal => high * failure: None/Unknown => Compile-time crash * component: Compiler => Compiler (Type checker) * milestone: => 8.0.2 @@ -4,1 +4,1 @@ - {{{ + {{{#!hs New description: When attempting to load this code in ghci with ghc-8.0.1, I get an infinite loop while it attempts to display the error: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where type family F a t :: * type family T a :: * type T a = F a }}} {{{ catbug :: ~/Scratch/ast-experiment » ghci test.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/trevor/.ghci [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:7:14: error: }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 14:09:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 14:09:49 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.b3b42650479fe0399e75c8060a277b80@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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): c.f #12386 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 14:10:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 14:10:32 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.aeab87e9b6243a41e73930fb961f53fc@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | 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 simonpj): This is a black-hole kind of bug. Works ok if you move `F` out of the type class {{{ type family F a t :: * class C a where type family T a :: * type T a = F a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 14:11:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 14:11:21 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.8467d24a53618821214da599e313222e@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | 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): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 14:12:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 14:12:19 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.91db020a4ee8b9d5e3827b9b22871591@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | 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): * cc: goldfire (added) Comment: Richard, might you have some idea of what is going on here? It seems plausibly related to #12174, perhaps you could have a look during your bug sweep? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 14:29:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 14:29:09 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.c08ab238daa650033df62d22d8745317@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 16:44:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 16:44:59 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap Message-ID: <046.6cc0462ada69fe792e001db236aed944@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | 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 stumbled upon a case where an external library (OpenCL) does not work if a specific address (0x200000000) is taken. It so happens that `osReserveHeapMemory` starts trying to `mmap` at `0x200000000`: {{{ void *hint = (void*)((W_)8 * (1 << 30) + attempt * BLOCK_SIZE); at = osTryReserveHeapMemory(*len, hint); }}} This makes it impossible to use Haskell programs compiled with GHC 8 with C functions that use OpenCL. See this example https://github.com/chpatrick/oclwtf for a repro. My proposal is to allow the user to work around this kind of behavior outside our control by letting the user override the starting address through an RTS command line flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 17:35:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 17:35:28 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.a7e0588f795f718a10bc2b0dc8a87248@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 Phyx-): @bollu, yeah, that seems like a reasonable thing to do, but I wouldn't go messing with your stage0 compiler (e.g. the one you use to compile the git source with the first time). Just do a normal compile and corrpupt the stage2 compiler in the folder `inplace` that gets created. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 18:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 18:07:47 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.fa308ad3126ced20ea96751ed08764fd@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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): You could also make a sandbox and damage the sandbox package database? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 18:26:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 18:26:38 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.16bc3355dbd71b5ae9dc3e5f675351e1@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 19:29:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:29:21 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.e89c7a4add586d0c08ea6f8cb88970f3@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: #9557 | Differential Rev(s): Phab:D2502 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4ff4929cbaab21a3ca867abbc1bd24ff3287a16f/ghc" 4ff4929c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ff4929cbaab21a3ca867abbc1bd24ff3287a16f" Make generated Ord instances smaller (per #10858). Reviewers: simonpj, bgamari, RyanGlScott, austin Reviewed By: simonpj Subscribers: nomeata, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2502 GHC Trac Issues: #10858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 19:29:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:29:21 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.8483102eea32511d2dcf14b15c5aaa09@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: akio Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2486 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6ea62427de419ea071e1ea79ad0c15d9f4e90a67/ghc" 6ea6242/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6ea62427de419ea071e1ea79ad0c15d9f4e90a67" Turn divInt# and modInt# into bitwise operations when possible This implements #5615 for divInt# and modInt#. I also included rules to do constant-folding when the both arguments are known. Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2486 GHC Trac Issues: #5615 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 19:29:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:29:21 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.92a69f8f81d0e9b5bbadf9e70d7347b9@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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:D2484 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8d00175f4ba969ca5f4edf26b0e8593a79d4f508/ghc" 8d00175/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d00175f4ba969ca5f4edf26b0e8593a79d4f508" Less scary arity mismatch error message when deriving Test Plan: Corrected a few tests to include the new message. Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2484 GHC Trac Issues: #12546 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 19:46:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:46:16 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.5dd193179aadc822fed4bcf7256bef16@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: akio Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2486 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 Mon Sep 5 19:46:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:46:59 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.ba3e9be56bbf390dde465c1d59465373@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mniip Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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:D2484 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 19:47:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:47:16 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.b6e568e6592be4b44e8b9966638ee1ac@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Rev(s): Phab:D2502 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 Mon Sep 5 19:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 19:48:42 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.5f96d7d2145c7ddf1351d44b04e7fe83@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"34010dbe77ac405da6c671c3feb3573d0d025379/ghc" 34010db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34010dbe77ac405da6c671c3feb3573d0d025379" Derive the Generic instance in perf/compiler/T5642 Summary: For some inexplicable reason, the `Generic` instance in `perf/compiler/T5642` is written out entirely by hand. This is not only strange, since Trac #5642 is about derived `Generic` instances, but it also annoying to maintain, since it requires manually changing a bunch of code whenever the algorithm behind `deriving Generic` changes. (See D2304 for a recent example of this.) It seems more sensible to just derive the `Generic` instance. It shifts the goalposts of what allocations we're measuring a bit, since we no longer have to parse a large amount of code (and as a knock-on effect, the allocations go down a bit). But I think this program is morally equivalent to what we were benchmarking before, so it's not too unreasonable to change. Test Plan: make test TEST=T5642 Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D2511 GHC Trac Issues: #5642 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:23:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:23:34 -0000 Subject: [GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' In-Reply-To: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> References: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> Message-ID: <061.dc0674e579269e8b1cd4f4f0312f2a5d@haskell.org> #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2492 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:27:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:27:58 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.2a08cd0a60c8a22122fbfeb78d042541@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:33:54 -0000 Subject: [GHC] #12472: "lazy" is not optimized away In-Reply-To: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> References: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> Message-ID: <060.3a6656cf2a4155755e611c5f48d6091a@haskell.org> #12472: "lazy" is not optimized away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 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:D2444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): A variant of the patch from comment:2 was merged to `ghc-8.0` to allow for easy merging of the fix for #12076. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:35:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:35:16 -0000 Subject: [GHC] #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' In-Reply-To: <045.45bfd5a6dee62b13780515de863d4289@haskell.org> References: <045.45bfd5a6dee62b13780515de863d4289@haskell.org> Message-ID: <060.4b115f7bf1184f9d5ec812de4d7e94ba@haskell.org> #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | 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:D2309 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: comment:6 was merged to `ghc-8.0` as 2a9767ed596679ddf21b7edfa9fc6410443c2a01. The `binary-trees` regression fix was merged as 47d589ef52ded1ab3f81994f6567dac666e08587. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:37:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:37:17 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.671d03de648c81ad6d78976b4bc38c57@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged in 8736625f143d55616e76ff660d476ce4a9cdb2d9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:42:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:42:30 -0000 Subject: [GHC] #12010: Incorrect return types for recv() and send() on Windows In-Reply-To: <045.cd7d6e8e5a2d9e9b7b83c726e2bb2436@haskell.org> References: <045.cd7d6e8e5a2d9e9b7b83c726e2bb2436@haskell.org> Message-ID: <060.70ba391a694b2156d8d052d424462aeb@haskell.org> #12010: Incorrect return types for recv() and send() on Windows -----------------------------------+-------------------------------------- Reporter: enolan | Owner: enolan Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2170 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: closed => merge * version: => 8.0.1 * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:47:24 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.6a5abba81cc78187df32041bf391675e@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: But comment:5 doesn't actually fix this issue. Reopening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:48:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:48:30 -0000 Subject: [GHC] #12216: GHC 8.0.1 panics when compiling JuicyPixels-repa 0.7.1 In-Reply-To: <042.b1ada30e7aa6c282148fb638f8d80f2a@haskell.org> References: <042.b1ada30e7aa6c282148fb638f8d80f2a@haskell.org> Message-ID: <057.6ecd1c1fac27764dc8fc724a96536342@haskell.org> #12216: GHC 8.0.1 panics when compiling JuicyPixels-repa 0.7.1 -------------------------------------+------------------------------------- Reporter: cgo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #12127 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12127 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:59:56 -0000 Subject: [GHC] #12555: bindist configure checks involving the compiler are broken In-Reply-To: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> References: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> Message-ID: <062.e3927f1f65d02904fc07bbdd7608dc0c@haskell.org> #12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch 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): Phab:D2510 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"05b497ece50f508526d0906f675bdb4c8109d46a/ghc" 05b497e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="05b497ece50f508526d0906f675bdb4c8109d46a" distrib: Fix libdw bindist check As reported in #12555 this code was terribly broken. Sadly, Autoconf was none-the-wiser. Thanks to @rwbarton for pointing this out. Test Plan: Test with libdw version newer and older and 0.158 Reviewers: hvr, austin, rwbarton Reviewed By: rwbarton Subscribers: thomie, rwbarton, erikd Differential Revision: https://phabricator.haskell.org/D2510 GHC Trac Issues: #12555 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 20:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 20:59:56 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.b8e4fd3ab5b84a5eb1d02431e7ca6c2a@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11746,#11972 | Differential Rev(s): Phab:D2189, Wiki Page: | Phab:D2512 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a7a960e43c34e40e1656fa1505605f756a44bb71/ghc" a7a960e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7a960e43c34e40e1656fa1505605f756a44bb71" Make the test for #11108 less fragile This change should close #11108 by fixing the test case. This commit fixes two issues: * Make sure that each weak pointer we allocate has a constructor as the key, not a thunk. A failure to do so meant these weak pointers died prematurely on the 'ghci' WAY. * Don't print anything in the finalizer, because they are not guaranteed to run. Test Plan: validate Reviewers: austin, simonmar, erikd, bgamari Reviewed By: erikd, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2512 GHC Trac Issues: #11108 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:02:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:02:48 -0000 Subject: [GHC] #12066: Symbol not found: _stg_ap_0_upd_info In-Reply-To: <047.acb085228fe7253ed07d0786e97ac00b@haskell.org> References: <047.acb085228fe7253ed07d0786e97ac00b@haskell.org> Message-ID: <062.0be7df39ca74cdf097307f59ffc9ec36@haskell.org> #12066: Symbol not found: _stg_ap_0_upd_info -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => duplicate * related: => #12076 * milestone: => 8.0.2 Comment: It sounds very likely that this was #12076, which will be fixed in 8.0.2. Closing. Feel free to reopen if you can still reproduce with 8.0.2 or later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:03:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:03:21 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.02dcf61e7f31036c04b66ace16513328@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeInType 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.0.2 => 8.2.1 Comment: Bumping off to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:05:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:05:27 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.e8086ed7a646eb60129407da4179777f@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: This won't be happening for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:10:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:10:19 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.ca45c0f517c33b6025295cac5042b8cb@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge Comment: comment:9 could be merged for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:10:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:10:58 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.e036ddd5872f1609394106d7d6b67c11@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeInType 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.0.2 => 8.2.1 Comment: This won't happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:11:27 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.f9a18afbbeaeb3773e6b12f7a0ee8592@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | 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.0.2 => 8.2.1 @@ -3,1 +3,1 @@ - {{{ + {{{#!hs New description: Consider this contrived example: {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds, UndecidableInstances #-} module Bug where import Data.Proxy type family F (a :: k) :: k type instance F a = G a type family G a type instance G a = a foo :: Proxy (F Maybe) -> Proxy Maybe foo = id }}} This (correctly) fails to compile. The error message is {{{ Bug.hs:14:7: Couldn't match type ‘F Maybe’ with ‘Maybe’ Expected type: Proxy (F Maybe) -> Proxy Maybe Actual type: Proxy Maybe -> Proxy Maybe In the expression: id In an equation for ‘foo’: foo = id Failed, modules loaded: none. }}} But this is peculiar, but it surely looks like `F` should be a type-level identity function! Of course, upon further inspection, we see that `F` is partial. It reduces only at kind `*`. This is quite hard to figure out, though, especially given that we're using the "default to `*`" behavior of open type families to arrange for this kind restriction. Thus, I propose: figure out when a type family reduction is held up due to a kind mismatch, and inform the user. -- Comment: This won't happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:12:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:12:23 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.2f384cd55beb7c7066cd7c33af31dc7f@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Raising priority as this leakage results in an extremely large number of files on my test box. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:15:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:15:23 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.b316ebc975c7d17c98b4880ba41adc51@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.0.2 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:D2324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2324 Comment: Phab:D2324 is a quick hack that I put together to fix this. Unfortunately, its use of recursive deletion makes me quite nervous. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:17:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:17:58 -0000 Subject: [GHC] #11836: Hello World Bug - silent stdout errors In-Reply-To: <042.baad19c7e01cfc8c7893de62fb103b5f@haskell.org> References: <042.baad19c7e01cfc8c7893de62fb103b5f@haskell.org> Message-ID: <057.6627cf1726417adbbc3726d6960b6e74@haskell.org> #11836: Hello World Bug - silent stdout errors -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.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: #11180 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: Bumping to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:20:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:20:00 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.3a35913ef17966f9000adb8d565ae4ae@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: How are you passing `-march` to the build system? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:22:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:22:43 -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.05e45ff369fe513348d2707c7614641b@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: phab:D2450 => phab:D2450, phab:D2514 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:27:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:27:29 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.86637e3d4fe9709d4ad6f7dc52fa95c2@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12209 | Differential Rev(s): Phab:D2500 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 714779c7d175203b95e6442f01a4164bedf52e90. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:27:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:27:59 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.9db4cfb1f28fa84a5e8ce24570d1852f@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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:D2484 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 52c743033ab0d969101ab4616bfce3ecf2e6e472. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:28:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:28:17 -0000 Subject: [GHC] #12555: bindist configure checks involving the compiler are broken In-Reply-To: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> References: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> Message-ID: <062.6c09a1f555ec6690806dd3621cafa3bf@haskell.org> #12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | 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): Phab:D2510 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 23d60a530e2013b643aaa2de96f8cbbe98feb64e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:38:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:38:54 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.0c9dd9991c9aed59a05c9f47efa749ad@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1-rc2 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:D2515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2515 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:39:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:39:14 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.5b92209cabd5f886d9f832bc14b9f506@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1-rc2 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:D2515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:40:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:40:25 -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.484dadd62e89b7d56943f90234c02f87@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: nomeata, simonpj, was there ever any motion in the direction of a fix here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:42:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:42:41 -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.bd0fec821f7ecf8836e70198c3c28f47@haskell.org> #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 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: new => infoneeded Comment: Can someone provide a simple set of instructions for how to reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:42:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:42:53 -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.866f7532c2f1022fd45d63b4a959c637@haskell.org> #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: infoneeded 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): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:50:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:50:00 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.79e52f129b09f9f870014714c6d2a912@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2516 @@ -7,1 +7,1 @@ - {{{ + {{{#!hs New description: This ticket is a continuation of #11978 and #12009. After fixing a couple of issues in those two tickets I found that the profiling run time is not thread safe. Have a trivial test program (written as one of the tests for #11978): {{{#!hs import Control.Concurrent import Control.Concurrent.MVar import Control.Exception import Control.Monad main :: IO () main = do putStrLn "Start ..." mvar <- newMVar (0 :: Int) let count = 50 forM_ [ 1 .. count ] $ const $ forkIO $ do threadDelay 100 i <- takeMVar mvar putMVar mvar $! i + 1 threadDelay 1000000 end <- takeMVar mvar putStrLn $ "Final result " ++ show end assert (end == count) $ return () }}} Compiling that with a compiler that has bug fixes arising from #11978 and #12009 as: {{{ inplace/bin/ghc-stage2 testsuite/tests/profiling/should_run/T11978b.hs \ -fforce-recomp -rtsopts -fno-warn-tabs -O -prof -static -auto-all \ -threaded -debug -o T11978b }}} and run as: {{{ ./T11978b +RTS -p -hb -N10 }}} crashes in a number of different ways. I've seen at least 3 different assertion failures and numerous segfaults (in different `stg_ap_*` functions). Replace `-hb` with other profiling options like `-hr` etc do not seem to crash. Looking at code, one example of lack of thread safetly is the function `LDV_recordDead` which mutates global variable `censuses` which does not have any locking around it. Only figured this out because the following assert (in `LDV_recordDead`) was being triggered occasionally. {{{ ASSERT(censuses[t].void_total < censuses[t].not_used); }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:52:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:52:27 -0000 Subject: [GHC] #12055: Typechecker panic instead of proper error In-Reply-To: <046.1237d444c794f470f1d99c65363ee9aa@haskell.org> References: <046.1237d444c794f470f1d99c65363ee9aa@haskell.org> Message-ID: <061.e67515d41282f04cd15e7717b75fe796@haskell.org> #12055: Typechecker panic instead of proper error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T12055, T12055a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => lowest * milestone: 8.0.2 => 8.0.3 Comment: It looks like this won't happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:52:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:52:39 -0000 Subject: [GHC] #12055: Typechecker panic instead of proper error In-Reply-To: <046.1237d444c794f470f1d99c65363ee9aa@haskell.org> References: <046.1237d444c794f470f1d99c65363ee9aa@haskell.org> Message-ID: <061.3c697dbfa4b74b8250bfaaf9abd2b768@haskell.org> #12055: Typechecker panic instead of proper error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: lowest | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T12055, T12055a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:53:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:53:32 -0000 Subject: [GHC] #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide In-Reply-To: <042.a992a290421e0ee585b6ffd4e20279f8@haskell.org> References: <042.a992a290421e0ee585b6ffd4e20279f8@haskell.org> Message-ID: <057.dbc46814e9c73107c5b2b9f85981c7ba@haskell.org> #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by bgamari): hvr, any updates on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:57:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:57:15 -0000 Subject: [GHC] #12193: Include target versions of unlit and hsc2hs when cross-compiling In-Reply-To: <047.70c7f34a854dd4d3e899f2d863451090@haskell.org> References: <047.70c7f34a854dd4d3e899f2d863451090@haskell.org> Message-ID: <062.ae4c92b1ceae9f44cafd104dca76a182@haskell.org> #12193: Include target versions of unlit and hsc2hs when cross-compiling -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Build System | Version: 8.0.1 Resolution: | Keywords: cross-compile 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.0.2 => 8.0.3 Comment: thomie, has there been any progress on this? In any event it doesn't seem likely that this will happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 21:58:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 21:58:34 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.1da32b29089696877960b8ff161fb06d@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer 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): * priority: normal => high Comment: Wow, this is quite bizarre. Someone will need to work out what is going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:00:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:00:34 -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.25aca8d74cb0c552d99113d13d0cf18a@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.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:02:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:02:49 -0000 Subject: [GHC] #12133: ConstraintKinds inference failure (regression from 7.10) In-Reply-To: <047.c733b50527f5eb857c28d94b329c6c5a@haskell.org> References: <047.c733b50527f5eb857c28d94b329c6c5a@haskell.org> Message-ID: <062.6b642b2013008d8da075cddff4a9a35b@haskell.org> #12133: ConstraintKinds inference failure (regression from 7.10) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12133 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed the commit mentioned in comment:3 has been merged into 8.0.2 and appears to have fixed the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:03:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:03:47 -0000 Subject: [GHC] #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary In-Reply-To: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> References: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> Message-ID: <061.df3868eb6dc3c9dd7cd0c2b74299ad6f@haskell.org> #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1-rc3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: It doesn't look like this will get fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:06:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:06:18 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.2de7a4c9adf58cb1cd4d5b2711b5fc5a@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 Phyx-): Would the sandbox (I'm fuzzy on the details of it) also sandbox the actual package registration? e.g. does the sandbox copy the installed packages or just links to the ones already installed? I must admit to not having used sandboxes before :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:07:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:07:02 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.4c53c401478c05590acfeb763f0dffe6@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: This won't be fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:09:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:09:01 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.30491d15e91ac45806736305356845aa@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Build System | Version: 8.0.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 bgamari): * milestone: 8.0.2 => 8.0.3 Comment: It doesn't look like this will get fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:10:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:10:27 -0000 Subject: [GHC] #12010: Incorrect return types for recv() and send() on Windows In-Reply-To: <045.cd7d6e8e5a2d9e9b7b83c726e2bb2436@haskell.org> References: <045.cd7d6e8e5a2d9e9b7b83c726e2bb2436@haskell.org> Message-ID: <060.419d4f45b25b66b4721f6491844db677@haskell.org> #12010: Incorrect return types for recv() and send() on Windows -----------------------------------+-------------------------------------- Reporter: enolan | Owner: enolan Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2170 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed Comment: comment:2 merged to `ghc-8.0` as 2a6ac3f18dc6e8abc779b8fbc7232e972f4a8a7d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:13:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:13:39 -0000 Subject: [GHC] #12010: Incorrect return types for recv() and send() on Windows In-Reply-To: <045.cd7d6e8e5a2d9e9b7b83c726e2bb2436@haskell.org> References: <045.cd7d6e8e5a2d9e9b7b83c726e2bb2436@haskell.org> Message-ID: <060.7c6f9ed658def278a91901c7a992a958@haskell.org> #12010: Incorrect return types for recv() and send() on Windows -----------------------------------+-------------------------------------- Reporter: enolan | Owner: enolan Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2170 Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Phyx-): Can you merge 2230c8822233d6d68f930170cd51d96169649056 as well @bgamari? Otherwise the test will fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:14:33 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.e0c5fb139467ac196672cf333e3a38b1@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: The tests aren't critical for 8.0.2. Bumping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:16:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:16:53 -0000 Subject: [GHC] #12421: TestEquality and TestCoercion documentation is confusing In-Reply-To: <045.c655c505ffcb7aac601fde4e2ee18aac@haskell.org> References: <045.c655c505ffcb7aac601fde4e2ee18aac@haskell.org> Message-ID: <060.61a2f18fb2bc2f3f49a8bfec7b7341a1@haskell.org> #12421: TestEquality and TestCoercion documentation is confusing -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | 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): * milestone: 8.0.2 => Comment: This isn't critical for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:17:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:17:36 -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.276e48e88ab06bfa85a9a8b48f836f6e@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: It doesn't look like this will get fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:19:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:19:07 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.9f499e1ebabfe5473c185d83409cbd08@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: GHCi | 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.0.2 => 8.0.3 Comment: Looks like this won't happen for 8.0.2. Rwbarton, do you suppose you could post your patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:23:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:23:59 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.13ac8625b57e66d8b54a0d3479142e24@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 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: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: This won't be fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:27:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:27:14 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.d1d891d64481043303dcddf6981d24e6@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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): They are installed in a completely separate database in ./.cabal-sandbox. So they or neither copied nor linked. I haven't understood this ticket but it's something that popped into my mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 22:32:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 22:32:32 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.078754b05c3356e2d8a816c473d707bb@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): rwbarton, any word on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 23:12:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 23:12:20 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.7484ba86efeb46c95e3bbfb7fc41cd39@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 676efb9f00d14c7f4bad7160d270c1292dd9b436. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 23:12:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 23:12:53 -0000 Subject: [GHC] #12367: Commit adding instances to GHC.Generics regression compiler performance In-Reply-To: <046.87a5f8a842934b4554eedf79fb6bebbc@haskell.org> References: <046.87a5f8a842934b4554eedf79fb6bebbc@haskell.org> Message-ID: <061.ed72d1f30ab26dfff8955f6bba7c967e@haskell.org> #12367: Commit adding instances to GHC.Generics regression compiler performance -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics 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:D2411 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:20 merged to `ghc-8.0` with 291b439fb1da7af4401477c92ba24c7b4b498df8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 23:16:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 23:16:15 -0000 Subject: [GHC] #12367: Commit adding instances to GHC.Generics regression compiler performance In-Reply-To: <046.87a5f8a842934b4554eedf79fb6bebbc@haskell.org> References: <046.87a5f8a842934b4554eedf79fb6bebbc@haskell.org> Message-ID: <061.7bea4f38dbbcd5ff17a3a21bb7529fda@haskell.org> #12367: Commit adding instances to GHC.Generics regression compiler performance -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Generics 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:D2411 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: It seems that the underlying issue here (the lack of laziness in the instance visibility check resulting in unnecessary typechecking) has been solved. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 23:28:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 23:28:51 -0000 Subject: [GHC] #10062: Codegen on sequential FFI calls is not very good In-Reply-To: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> References: <049.b796a4f17cfdd37dfc8152ae0e3bc180@haskell.org> Message-ID: <064.2f7804868f44e2cb60547ca8400d42b3@haskell.org> #10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | 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 tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 5 23:29:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Sep 2016 23:29:19 -0000 Subject: [GHC] #8048: Register spilling produces ineffecient/highly contending code In-Reply-To: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> References: <046.812a6c0f95e2954ecf561f3e19f7d22f@haskell.org> Message-ID: <061.c1cec39f30b970bda9ce7dc92a95a18b@haskell.org> #8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 (CodeGen) | Keywords: register Resolution: | allocator spill Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 05:57:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 05:57:52 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.23d33471c870e379f2ee3e1d3b15e5bf@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: bollu Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 Phyx-): Aha, no you're right, sandboxes would be ideal it sounds like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 08:24:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 08:24:23 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.9e50a0b2d68cdcdc6edc3840ceb40fb7@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: trevor.mcdonell@…, chak (added) Comment: A similar issue came up with Accelerate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 10:09:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 10:09:05 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.6d859f1db950edced72e3a9d1bbca3a9@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmcdonell): @bitonic my current (partially working) solution is to use an `__attribute__((constructor))` function to `mmap` the region that CUDA/OpenCL requires before the RTS initialises. The RTS will then avoid it and you can `munmap` it right before initialising CUDA/OpenCL: https://github.com/tmcdonell/cuda/blob/hotfix/ghc-8/cbits/init.c You can also initialise OpenCL directly in the constructor function, but then you'll spin up the GPU many times during compilation/haddock (every time a package loads your library). (This is simpler and what the master branch of the above repo does, actually.) Both those approaches work for compiled programs, but not in ghci, and I haven't had a chance to dig to the bottom of it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 10:09:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 10:09:58 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.198c3d7ffe6c86ebbce462cadfde017b@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: trevor.mcdonell@… (removed) * cc: tmcdonell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 10:23:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 10:23:57 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.bd5300e4018dafa48ec7d7fc987046b3@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records 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): This sounds good in theory but there are some namespacing problems. Say that we just want to suppress the record selectors, that is easy enough to achieve, but the intention is clearly that users can then define their own selectors with whatever semantics they want with the same names as the field labels. A field label and record selector are currently the same thing. In order to resolve record updates, the current implementation looks up the record selector with the right name. It would seem that a correct solution would place field labels in a separate namespace to variables so they would become truly distinct and properly distinguish the record selector and the field label. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 10:31:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 10:31:29 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.4b77a7070008474e04f007c29f5338e9@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): @tmcdonell , that's clever, I did not know about `__attribute__((constructor))`. It's a nice workaround until we get the RTS workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 12:03:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 12:03:40 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.18cbc5a0ec8624ba96fd4cdfbb3c5e6a@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: cocreature 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 cocreature): * owner: => cocreature Comment: I am making progress in isolating the bug and hope to have a much smaller testcase in the next few days. In the mean time I’m assigning this issue to myself so that other people don’t waste their time on that ugly testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 12:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 12:13:26 -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.741ebbadab929937ebb2a4154428f856@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Sorry I missed your questions, richardfung. Regardless, thanks for your work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 12:28:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 12:28:18 -0000 Subject: [GHC] #12443: DEFAULT_TMPDIR is documented, but doesn't exist In-Reply-To: <047.edde35b3f67cb5f9ea6388079fa88a02@haskell.org> References: <047.edde35b3f67cb5f9ea6388079fa88a02@haskell.org> Message-ID: <062.c3e7ffca136cccc18ad8e8634cb96372@haskell.org> #12443: DEFAULT_TMPDIR is documented, but doesn't exist -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | 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): Phab:D2493 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 Tue Sep 6 13:11:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 13:11:15 -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.82d632adb5f81c17c4ae4a59891ab76b@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: normal | 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Yes. This is a known (but perhaps undocumented) infelicity. I am hoping to fix for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 13:11:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 13:11:23 -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.ab6f3a092cb5f594d674e773b1fd13c9@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: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 14:36:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 14:36:10 -0000 Subject: [GHC] #12565: unhelpful error message about enabling TypeApplications In-Reply-To: <044.4134d62159643bc95161b319ea8f1a1e@haskell.org> References: <044.4134d62159643bc95161b319ea8f1a1e@haskell.org> Message-ID: <059.6f6727e703425735b92119065c8c51a7@haskell.org> #12565: unhelpful error message about enabling TypeApplications -------------------------------------+------------------------------------- Reporter: mauke | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 15:12:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 15:12:15 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjU2MDog4oCYOmluZm8gVFlQReKAmSBtZW50?= =?utf-8?q?ions_any_instance_that_includes_=E2=80=98Type=E2=80=99?= In-Reply-To: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> References: <051.506f18792a704765a26cd81bb962ba2c@haskell.org> Message-ID: <066.0a0776328b8c84332033365579ef21bf@haskell.org> #12560: ‘:info TYPE’ mentions any instance that includes ‘Type’ -------------------------------------+------------------------------------- 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 goldfire): OK, so to summarize: * You request that `:info T` print only those instances for which the use of `T` is visible. Naturally, this list is affected by `-fprint-explicit- kinds`. You mention some other ideas, but I don't think we should treat `TYPE` specially here: if a user is asking about it, they are accessing experts- only areas of GHC and can control the output themselves. Do you agree that this ticket is a feature request for my bulleted feature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 15:23:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 15:23:10 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.7e6e049a157d82743d9e0a55240c2f2a@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: cocreature 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): Thanks. I did try the above but failed with {{{ setup: The program 'llvm-config' version ==3.8.* is required but the version found at /usr/bin/llvm-config is version 2.9 }}} So I can't reproduce without updgrading my Unix box, which I don't own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 15:31:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 15:31:29 -0000 Subject: [GHC] #12569: TypeApplications allows instantiation of implicitly-quantified kind variables In-Reply-To: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> References: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> Message-ID: <063.3570838b184a28bbbc46673bd36d084d@haskell.org> #12569: TypeApplications allows instantiation of implicitly-quantified kind variables -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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 goldfire): I see no bugs here, except possibly bugs in error messages / documentation. The tick is merely at the level of name resolution. When GHC sees an unticked constructor-like name (that is, a capitalized identifier, an identifier starting with a colon, or a use of list syntax in a type), it looks to see if there is a type constructor of that name. If there is, it uses the type name. If there is not, it looks for a data constructor of that name. And that's it. There is no type-directed lookup here. So, when you say `[0]`, without the tick, GHC uses the type `[]` which has the wrong kind. You're right that you "obviously" mean `'[]`, but this would require type-directed name resolution, which GHC does not support. This all works for `True` because there is no type named `True`. (If there were -- try declaring one! -- then your `True` example wouldn't work.) As for `TypeApplications` quantification: if you have mentioned the name of the type/kind variable in the text of your program, it is available for quantification. That's the simple rule, and there are no exceptions (barring bugs in implementation, of which there are several). So, for `foo :: forall (x :: k). ...`, both `k` and `x` are available for visible type application. GHC quantifies the variables in left-to-right order and then does a stable topological sort, putting depended-on variables before their dependencies. (A topological sort is a sort that puts depended-on things before dependencies, and "stable" here means that there is no extra violations of the left-to-right ordering of quantification.) In this case, we get `k` and then `x`. This is explained in the manual [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #visible-type-application here]. I'm happy to take concrete suggestions for improvement, either of the manual or of error messages here. Or, of course, we can debate whether the current behavior is desired -- I'm certainly not wedded to it, but it does seem like a good compromise between the availability of visible type application and need to write `forall` a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 15:40:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 15:40:35 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.72533e837853722e07303e4407b4f30f@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | 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 goldfire): * owner: simonpj => goldfire Comment: Yes, that's plausible. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 16:06:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 16:06:12 -0000 Subject: [GHC] #12569: TypeApplications allows instantiation of implicitly-quantified kind variables In-Reply-To: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> References: <048.fb6eefa9c25c1bc35093206af4ee1086@haskell.org> Message-ID: <063.7be04943accbc3b9b6958d4e37ba28dc@haskell.org> #12569: TypeApplications allows instantiation of implicitly-quantified kind variables -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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 adamgundry): Ah, I imagined that the left-to-right collection and topological sorting of variables applied only when there wasn't an explicit `forall`. My expectation was that if the user gives an explicit `forall`, only the binding occurrences would be available for visible type application. Thus `forall (x :: k)` would make `x` available alone, whereas `forall k (x :: k)` would make both `k` and `x` available. I think this alternative would be better, because otherwise there is no way to get at `forall {k} (x :: k)`, is there? Unless we permit visibility annotations in concrete syntax, I suppose... In any case, this deserves explicit mention in the manual, including the `forall (x :: k)` example, whichever treatment it ends up getting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 17:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 17:57:02 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.90f3d94e7702f7060f55e9a7115d7a37@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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 ekmett): @Iceland_jack: That should complain. The only way for it to become solvable is for the user to supply an orphan instance. We could never supply any errors for unsatisfied instances if that worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 18:43:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 18:43:02 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.38e1125345a63cb3ac1ab33f2f2f834c@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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 cocreature): * owner: cocreature => @@ -1,4 +1,0 @@ - First of all let me apologize for the terrible testcase. I tried to find a - smaller one (and am still trying) but haven’t managed to do so. The good - news is that at least for me it’s reproducible - @@ -8,2 +4,1 @@ - -- Install llvm-3.8 - git clone 'https://github.com/bscarlet/llvm-general.git' -b llvm-3.8 + git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic New description: === Steps to reproduce === {{{ git clone 'https://github.com/cocreature/llvm-general.git' -b ghc-panic cd llvm-general cabal new-build llvm-general curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141bfef/raw/2b70a8cc1a1aed7a44b418fba04e8df4818c1237/out.patch > out.patch git apply out.patch cabal new-build llvm-general }}} The patch just adds a newline somewhere to create a rebuild. I’ve seen this panic for completely different changes (all in this project) so I don’t think the change matters. I’ve also seen this panic with stack, cabal new-build and cabal build (using sandboxes). === Output === {{{ In order, the following will be built (use -v for more details): llvm-general-3.8.0.0 Preprocessing library llvm-general-3.8.0.0... [84 of 92] Compiling LLVM.General.Internal.Module ( src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist- newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o ) [85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Module.o ) [LLVM.General.Internal.Module changed] [89 of 92] Compiling LLVM.General.Internal.PassManager ( src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general /dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): idInfo r_XsTP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} === Comments === In this case this can be resolved by running cabal new-build again. However I’ve also had cases where this didn’t fix it and I had to blow away dist-newstyle. I haven’t yet managed to find a reproducible testcase for the latter. Matthew Pickering mentioned that he encountered this (or a similar) bug while building GHC. I tried core-lint but that didn’t help. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 18:44:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 18:44:37 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.763ba78dc8d99a7a3592180b8ca8199a@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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 cocreature): I’ve managed to make the testcase smaller and most importantly reduce the dependency on LLVM, so it should be a lot easier to build it on various platforms. I’ve updated the instructions in the issue description. The project is still not exactly small but when I tried reducing it the panic went away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 21:10:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 21:10:01 -0000 Subject: [GHC] #11990: Custom Type Error not getting triggered in the nested Type function call In-Reply-To: <047.cd64e02ac6207e6c5247bec38dfaa3ba@haskell.org> References: <047.cd64e02ac6207e6c5247bec38dfaa3ba@haskell.org> Message-ID: <062.a2a92a5802d0a0aaa29cbed7ecf5cfcf@haskell.org> #11990: Custom Type Error not getting triggered in the nested Type function call -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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 diatchki): Hello, sorry for the slow response---I didn't see this before. The current version does exactly what you've pasted so we are OK. Basically, each `TypeError` constraint becomes its own type error, and all of those should be reported as before. The comment about "picking just one type error" was referring to when a single type contains multiple errors. For example, consider the following: {{{ g :: Proxy '[ TypeError (Text "A"), TypeError (Text "B") ] g = Proxy }}} This will generate just one of the type errors. I am not sure if it might be better to generate all of them anyway, or if that would result in too many spurious errors... Even though your example works at the moment, it relies on a specific behavior of the GHC constraint solver that may change in the future. In particular, currently GHC continues to reduce constraints, even though it found a constraint that is impossible to solve (i.e., the `TypeError`). If GHC was to become "lazier" in the future, you would only see one of those errors. A more robust way to get the same behavior would be to write a type function/class that analyzes the type and constructs an error message containing everything that went wrong, and then emitting just one type error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 22:20:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 22:20:44 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings Message-ID: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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: 11583 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I have a polymorphic local binding without a type signature, `-Weverything` complains: {{{ warning: [-Wmissing-local-sigs] Polymorphic local binding with no type signature: ... }}} However, when I add `-Wno-missing-local-sigs`, I immediately get a deprecation warning ` -Wno-missing-local-sigs is deprecated: it is replaced by -Wmissing- local-signatures` First, the warning with `-Weveryting` should use the non-depricated `signatures` version. Second, the deprecation warning should probably respect my use of `no`: `-Wno-missing-local-sigs` is replaced by `-Wno- missing-local-signatures`, not `-Wmissing-local-signatures`. Obviously, check for similar cases with the other "sigs" options mentioned in #11583. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 22:23:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 22:23:22 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.2f4f1ceb3bab7f2272e14ccfda031eb9@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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 warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * failure: None/Unknown => Incorrect warning at compile-time * related: 11583 => #11583, #10752 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 22:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 22:34:35 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout Message-ID: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: -------------------------------------+------------------------------------- GHC doesn't accept `-Wmissed-specializations`. Based on the [http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #specialize-pragma docs], it seems like GHC is trying to support both spellings, so both spellings in the warning should be supported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 22:34:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 22:34:49 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.1c087ad59fcd6eaa92445bb6edb988e5@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 22:41:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 22:41:07 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.753adc95373a302cf101f995ecfa428e@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 6 22:53:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Sep 2016 22:53:57 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.e3f46bb857d7facd82b289a5d8edfa25@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * milestone: => 8.0.2 Comment: still seeing the same problem on 8.0.1. Any chance of this getting fixed in 8.0.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 00:07:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 00:07:43 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.cf7af7d2ce462ab22119201e1380686f@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records 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 AntC): Hi Matthew, I guess this whole ticket has been overtaken by the DuplicateRecordFields extension in GHC 8.0. This ticket was written way before SPJ and Adam arrived at that approach. There might still be some lensaholics who hanker after the namespace. For the record ... > A field label and record selector are currently the same thing. You might think that because they are spelt the same, and one always comes with the other under H98, but actually as at H98 they're not. And that's the point: * a record selector is a function, first-class. If the language didn't create one automatically, you could do it yourself. * a field label can only appear in specific record access contexts {inside curly braces}. It is not first-class; only syntax sugar for positional access to the fields of the constructor. I agree there are namespace concerns if a user creates their own function with the same name (which is indeed the purpose). This chiefly affects module export/import. See the link in the OP for more detail. > It would seem that a correct solution would place field labels in a separate namespace ... I believe the pre-DuplicateRecordFields implementation unsugarred the field labels so they didn't occupy a namespace atall. Perhaps the situation is now different with Overloaded labels. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 03:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 03:48:04 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.a0fcdf31abc0cd9c95b19d399ef581e1@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 erikd): This is now fixed in the unix git repo. at bgamari whats the process to get the GHC tree using the latest version on github? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 06:38:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 06:38:06 -0000 Subject: [GHC] #12576: Large Address space is unenable-able on Windows. Message-ID: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> #12576: Large Address space is unenable-able on Windows. -------------------------------------+------------------------------------- Reporter: Phyx- | 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: #12573 #12495 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Autoconf file changes have made it impossible to enable `USE_LARGE_ADDRESS_SPACE` for Windows, as the `--enable-large-address- space` flag is only respected on Darwin. The general case now depends on the presence of MADV_FREE to enable large address space support. Which means all possibility of enabling this feature on Windows have been removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 06:38:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 06:38:56 -0000 Subject: [GHC] #12576: Large Address space is unenable-able on Windows. In-Reply-To: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> References: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> Message-ID: <059.b5e61eff05042719273f672f6bf0d1c2@haskell.org> #12576: Large Address space is unenable-able on Windows. ----------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12573 #12495 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * keywords: => newcomer * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 07:12:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 07:12:22 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.21776f4f349355c18b62824b6942d1a1@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records 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 adamgundry): @AntC I think mpickering's point is that inside GHC, a(n unambiguous) field label is identified by the `Name` of its selector function when used inside curly braces. There's no real distinction between the two made by the implementation. Changing that would be possible, but tedious. In the post-DuplicateRecordFields implementation, it is possible to distinguish between fields and non-fields during name resolution. Thus it probably wouldn't be too hard to implement a variant on this whereby enabling the extension suppressed all selector functions (local or imported) //for expressions in the current module//, just as DuplicateRecordFields changes the name resolution rules within a single module. The selectors would still be generated, they just wouldn't be in scope. That wouldn't quite give the behaviour you describe on the wiki page with regard to import/export, because if you exported a field then client modules could use it as a selector (unless they enable the extension themselves). You would have the option to hide the field and export a lens of the same name though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 07:40:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 07:40:25 -0000 Subject: [GHC] #12577: The flag -xb has no effect on Windows Message-ID: <044.cc6353756c3c51c0ac3f3dbe20447d20@haskell.org> #12577: The flag -xb has no effect on Windows ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: #12576 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- `-xb` is supposed to be used to change the base memory location for heap allocation calls. However all the calls in `rts\win32\OSMEM.c` call `VirtualAlloc` with `NULL` and not the desired start address. This makes the flag not do anything on Windows (based on quick inspection of allocated values). [[Image(http://i.imgur.com/e1O9Jlb.png, 720px)]] Allocation always starts at `0x020000` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 08:10:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 08:10:49 -0000 Subject: [GHC] #12476: Error building HList In-Reply-To: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> References: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> Message-ID: <070.7588b47ecb0d0b0cc53f420456348b21@haskell.org> #12476: Error building HList -------------------------------------+------------------------------------- Reporter: DanielWaterworth | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielWaterworth): * status: infoneeded => closed * resolution: => fixed Comment: I'm not going to look at this any time soon, so no need to block on it. I'll reopen when/if I revisit it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 08:46:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 08:46:34 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.c415357728394144965429480652c163@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records 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): Replying to [comment:14 AntC]: > Hi Matthew, I guess this whole ticket has been overtaken by the DuplicateRecordFields extension in GHC 8.0. This ticket was written way before SPJ and Adam arrived at that approach. There might still be some lensaholics who hanker after the namespace. For the record ... > > > A field label and record selector are currently the same thing. > > You might think that because they are spelt the same, and one always comes with the other under H98, but actually as at H98 they're not. And that's the point: > > * a record selector is a function, first-class. If the language didn't create one automatically, you could do it yourself. > * a field label can only appear in specific record access contexts {inside curly braces}. It is not first-class; only syntax sugar for positional access to the fields of the constructor. > > I agree there are namespace concerns if a user creates their own function with the same name (which is indeed the purpose). This chiefly affects module export/import. See the link in the OP for more detail. > > > It would seem that a correct solution would place field labels in a separate namespace ... > > I believe the pre-DuplicateRecordFields implementation unsugarred the field labels so they didn't occupy a namespace atall. Perhaps the situation is now different with Overloaded labels. Hi Ant, yes, I am one of those 'lensaholics'. Adam is right that I was referring to the implementation where a field label is identified by the `Name` of the selector (in the non-overloaded case). I don't think this is related to overloaded record fields really. When I read this ticket I didn't imagine that enabling this flag would allow duplicate field labels, just suppress the generation of the field accessors. Anyway, this ticket was instructive because it showed how tightly intertwined the implementation is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 09:15:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 09:15:15 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.182457fedb15615f47c49c299438288e@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records 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 AntC): Thank you Adam for the implementation detail. Remember: * This ticket was raised 4+ years ago (strewth!) when there were huge debates raging about the "Records problem" and a great deal of nothing had been achieved. (It was even before PolyKinds and type-level Strings IIRC.) I wanted to free up some of the design space. * I am not an implementor, so what the ticket requests is in terms of an end-programmer's view. * My remarks just above (and back then) re field labels vs selectors are in terms of the language report [section 3.15] "[Field] Selectors are top level bindings ... This [name] shadowing only affects selector functions; in record construction (Section 3.15.2) and update (Section 3.15.3), field labels cannot be confused with ordinary variables." > When I read this ticket I didn't imagine that enabling this flag would allow duplicate field labels, ... No that wasn't the aim. I was merely aiming to avoid gobbling up the name space. DuplicateRecordFields is a different way to avoid it. > ... just suppress the generation of the field accessors. > > Anyway, this ticket was instructive because it showed how tightly intertwined the implementation is. Yes. Isn't it! I rather wish I hadn't found that out. We still seem a long way from a decent records system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 15:07:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 15:07:24 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2312578=3A_Update_links_to_SPJ=E2=80=99s_pa?= =?utf-8?q?pers?= Message-ID: <046.484aa36286e88f4ca7fdf494dce8681e@haskell.org> #12578: Update links to SPJ’s papers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | 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: -------------------------------------+------------------------------------- It seems that Simon’s homepage got restructured, and a lot of links in the documentation and the code comments are not valid any more. At least these need to be looked at: {{{ $ git grep 'people/simonpj' compiler/types/FamInstEnv.hs:http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/axioms-extended.pdf compiler/types/Unify.hs:[1]: http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/axioms-extended.pdf docs/core-spec/core-spec.mng:phantom equality includes all types. See \url{http://ghc.haskell.org/trac/ghc/wiki/Roles} and \url{http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf} docs/users_guide/glasgow_exts.rst:paper `__. docs/users_guide/glasgow_exts.rst:cloud `__, docs/users_guide/using-optimisation.rst: multiprocessor `__. docs/users_guide/using-optimisation.rst: (ICFP'96) `__. docs/users_guide/using-optimisation.rst: (ICFP'96) `__. docs/users_guide/using-optimisation.rst: programs `__. docs/users_guide/using-optimisation.rst: thesis `__ docs/users_guide/using-optimisation.rst: analyser `__, libraries/base/GHC/Arr.hs:-- http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf libraries/base/GHC/Base.hs:-- http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/coercible.pdf testsuite/tests/dependent/should_compile/all.T:# http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell- dynamic/ $ git grep '~simonpj' compiler/coreSyn/CoreSyn.hs:-- GHC uses System FC for this purpose, docs/users_guide/bugs.rst: inliner `__. docs/users_guide/glasgow_exts.rst: Languages `__. docs/users_guide/glasgow_exts.rst:"group by" `__, docs/users_guide/glasgow_exts.rst:space `__ docs/users_guide/glasgow_exts.rst:papers `__ docs/users_guide/glasgow_exts.rst:Haskell `__" docs/users_guide/glasgow_exts.rst:2 `__. libraries/base/Control/Concurrent/MVar.hs:-- libraries/base/GHC/Conc/Sync.hs:(). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 16:51:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 16:51:01 -0000 Subject: [GHC] #12576: Large Address space is not supported on Windows (was: Large Address space is unenable-able on Windows.) In-Reply-To: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> References: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> Message-ID: <059.f33f4adf4ce8c95db2d41124054b1c65@haskell.org> #12576: Large Address space is not supported on Windows ----------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12573 #12495 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Description changed by Phyx-: @@ -1,3 +1,2 @@ - Autoconf file changes have made it impossible to enable - `USE_LARGE_ADDRESS_SPACE` for Windows, as the `--enable-large-address- - space` flag is only respected on Darwin. + `USE_LARGE_ADDRESS_SPACE` is disabled for Windows, as the `--enable-large- + address-space` flag is only respected on Darwin. @@ -8,0 +7,11 @@ + + The reason for it being disabled is described in the configure.ac file: + + ``` + Windows has VirtualAlloc MEM_RESERVE/MEM_COMMIT, however + it counts page-table space as committed memory, and so quickly + runs out of paging file when we have multiple processes reserving + 1TB of address space, we get the following error: + VirtualAlloc MEM_RESERVE 1099512676352 bytes failed: The paging file + is too small for this operation to complete. + ``` New description: `USE_LARGE_ADDRESS_SPACE` is disabled for Windows, as the `--enable-large- address-space` flag is only respected on Darwin. The general case now depends on the presence of MADV_FREE to enable large address space support. Which means all possibility of enabling this feature on Windows have been removed. The reason for it being disabled is described in the configure.ac file: ``` Windows has VirtualAlloc MEM_RESERVE/MEM_COMMIT, however it counts page-table space as committed memory, and so quickly runs out of paging file when we have multiple processes reserving 1TB of address space, we get the following error: VirtualAlloc MEM_RESERVE 1099512676352 bytes failed: The paging file is too small for this operation to complete. ``` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 16:51:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 16:51:29 -0000 Subject: [GHC] #12576: Large Address space is not supported on Windows In-Reply-To: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> References: <044.d526ad2ba15932d9a7d4b6354fdd4d6c@haskell.org> Message-ID: <059.633f15c224984d9b570e22dd667029eb@haskell.org> #12576: Large Address space is not supported on Windows ----------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12573 #12495 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Description changed by Phyx-: @@ -10,1 +10,1 @@ - ``` + {{{ @@ -17,1 +17,1 @@ - ``` + }}} New description: `USE_LARGE_ADDRESS_SPACE` is disabled for Windows, as the `--enable-large- address-space` flag is only respected on Darwin. The general case now depends on the presence of MADV_FREE to enable large address space support. Which means all possibility of enabling this feature on Windows have been removed. The reason for it being disabled is described in the configure.ac file: {{{ Windows has VirtualAlloc MEM_RESERVE/MEM_COMMIT, however it counts page-table space as committed memory, and so quickly runs out of paging file when we have multiple processes reserving 1TB of address space, we get the following error: VirtualAlloc MEM_RESERVE 1099512676352 bytes failed: The paging file is too small for this operation to complete. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 18:31:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 18:31:19 -0000 Subject: [GHC] #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used Message-ID: <051.da16cd3b89a43b31275591a6abe18c9a@haskell.org> #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I can't remember if this had been filed before but this is present in both 7.8.4 and 8.0.1: {{{ Prelude> newtype A = (****) Int }}} There is no way to use the constructor `****`: {{{ Prelude> :i A newtype A = **** Int -- Defined at :3:1 Prelude> :i **** Top level: Not in scope: ‘****’ Prelude> :t (****) :1:1: Not in scope: ‘****’ Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 22:03:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 22:03:15 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.f0c3bf4f7219402f30cf56a02da8c510@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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): Thanks. But the issue description looks unchanged. What are the new instructions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 22:26:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 22:26:39 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.cb337d70a4f19c0d4dc30206ba7841d9@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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): The instructions in the ticket are the right ones. I managed to reproduce the issue and there is no dependency on llvm. It looked like the problem was somewhere in `CorePrep` but this isn't an informed opinion, just by looking at the output of `-v5`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 22:33:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 22:33:28 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.75180a4e6c793a9f9eaa7f4be046a675@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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): But instructions look the same. Perhpas you mean `llvm-general` no longer depends on llvm, despite its name? So the instructions are unchanged but `llvm-general.git` has changed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 22:39:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 22:39:36 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.126de5f786384a60d16b15d3cf93c378@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 22:42:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 22:42:11 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.45871af833d16cd7be0a236bae273392@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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): Yes that's right. Moritz reduced the testcase and changed the URL of the repository you need to clone. If you look at the commit history of the branch it now points to, there are a lot of commits removing code. https://github.com/cocreature/llvm-general/commits/ghc-panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 23:27:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 23:27:16 -0000 Subject: [GHC] #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used In-Reply-To: <051.da16cd3b89a43b31275591a6abe18c9a@haskell.org> References: <051.da16cd3b89a43b31275591a6abe18c9a@haskell.org> Message-ID: <066.9026d1e3f640345a87735aa3a89ab152@haskell.org> #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: See #12051 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 7 23:39:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Sep 2016 23:39:04 -0000 Subject: [GHC] #9880: ghc crashes on th splices in instance context In-Reply-To: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> References: <048.f4daf5bbce32dd24217721fc99cc931b@haskell.org> Message-ID: <063.53f5e4e7047e27ee15a9844c26861b92@haskell.org> #9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 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 mentheta): Replying to [comment:2 goldfire]: > The behavior you see -- that error -- is what I'd expect. > > I had a brief go at implementing local declaration splices but soon realized that implementing this involves quite a bit of replumbing. The splices would have to break up mutually-recursive groups within class, instance, and `let` declarations, and that would require changes to several bits of HsSyn. So, I settled for just fixing the panic and waiting for someone to scream loudly that they need this feature. Hello goldfire, I've just run into the situation where I hoped `Q [Dec]` would have worked in a let binding, and it did not. I don't yet intend to scream, however, I am curious; Is there any Trac ticket in particular I could subscribe to, where I can follow any potential development on the implementation for supporting declaration splices in let bindings? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 00:29:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 00:29:10 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.1d38c18c7684c72a9d2f354d4cc55b22@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ezyang): When I validate GHC with the latest version of unix, I get a segfault. {{{ *** Error in `/home/hs01/ezyang/ghc-validate/inplace/lib/bin/haddock': free(): invalid pointer: 0x00000000022f18e0 *** ======= Backtrace: ========= /usr/lib/libc.so.6(+0x70c4b)[0x7f0860463c4b] /usr/lib/libc.so.6(+0x76fe6)[0x7f0860469fe6] /usr/lib/libc.so.6(+0x777de)[0x7f086046a7de] /home/hs01/ezyang/ghc-validate/libraries/unix/dist- install/build/libHSunix-2.7.2.0-ghc8.1.20160 905.so(__hscore_free_dirent+0x9)[0x7f0863212010] /home/hs01/ezyang/ghc-validate/libraries/unix/dist- install/build/libHSunix-2.7.2.0-ghc8.1.20160 905.so(+0x97197)[0x7f08631d5197] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 00:31:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 00:31:24 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.59d0a6c7bd843b6df90ff479fb05c0aa@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ezyang): Bug looks very simple: {{{ commit 748e3224e06638639a76cbc622e9b8c17054d5df Author: Edward Z. Yang Date: Wed Sep 7 17:31:02 2016 -0700 Fix segfault from inconsistent macro use. Signed-off-by: Edward Z. Yang diff --git a/cbits/HsUnix.c b/cbits/HsUnix.c index 08cccd5..7c72a34 100644 --- a/cbits/HsUnix.c +++ b/cbits/HsUnix.c @@ -110,7 +110,7 @@ char *__hscore_d_name( struct dirent* d ) void __hscore_free_dirent(struct dirent *dEnt) { -#if HAVE_READDIR_R +#if HAVE_READDIR_R && USE_READDIR_R free(dEnt); #endif } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 01:22:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 01:22:25 -0000 Subject: [GHC] #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used In-Reply-To: <051.da16cd3b89a43b31275591a6abe18c9a@haskell.org> References: <051.da16cd3b89a43b31275591a6abe18c9a@haskell.org> Message-ID: <066.daf2ea26092df1c9a5738c83a9fe9542@haskell.org> #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thanks Matthew! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 02:08:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 02:08:00 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.c1fdd4e3d48b00988a1407123fd3e6b5@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think the following clarifying comment might help: When declaring a type family like {{{ type family F a :: u }}} the result kind `u` is actually a ''parameter'' to `F`. This type family is the same as {{{ type family G u a :: u }}} except that in `F`, the `u` is invisible. So there are no existential kinds involved. Does this help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 04:08:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 04:08:11 -0000 Subject: [GHC] #12580: Eagerly simplify inherently-coherent instances Message-ID: <045.64d4dac46eec16d9d7eabe23f42f3139@haskell.org> #12580: Eagerly simplify inherently-coherent instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/src/TysPrim.html] explains that `~~` and `~` are "inherently coherent", so GHC can reduce them immediately to their constraints. It seems to me that certain user- written classes can also be seen to be inherently coherent in this fashion. Specifically, given {{{#!hs class constraintC => C a1 a2 ... instance constraintI => C a1 a2 ... }}} where `a1`, `a2`, etc., are type variables, `C` is inherently coherent if both of the following hold: 1. `C` has no methods whatsoever. 2. `constraintC` entails `constraintI` (so the constraints are effectively identical). I believe in these cases GHC can and probably should reduce `C a1 a2` immediately to `constraintC`. Condition (2) is more general that we really need; in realistic cases, the constraints will be identical up to alpha renaming because most people don't write obfuscated code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 05:42:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 05:42:56 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.8ac1200b98bdc87f9da1f3e07f486134@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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 cocreature): The only changes I made to the instructions are changing the url and the branch which now point to the one linked by mpickering where I tried to remove as much code as possible and stub things with undefined while still being able to reproduce this. I also removed the requirement to install LLVM from the instructions since this is no longer necessary. Also it is now only a single cabal project so it is easy to just use a normal `cabal build` rather than `cabal new-build` and you can reproduce the issue that way too (I tried this). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 08:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 08:04:16 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.3733fe737d5beeb323dbee355c036846@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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 adamgundry): I agree that we should make the inaccessible code error into a warning. I'm on the fence as to whether that warning should automatically be suppressed in instance methods, or whether users should simply have to disable it themselves. It would be very useful for it automatically to be suppressed when checking generated code. See also #11066, #8128, #8740. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 10:15:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 10:15:22 -0000 Subject: [GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.5f0766142edbf7ea4bf5f285441df1c1@haskell.org> #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #12469 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * failure: Compile-time crash => Incorrect result at runtime * version: 7.10.3 => 8.0.1 * related: => #12469 Comment: Replying to [comment:1 trommler]: > This could be #12469. I am going to check. I applied the patch for #12469 to ghc 8.0.1 and rebuilt all of Haskell LTS nightly and still about 40 to 50 packages fail with the segmentation fault reported here. Rebuilding succeeds most of the time. I am not ruling out #12469 yet as @rrnewton remarked in comment 12 that a write (store-store) barrier might be missing in array writes too. Note: openSUSE's ghc 7.10.3 is patched with the native code generator and the patch in SMP.h for atomic operations. I am setting the version field to 8.0.1 to avoid confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 10:18:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 10:18:50 -0000 Subject: [GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.7d54cf3f2996d6a784656e7ca25d2962@haskell.org> #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #12469 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): The panic in `mkFastStringWith` does not depend on debuginfo rpms being installed. I have also seen it happen on the build service but only rarely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 13:17:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 13:17:04 -0000 Subject: [GHC] #12580: Eagerly simplify inherently-coherent instances In-Reply-To: <045.64d4dac46eec16d9d7eabe23f42f3139@haskell.org> References: <045.64d4dac46eec16d9d7eabe23f42f3139@haskell.org> Message-ID: <060.b6e1963c6e9d307cdd1aa4b43c912de5@haskell.org> #12580: Eagerly simplify inherently-coherent instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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 goldfire): For the instance to be accepted, don't we also need (`constraintI` implies `constraintC`)? Perhaps that's what you mean by the constraints being identical. To rephrase your proposal, you wish solving for `C` to pretend that `IncoherentInstances` is in effect, reducing to `constraintC`/`constraintI` even when another given is in scope. This seems plausible at first glance. Do you have a full concrete example of where this would change behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 14:15:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 14:15:45 -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.a3e054c19f2998fb53577f7c2bb8af9e@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by alexvieth): Sorry for the delay, new contract is keeping my occupied. comment:17 certainly shows a shortcoming in the patch for #11348. No sense reopening it though, this ticket can supersede it (its summary could use a revision for scope). Thanks for the wiki writeup mpickering. It's accurate and I have nothing to add right now. That section called "The Solution" is a tall order! Replying to [comment:20 goldfire]: > This would then put ill-kinded equalities into the context. I think it would be awfully hard to avoid getting GHC to loop or do other silly things with a bad context. Perhaps you could squeeze this through, but I'm very skeptical. > > Or am I misunderstanding something? You're probably not misunderstanding. I'm just sounding off ideas and I'm no expert on GHC's type checker. Putting ill-kinded equalities into the context sounds irresponsible yes, but they'll all be of the form `F k ~ l` for some open type family `F` (or similar for higher arities). Does this fact help at all? Could you come up with a case where an ill-kinded equality of this form would wreak havoc? How about a variation on that suggestion of mine? A kind of lazy evaluation for open type families in kinds. While type checking other declarations, rather than assuming the (possibly ill-kinded) equalities arising from open type families to be true, defer them until after all declarations are checked. Then we end up with a set of equalities featuring open type family constructors which must be solved using all open type family instances. So in the `FieldCount` example from comment:17, repeated here for convenience: {{{#!hs {-# LANGUAGE TypeInType, GADTs, TypeFamilies #-} import Data.Kind (Type) data N = Z | S N data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family FieldCount (t :: Type) :: N type family FieldType (t :: Type) (i :: Fin (FieldCount t)) :: Type data T type instance FieldCount T = S (S (S Z)) type instance FieldType T FZ = Int type instance FieldType T (FS FZ) = Bool type instance FieldType T (FS (FS FZ)) = String }}} The only declarations which give rise to a deferred kind equality are the `FieldType` instances. - `type instance FieldType T FZ = Int` yields `S n0 ~ FieldCount T` - `type instance FieldType T (FS FZ) = Bool` yields `S (S n1) ~ FieldCount T` - `type instance FieldType T (FS (FS FZ)) = String` yields `S (S (S n2)) ~ FieldCount T` These don't stop type checking dead, they're just tucked away for later and `type instance FieldCount T = S (S (S Z))` will eventually be checked (either before or after, we don't care) and available when those three equalities are solved. The program will therefore pass: `n0 := (S (S Z))`, `n1 := S Z`, `n2 := Z`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 14:28:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 14:28:47 -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.cb9af2f172d543edbe22649120e63dc6@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by goldfire): I still am in favor of my comment:13 and comment:15. The other approaches seem a bit ad-hoc and perhaps are approximations of my proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 14:30:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 14:30:00 -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.f633c194e537e9c8d076ef52f50b2730@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps that last comment was a bit strongly worded, upon re-reading. I do think comment:25 may be onto something -- waiting until later to solve equality constraints is something GHC does well -- but I don't have a clear enough specification of comment:25 in my head to really analyze. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:11:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:11:56 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.4fd87faebd578fce8aa5873a9026fdcb@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1-rc2 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:D2515 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"feaa31fbc41685d69045ac8d34be4e18f4f27ffd/ghc" feaa31fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feaa31fbc41685d69045ac8d34be4e18f4f27ffd" Remove references to -XRelaxedPolyRec Test Plan: Read it Reviewers: dfeuer, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2515 GHC Trac Issues: #11691 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:11:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:11:56 -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.ad6292c1776737a674e5e0a1d66f6ee8@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.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5eab6a0da5f22a47d04b97a0ec8988346675b33b/ghc" 5eab6a0d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5eab6a0da5f22a47d04b97a0ec8988346675b33b" Document meaning of order of --package-db flags, fixes #12485. Test Plan: none Reviewers: austin, niteria, bgamari Reviewed By: niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2514 GHC Trac Issues: #12485 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:11:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:11:56 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.9d01fa9f512c1068093f233a40321448@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dcc49044e8ac5b905955f99b042449635eb47e64/ghc" dcc4904/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dcc49044e8ac5b905955f99b042449635eb47e64" Add failing testcase for #12433 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2517 GHC Trac Issues: #11433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:11:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:11:56 -0000 Subject: [GHC] #11433: sphinx: Error: source directory and destination directory are same. In-Reply-To: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> References: <046.a16688ae7dd42e6324005a26cbb821ab@haskell.org> Message-ID: <061.49aea1e53a5be317041a8be99c58b2be@haskell.org> #11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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): Phab:D1782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dcc49044e8ac5b905955f99b042449635eb47e64/ghc" dcc4904/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dcc49044e8ac5b905955f99b042449635eb47e64" Add failing testcase for #12433 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2517 GHC Trac Issues: #11433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:39:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:39:03 -0000 Subject: [GHC] #11990: Custom Type Error not getting triggered in the nested Type function call In-Reply-To: <047.cd64e02ac6207e6c5247bec38dfaa3ba@haskell.org> References: <047.cd64e02ac6207e6c5247bec38dfaa3ba@haskell.org> Message-ID: <062.597a320c1cd7b98bc600d8debfd16a08@haskell.org> #11990: Custom Type Error not getting triggered in the nested Type function call -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): For the record the patch in comment:3 was merged to `ghc-8.0` as 23be8c99a411f846ae7668682259bcad2a507122. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:40:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:40:37 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.4c38c0cbebeeaee30df0d403de3a9a9d@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1-rc2 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:D2515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 15:43:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 15:43:53 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.186721853b5a807f9705bcbcf8563749@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): While working on Phab:D1259 I came across another example of this issue (NB it requires my patch to trigger). The idea in that patch is to avoid inlining `String` literals and share them as top-level values instead. In order to keep using the REWRITE rules, we pretend that `unpackCString#` is CONLIKE. This has a side-effect of making GHC float the unboxed string literal out into a separate let-binder, which then prevents us from floating the `unpackCString#` application to the top-level, as unboxed literals aren't allowed there. Here's a simple example that triggers the behavior with the Phab:D1259 patch, but properly floats the `String`s on master. {{{ module Foo where draw xs = a ++ b ++ xs [a,b] = ["aa", "bb"] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 16:12:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 16:12:07 -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.03e15e2d422434953cbf30ebf96cf2b9@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: | -------------------------------------+------------------------------------- Comment (by goldfire): The idea in comment:39 has grown on me. So let me turn this into a concrete proposal: 1. Relax Haskell's current restriction around capitalized identifiers. That is, any old variable can now begin with a capitalized letter or a colon. Capitalized variables can be defined only by function-definition syntax, never by patterns. That is, `Foo = 5` is OK, as is `Bar x = x + 2`. On the other hand, `Just Quux = listToMaybe blurgh` would not be OK. 2. Unidirectional pattern synonyms remain unchanged. 3. If a bidirectional (whether implicitly bidirectional or explicitly bidirectional) pattern synonym is defined in a module, and that module defines no variable of the same (capitalized) name as the pattern, then the pattern synonym declaration also serves as a declaration of the capitalized identifier. The type of the capitalized identifier will be derived from the type of the pattern synonym, concatenating the required and provided contexts. 4. A pattern synonym signature in a `-boot` file declares only the pattern synonym, not the capitalized identifier. 5. Export and import of capitalized identifiers will need a new keyword prefix in export/import lists. I propose `constructor`, analogous to `pattern` today. 6. Exporting/importing a pattern synonym with an implicitly-declared capitalized identifier associated with it will also export/import that capitalized identifier. This is mostly for backward compatibility, but it also seems quite convenient. What do we think? Some of this design is motivated by backward compatibility with existing pattern synonyms -- we could imagine having pattern synonyms always be unidirectional and asking users to declare both ways explicitly. But this is also inconvenient for the common case. I think this proposal balances the different needs nicely. It also suggests that we can do away entirely with "builders" in the implementation, as a capitalized identifier is just a normal variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 16:36:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 16:36:36 -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.c783080219dda159e41beb60e8406c27@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:45 goldfire]: > The idea in comment:39 has grown on me. So let me turn this into a concrete proposal: > > 1. Relax Haskell's current restriction around capitalized identifiers. That is, any old variable can now begin with a capitalized letter or a colon. Capitalized variables can be defined only by function-definition syntax, never by patterns. That is, `Foo = 5` is OK, as is `Bar x = x + 2`. On the other hand, `Just Quux = listToMaybe blurgh` would not be OK. I like the general theme very much, but I think we use the `constructor` keyword to introduce capitalized identifiers as well as to export them unbundled. This distinguishes them syntactically from pattern bindings and makes it immediately obvious that something strange is happening. I agree that we don't need to allow them to be defined using pattern bindings; that would complicate things with little benefit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 16:46:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 16:46:18 -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.aeb4caef319e8edc4b8d3e837ac1d658@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: | -------------------------------------+------------------------------------- Comment (by dmcclean): Does this proposed use of `constructor` as a keyword conflict with the use proposed in #11080? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 17:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 17:04:05 -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.10771dc10b976f9e2b3f8d4d17892180@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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:47 dmcclean]: > Does this proposed use of `constructor` as a keyword conflict with the use proposed in #11080? I doubt it. This use would never come after `data`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 17:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 17:13:26 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.868842ef22859c82a8d06bc13aae9425@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | 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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: => Iceland_jack Comment: Code from discussion thread [https://github.com/ramda/ramda- lens/pull/2#issuecomment-181955004 comment] would be valid: > The only way to write such a function is to use methods in the `Profunctor` interface of which there is only 1. Thus, if we have any value `i :: Iso s a` we know it must be of the form > > {{{#!hs > i = dimap fwd bck > where > fwd :: s -> a > bck :: a -> s > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 19:06:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 19:06:21 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.489d0c6558f6c16e1e711068676f6110@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Edward Z. Yang ): In [changeset:"a8238a4eb628dcab93e19021b27c0cf2b38ef7d0/ghc" a8238a4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8238a4eb628dcab93e19021b27c0cf2b38ef7d0" Update unix submodule to latest HEAD. Fixes readdir validation error (fixes #12572). Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 19:07:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 19:07:11 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.c4f7a94a161227bc5b638cabf309d523@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: Component: Core Libraries | 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 ezyang): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 21:36:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 21:36:37 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.25e985ac4a4e864f997d6a21db893e7f@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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 propose (comment:31) to report an error for a Given insoluble (e.g. `Int ~ Bool`) only if * there is an enclosing pattern match * that binds some equalities Otherwise silently ignore Given insolubles. That will resolve all the complaints here, I think. It's possible that we should warn; but it'd have to be not in `-Wall` because in some cases (like the instance one above) you can't "fix" the program to avoid the warning. So for now I'm inclined just to silently ignore. OK? Patch in preparation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 21:46:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 21:46:13 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.1db6a8ec9b513759d73f3687bc7ebffd@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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 dfeuer): Replying to [comment:34 simonpj]: > I propose (comment:31) to report an error for a Given insoluble (e.g. `Int ~ Bool`) only if > * there is an enclosing pattern match > * that binds some equalities > > Otherwise silently ignore Given insolubles. That will resolve all the complaints here, I think. > > It's possible that we should warn; but it'd have to be not in `-Wall` because in some cases (like the instance one above) you can't "fix" the program to avoid the warning. So for now I'm inclined just to silently ignore. > > OK? Patch in preparation. > > Simon Can you give an example or two of code that will still produce an error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 23:18:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 23:18:44 -0000 Subject: [GHC] #12581: Testsuite segfaults on OS X Message-ID: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> #12581: Testsuite segfaults on OS X --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: --------------------------------------+--------------------------------- {{{ git bisect start # bad: [34010dbe77ac405da6c671c3feb3573d0d025379] Derive the Generic instance in perf/compiler/T5642 git bisect bad 34010dbe77ac405da6c671c3feb3573d0d025379 # good: [b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c] Fix kind generalisation for pattern synonyms git bisect good b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c # skip: [39103062e50249da857761d0eaca325aa428e446] Add -XStaticPointers to the flag reference. git bisect skip 39103062e50249da857761d0eaca325aa428e446 # good: [0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d] RtsUtils: Use `size_t` instead of `int` where appropriate git bisect good 0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d # good: [bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b] Remote GHCi: separate out message types git bisect good bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b # bad: [4036c1f110578f8e2813295116b79a5a06e2bf59] Testsuite: fix T10482a git bisect bad 4036c1f110578f8e2813295116b79a5a06e2bf59 # bad: [6cedef01e00e95517a546a72592ba6ff07bac605] Test Trac #12133 git bisect bad 6cedef01e00e95517a546a72592ba6ff07bac605 # bad: [9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff] Add a new determinism test git bisect bad 9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff # good: [206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a] Testsuite: simplify extra_file handling git bisect good 206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a # bad: [dc62a22279846abe7e84ef57896f0a38f6b7b845] Wibble error message for #11471 git bisect bad dc62a22279846abe7e84ef57896f0a38f6b7b845 # bad: [6b3b631e90aa5f6f9322efcb81e9b13d14d087f0] Testsuite: run all indexed-types ways on ./validate --slow git bisect bad 6b3b631e90aa5f6f9322efcb81e9b13d14d087f0 # bad: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly git bisect bad 58f0086b70f2f409b9f88de1611efcf18756f9e5 # good: [bafd615e40c2a11af1390e736f6122033eecc4c6] Testsuite: do not print timeout message git bisect good bafd615e40c2a11af1390e736f6122033eecc4c6 # first bad commit: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 23:21:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 23:21:15 -0000 Subject: [GHC] #12581: Testsuite segfaults on OS X In-Reply-To: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> References: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> Message-ID: <061.f164679dd58979e2e7614ea9c6128792@haskell.org> #12581: Testsuite segfaults on OS X ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: 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: | ---------------------------------+-------------------------------------- Description changed by bgamari: @@ -0,0 +1,4 @@ + `derefnull` and ? fail. + + = Bisection log + New description: `derefnull` and ? fail. = Bisection log {{{ git bisect start # bad: [34010dbe77ac405da6c671c3feb3573d0d025379] Derive the Generic instance in perf/compiler/T5642 git bisect bad 34010dbe77ac405da6c671c3feb3573d0d025379 # good: [b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c] Fix kind generalisation for pattern synonyms git bisect good b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c # skip: [39103062e50249da857761d0eaca325aa428e446] Add -XStaticPointers to the flag reference. git bisect skip 39103062e50249da857761d0eaca325aa428e446 # good: [0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d] RtsUtils: Use `size_t` instead of `int` where appropriate git bisect good 0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d # good: [bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b] Remote GHCi: separate out message types git bisect good bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b # bad: [4036c1f110578f8e2813295116b79a5a06e2bf59] Testsuite: fix T10482a git bisect bad 4036c1f110578f8e2813295116b79a5a06e2bf59 # bad: [6cedef01e00e95517a546a72592ba6ff07bac605] Test Trac #12133 git bisect bad 6cedef01e00e95517a546a72592ba6ff07bac605 # bad: [9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff] Add a new determinism test git bisect bad 9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff # good: [206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a] Testsuite: simplify extra_file handling git bisect good 206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a # bad: [dc62a22279846abe7e84ef57896f0a38f6b7b845] Wibble error message for #11471 git bisect bad dc62a22279846abe7e84ef57896f0a38f6b7b845 # bad: [6b3b631e90aa5f6f9322efcb81e9b13d14d087f0] Testsuite: run all indexed-types ways on ./validate --slow git bisect bad 6b3b631e90aa5f6f9322efcb81e9b13d14d087f0 # bad: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly git bisect bad 58f0086b70f2f409b9f88de1611efcf18756f9e5 # good: [bafd615e40c2a11af1390e736f6122033eecc4c6] Testsuite: do not print timeout message git bisect good bafd615e40c2a11af1390e736f6122033eecc4c6 # first bad commit: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 23:45:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 23:45:48 -0000 Subject: [GHC] #12581: Testsuite segfaults on OS X In-Reply-To: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> References: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> Message-ID: <061.f088227553191659f5ec3766f6364c8f@haskell.org> #12581: Testsuite segfaults on OS X ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: 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: | ---------------------------------+-------------------------------------- Description changed by bgamari: @@ -1,1 +1,32 @@ - `derefnull` and ? fail. + `derefnull` fails with, + {{{ + =====> derefnull(normal) 1 of 3 [0, 0, 0] + cd "./rts/derefnull.run" && "/Users/bgamari/ghc/inplace/test spaces + /ghc-stage2" -o derefnull derefnull.hs -dcore-lint -dcmm-lint -dno-debug- + output -no-user-package-db -rtsopts -fno-warn-missed-specialisations + -fshow-warning-groups + + cd "./rts/derefnull.run" && ./derefnull + Actual stderr output differs from expected: + --- /dev/null 2016-09-09 02:44:22.000000000 +0300 + +++ ./rts/derefnull.run/derefnull.run.stderr.normalised 2016-09-09 + 02:44:24.000000000 +0300 + @@ -0,0 +1 @@ + +/bin/sh: line 1: 91959 Segmentation fault: 11 ./derefnull + }}} + + and `divbyzero` fails with, + {{{ + =====> divbyzero(normal) 2 of 3 [0, 1, 0] + cd "./rts/divbyzero.run" && "/Users/bgamari/ghc/inplace/test spaces + /ghc-stage2" -o divbyzero divbyzero.hs -dcore-lint -dcmm-lint -dno-debug- + output -no-user-package-db -rtsopts -fno-warn-missed-specialisations + -fshow-warning-groups + cd "./rts/divbyzero.run" && ./divbyzero + Actual stderr output differs from expected: + --- /dev/null 2016-09-09 02:44:24.000000000 +0300 + +++ ./rts/divbyzero.run/divbyzero.run.stderr.normalised 2016-09-09 + 02:44:24.000000000 +0300 + @@ -0,0 +1 @@ + +/bin/sh: line 1: 91975 Floating point exception: 8 ./divbyzero + }}} New description: `derefnull` fails with, {{{ =====> derefnull(normal) 1 of 3 [0, 0, 0] cd "./rts/derefnull.run" && "/Users/bgamari/ghc/inplace/test spaces /ghc-stage2" -o derefnull derefnull.hs -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups cd "./rts/derefnull.run" && ./derefnull Actual stderr output differs from expected: --- /dev/null 2016-09-09 02:44:22.000000000 +0300 +++ ./rts/derefnull.run/derefnull.run.stderr.normalised 2016-09-09 02:44:24.000000000 +0300 @@ -0,0 +1 @@ +/bin/sh: line 1: 91959 Segmentation fault: 11 ./derefnull }}} and `divbyzero` fails with, {{{ =====> divbyzero(normal) 2 of 3 [0, 1, 0] cd "./rts/divbyzero.run" && "/Users/bgamari/ghc/inplace/test spaces /ghc-stage2" -o divbyzero divbyzero.hs -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups cd "./rts/divbyzero.run" && ./divbyzero Actual stderr output differs from expected: --- /dev/null 2016-09-09 02:44:24.000000000 +0300 +++ ./rts/divbyzero.run/divbyzero.run.stderr.normalised 2016-09-09 02:44:24.000000000 +0300 @@ -0,0 +1 @@ +/bin/sh: line 1: 91975 Floating point exception: 8 ./divbyzero }}} = Bisection log {{{ git bisect start # bad: [34010dbe77ac405da6c671c3feb3573d0d025379] Derive the Generic instance in perf/compiler/T5642 git bisect bad 34010dbe77ac405da6c671c3feb3573d0d025379 # good: [b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c] Fix kind generalisation for pattern synonyms git bisect good b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c # skip: [39103062e50249da857761d0eaca325aa428e446] Add -XStaticPointers to the flag reference. git bisect skip 39103062e50249da857761d0eaca325aa428e446 # good: [0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d] RtsUtils: Use `size_t` instead of `int` where appropriate git bisect good 0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d # good: [bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b] Remote GHCi: separate out message types git bisect good bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b # bad: [4036c1f110578f8e2813295116b79a5a06e2bf59] Testsuite: fix T10482a git bisect bad 4036c1f110578f8e2813295116b79a5a06e2bf59 # bad: [6cedef01e00e95517a546a72592ba6ff07bac605] Test Trac #12133 git bisect bad 6cedef01e00e95517a546a72592ba6ff07bac605 # bad: [9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff] Add a new determinism test git bisect bad 9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff # good: [206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a] Testsuite: simplify extra_file handling git bisect good 206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a # bad: [dc62a22279846abe7e84ef57896f0a38f6b7b845] Wibble error message for #11471 git bisect bad dc62a22279846abe7e84ef57896f0a38f6b7b845 # bad: [6b3b631e90aa5f6f9322efcb81e9b13d14d087f0] Testsuite: run all indexed-types ways on ./validate --slow git bisect bad 6b3b631e90aa5f6f9322efcb81e9b13d14d087f0 # bad: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly git bisect bad 58f0086b70f2f409b9f88de1611efcf18756f9e5 # good: [bafd615e40c2a11af1390e736f6122033eecc4c6] Testsuite: do not print timeout message git bisect good bafd615e40c2a11af1390e736f6122033eecc4c6 # first bad commit: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 23:49:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 23:49:21 -0000 Subject: [GHC] #12581: Testsuite segfaults on OS X In-Reply-To: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> References: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> Message-ID: <061.86bb1af7faa250fe67da6e940477bb07@haskell.org> #12581: Testsuite segfaults on OS X ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: 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 bgamari): While I was expecting the backtrace to place the problem in the RTS, it appears that this isn't the case, {{{ ghc-mini:rts bgamari$ sudo lldb ./derefnull (lldb) target create "./derefnull" Current executable set to './derefnull' (x86_64). (lldb) run Process 92160 launched: './derefnull' (x86_64) Process 92160 stopped * thread #1: tid = 0xa865a5, 0x000000010003f435 derefnull`c6ba_info + 21, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x000000010003f435 derefnull`c6ba_info + 21 derefnull`c6ba_info: -> 0x10003f435 <+21>: movq (%rax), %rax 0x10003f438 <+24>: leaq 0x30ad31(%rip), %rbx ; ghczmprim_GHCziTypes_Izh_con_info 0x10003f43f <+31>: movq %rbx, -0x8(%r12) 0x10003f444 <+36>: movq %rax, (%r12) (lldb) bt * thread #1: tid = 0xa865a5, 0x000000010003f435 derefnull`c6ba_info + 21, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x000000010003f435 derefnull`c6ba_info + 21 frame #1: 0x00000001000683f8 derefnull`base_GHCziBase_bindIO1_info + 64 frame #2: 0x00000001003c25d1 derefnull`s1Y5_closure + 1 frame #3: 0x0000000100371cc0 derefnull`stg_catch_frame_info_dsp + 16 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 23:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 23:50:40 -0000 Subject: [GHC] #12581: Testsuite segfaults on OS X In-Reply-To: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> References: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> Message-ID: <061.aa157d214798c80628e554d75af3663b@haskell.org> #12581: Testsuite segfaults on OS X ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: 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): * cc: thomie (added) Comment: Ahh, but this test is indeed supposed to crash (via `peek nullPtr`) and is intended to test the RTS's signal handler. I guess this 58f0086b70f2f409b9f88de1611efcf18756f9e5 somehow broke this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 8 23:52:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Sep 2016 23:52:07 -0000 Subject: [GHC] #12581: Testsuite segfaults on OS X In-Reply-To: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> References: <046.13cc8ed70afa895715c5f816ad32c529@haskell.org> Message-ID: <061.b5d8ead981334e531a23028d7be94c20@haskell.org> #12581: Testsuite segfaults on OS X ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: 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 bgamari): Ahh, well, I suppose the problem is pretty obvious; the patch in question changes the redirection behavior and the failures are stderr mismatches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 08:05:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 08:05:09 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.c8ff48ea10d6a6911c580d157b5b4f67@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler Comment: It seems there is a write barrier missing here in `StgCmmPrim.hs`: {{{ emit (setInfo addr (CmmLit (CmmLabel mkMAP_DIRTY_infoLabel))) -- the write barrier. We must write a byte into the mark table: -- bits8[a + header_size + StgMutArrPtrs_size(a) + x >> N] emit $ mkStore ( }}} I am going to add it an see what it is doing to #12537. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 08:12:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 08:12:56 -0000 Subject: [GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.4c87554ae5784287ed6da36f6df2c8ef@haskell.org> #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * blockedby: => 12469 * related: #12469 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 08:25:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 08:25:51 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.c7ff3a47abca191a67174255dea637f6@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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): > Can you give an example or two of code that will still produce an error? Yes indeed: see comment:31. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 10:41:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 10:41:00 -0000 Subject: [GHC] #12582: HSOC Eventlog live profiling Message-ID: <047.39614347d19ac7526209a37004883cae@haskell.org> #12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: eventlog | Operating System: Unknown/Multiple profile hsoc | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, it is ticket for results of my Haskell Summer of Code 2016 project [1]. The goal is provide feature for redirection of events to external profilers without an application termination. Proposed changes: * Changing eventlog file descriptor in runtime. {{{#!c /* * Set custom file stream for global event log sink. * * The function overwrites previous event log file pointer. Previouss * sink is closed only if closePrev flag is on. * * Writing to the sink is protected by global mutex. * * The function puts header to the new sink only when emitHeader flag * is on. User might not want the header if it is switching to * already existed eventlog handle that was switched away recently. */ void rts_setEventLogSink(FILE *sink, StgBool closePrev, StgBool emitHeader); /* * Get current file stream that is used for global event log sink. * * You shouldn't do anything with the pointer until * rts_setEventLogSink(otherFileOrNull, false) is called. After that * you can do anything with the file stream. */ FILE* rts_getEventLogSink(void); }}} * Special flag `-lm` for RTS to store eventlog in memory chunks. User space functions to retrieve the chunks from memory. {{{#!c /* * If RTS started with '-lm' flag then eventlog is stored in memory buffer. * * The function allows to pop chunks of the buffer. Return value of 0 means * that there is no any filled chunk of data. * * If the function returns nonzero value the parameter contains full chunk * of eventlog data with size of the returned value. Caller must free the * buffer, the buffer isn't referenced anywhere anymore. * * If nobody calls the function with '-lm' flag then the memory is kinda * to be exhausted. */ StgWord64 rts_getEventLogChunk(StgInt8** ptr); }}} * Feature for dynamic resize of eventlog buffers. {{{#!c /* * Reallocate inner buffers to match the new size. The size should be not * too small to contain at least one event. * * If RTS started with '-lm' the chunks of memory buffer is also resized. */ void rts_resizeEventLog(StgWord64 size); /* * Return current size of eventlog buffers. */ StgWord64 rts_getEventLogBuffersSize(void); }}} * Bindings to new features in `Debug.Trace` in `base` package. {{{#!hs -- | The 'setEventLogCFile' function changes current sink of the eventlog, if eventlog -- profiling is available and enabled at runtime. -- -- The second parameter defines whether old sink should be finalized and closed or not. -- Preserving it could be helpful for temporal redirection of eventlog data into not -- standard sink and then restoring to the default file sink. -- -- The third parameter defines whether new header section should be emitted to the new -- sink. Emitting header to already started eventlog streams will corrupt the structure -- of eventlog format. -- -- The function is more low-level than 'setEventLogHandle' but doesn't recreate underlying -- file descriptor and is intended to use with 'getEventLogCFile' to save and restore -- current sink of the eventlog. -- -- @since 4.10.0.0 setEventLogCFile :: Ptr CFile -> Bool -> Bool -> IO () -- | The 'getEventLogCFile' function returns current sink of the eventlog, if eventlog -- profiling is available and enabled at runtime. -- -- The function is intented to be used with 'setEventLogCFile' to save and restore -- current sink of the eventlog. -- -- @since 4.10.0.0 getEventLogCFile :: IO (Ptr CFile) -- | Setting size of internal eventlog buffers. The size should be not -- too small to contain at least one event. -- -- If RTS started with '-lm' the chunks of memory buffer is also resized. -- -- The larger the buffers the lesser overhead from event logging, but -- larger delays between data dumps. -- -- See also: 'getEventLogChunk', 'getEventLogBufferSize' setEventLogBufferSize :: Word -> IO () -- | Getting size of internal eventlog buffers. -- -- See also: 'setEventLogBufferSize', 'getEventLogChunk' getEventLogBufferSize :: IO Word -- | Get next portion of the eventlog data. -- -- If RTS started with '-lm' flag then eventlog is stored in memory buffer. -- -- The function allows to pop chunks out of the buffer. Return value of Nothing -- means that there is no any filled chunk of data. -- -- If the function returns nonzero value the parameter contains full chunk -- of eventlog data with size of the returned value. Caller must free the -- buffer with 'free' from 'Foreign.Marshal.Alloc', the buffer isn't referenced -- anywhere anymore. -- -- If nobody calls the function with '-lm' flag on then the memory is kinda -- to be exhausted. -- -- If '-lm' flag is off, the function returns always 'Nothing'. -- -- See also: 'setEventLogBufferSize' getEventLogChunk :: IO (Maybe CStringLen) }}} References: 1. [http://ncrashed.github.io/blog/posts/2016-06-12-hsoc-acceptance.html HSOC project description] 2. [http://ncrashed.github.io/blog/posts/2016-06-22-hsoc-rts.html Design choices for implementation] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 10:41:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 10:41:58 -0000 Subject: [GHC] #12582: HSOC Eventlog live profiling In-Reply-To: <047.39614347d19ac7526209a37004883cae@haskell.org> References: <047.39614347d19ac7526209a37004883cae@haskell.org> Message-ID: <062.3cd03f71fdc3cd5cba146b778e9b9cec@haskell.org> #12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: eventlog | profile hsoc 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 NCrashed): The diffs will be uploaded to Phabricator shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 10:44:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 10:44:27 -0000 Subject: [GHC] #12582: HSOC Eventlog live profiling In-Reply-To: <047.39614347d19ac7526209a37004883cae@haskell.org> References: <047.39614347d19ac7526209a37004883cae@haskell.org> Message-ID: <062.099fe5c64b1de4f08113ade29f5926d9@haskell.org> #12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: eventlog | profile hsoc 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): Thanks for opening a ticket, I'll comment on the diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 11:35:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 11:35:51 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.0248e9c18fa301b37cc6450cdef8e9b9@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: closed => new * owner: facundo.dominguez => * differential: Phab:D2286 => Phab:D2286 Phab:D2519 * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 11:36:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 11:36:38 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.6a1e38b89fcfe3f951d093592857b4ff@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * owner: => facundo.dominguez -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 11:42:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 11:42:54 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.978aa9437edcfee4e0e36c5edfc16790@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch Comment: After last fix, {{{ g :: Int g = 0 f = $(do addModFinalizer $ reify (mkName "g") >>= ... [| return () |] ) }}} couldn't find `g`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 14:28:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 14:28:35 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.ff2f938bb71541944bab891a198471ab@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Comment (by goldfire): When you set the status as `patch`, do you mean that you've fixed this shortcoming? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 14:46:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 14:46:44 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.5ae0ba1d9b4ed789ac4116d1a68060ea@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I hope so in a patch I submitted today https://phabricator.haskell.org/D2519. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 17:32:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 17:32:10 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.03cd0071d485c6980a84d2ce156089f1@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: Hadn't noticed that the ticket wasn't set on the phabricator diff correctly before I committed. In any case, committed as 1b5f9207a649a64a1bba20b0283253425f9208d7 Thanks for the report and fix bitonic! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 17:32:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 17:32:30 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.37dc3a2ad1bc2478d0896f91ae687b6a@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | Status: merge 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 18:49:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 18:49:52 -0000 Subject: [GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic Message-ID: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> #12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- 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: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On GHC 8.0.1 and HEAD, the following code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} module Bug where import Data.Ix data Foo a where MkFoo :: (Eq a, Ord a, Ix a) => Foo a deriving instance Ix (Foo a) }}} results in a GHC panic: {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160908 for x86_64-unknown-linux): Prelude.foldl1: empty list Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The culprit is [http://git.haskell.org/ghc.git/blob/1b5f9207a649a64a1bba20b0283253425f9208d7:/compiler/typecheck/TcGenDeriv.hs#l911 here], in the code which generates an `inRange` implementation for a derived `Ix` instance for a datatype with exactly one constructor. Normally, this code wouldn't be reached for a datatype like `data Bar = MkBar`, since GHC would treat that as an enumeration and generate different code for `inRange`. That is, normally, the only time this `foldl1` would be reached is if we were dealing with exactly one constructor with one or more arguments (making the use of `foldl1` justified). However, there's a catch: the function which checks if a datatype is an enumeration (`isEnumerationTyCon`) will reject any GADT-like datatypes. `gen_Ix_binds` uses `isEnumerationTyCon` [http://git.haskell.org/ghc.git/blob/1b5f9207a649a64a1bba20b0283253425f9208d7:/compiler/typecheck/TcGenDeriv.hs#l800 here] to determine whether to use the case that goes through `foldl1` or not, and since `Foo` as above is a GADT, it defaults to the case that uses `foldl1`. What's interesting is that this bug is //not// present in GHC 7.10.3 and earlier. Instead, it will simply error out with an appropriate error message: {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:1: Can't make a derived instance of ‘Ix (Foo a)’: ‘Foo’ must be an enumeration type (an enumeration consists of one or more nullary, non-GADT constructors) or ‘Foo’ must have precisely one constructor In the stand-alone deriving instance for ‘Ix (Foo a)’ }}} That's because before `gen_Ix_binds` is reached, the `sideConditions` function [http://git.haskell.org/ghc.git/blob/1b5f9207a649a64a1bba20b0283253425f9208d7:/compiler/typecheck/TcDeriv.hs#l1330 checks] if the datatype meets the requirements imposed by `isEnumerationTyCon` or `isProductTyCon`. In GHC 7.10.3 and earlier, the implementation of `isProductTyCon` is: {{{#!hs isProductTyCon :: TyCon -> Bool -- True of datatypes or newtypes that have -- one, vanilla, data constructor isProductTyCon tc@(AlgTyCon {}) = case algTcRhs tc of DataTyCon{ data_cons = [data_con] } -> isVanillaDataCon data_con NewTyCon {} -> True _ -> False isProductTyCon (TupleTyCon {}) = True isProductTyCon _ = False }}} But as a result of [ this commit] of Simon's, the implementation of `isProductTyCon` in GHC 8.0.1 and later is: {{{#!hs isProductTyCon :: TyCon -> Bool -- True of datatypes or newtypes that have -- one, non-existential, data constructor -- See Note [Product types] isProductTyCon tc@(AlgTyCon {}) = case algTcRhs tc of DataTyCon{ data_cons = [data_con] } -> null (dataConExTyVars data_con) NewTyCon {} -> True _ -> False isProductTyCon (TupleTyCon {}) = True isProductTyCon _ = False }}} Before, `isProductTyCon` rejected all GADTs, but now, it only checks if there are no existentially quantified type variables, which allows `Foo` to slip through the cracks. ----- The question is: how should we fix this? Should we generate the code the same code as we do for enumerations in this case? i.e., {{{#!hs instance Ix (Foo a) where ... inRange (a_a27l, b_a27m) c_a27n = case ($con2tag_PPfAWSX7zu8vtuLB8bgeJ a_a27l) of { a#_a27o -> case ($con2tag_PPfAWSX7zu8vtuLB8bgeJ b_a27m) of { b#_a27p -> case ($con2tag_PPfAWSX7zu8vtuLB8bgeJ c_a27n) of { c#_a27q -> (&&) (tagToEnum# (c#_a27q >=# a#_a27o)) (tagToEnum# (c#_a27q <=# b#_a27p)) } } } }}} Or should we generate the even-simpler definition: {{{#!hs instance Ix (Foo a) where ... inRange (MkFoo, MkFoo) MkFoo = True }}} FWIW, I think the Haskell Report [https://www.haskell.org/onlinereport/haskell2010/haskellch19.html#x27-22700019.2 doesn't specify exactly] how this kind of case should be handled, so we should have some leeway in picking a solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 21:26:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 21:26:21 -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.fd48adb10687e9c4455be16d719cb53d@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 ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 21:58:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 21:58:31 -0000 Subject: [GHC] #12584: Bug (or Unhelpful Error) with TemplateHaskell Message-ID: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> #12584: Bug (or Unhelpful Error) with TemplateHaskell -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: -------------------------------------+------------------------------------- To recreate this make a Haskell file say named 'T.hs', with the following code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} (() -> ()) }}} Then try to compile it: {{{ $> ghc-stage2 T.hs [...] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160617 for x86_64-unknown-linux): tcMonoExpr _ [...] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 22:19:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 22:19:52 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality Message-ID: <045.ef28efa89ec213234d38356686664780@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | 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 -- test-sha256.hs: {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Prim (Addr#) import GHC.Ptr (Ptr(..), minusPtr) bug :: Addr# -> IO () bug a = do print ("cmp:", Ptr a == Ptr a) print ("delta:", Ptr a `minusPtr` Ptr a) print ("values:", Ptr a, Ptr a) main :: IO () main = bug "Assumptions are subtle!"# }}} {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -O1 --make test-sha256.hs && ./test-sha256 [1 of 1] Compiling Main ( test-sha256.hs, test-sha256.o ) Linking test-sha256 ... ("cmp:",False) ("delta:",-24) ("values:",0x000000000072fdc0,0x000000000072fda8) }}} Stg shows that literal gets inlined: {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -O1 --make test-sha256 -ddump-stg -dsuppress-all -dsuppress-uniques 2>&1 | grep Assumptions eqAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] minusAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] $w$cshowsPrec "Assumptions are subtle!"# w2 $w$cshowsPrec "Assumptions are subtle!"# w2 eqAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] minusAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] $w$cshowsPrec "Assumptions are subtle!"# w2 $w$cshowsPrec "Assumptions are subtle!"# w2 }}} I've found this bug as a SIGSEGV on testsuite cryptohash-sha256-0.11.100.1 from hackage. Bytestring assumes that address does not change and implements loops over Ptrs https://github.com/haskell/bytestring/blob/master/Data/ByteString.hs#L1171 : {{{#!hs filter :: (Word8 -> Bool) -> ByteString -> ByteString filter k ps@(PS x s l) | null ps = ps | otherwise = unsafePerformIO $ createAndTrim l $ \p -> withForeignPtr x $ \f -> do t <- go (f `plusPtr` s) p (f `plusPtr` (s + l)) return $! t `minusPtr` p -- actual length where go !f !t !end | f == end = return t | otherwise = do w <- peek f if k w then poke t w >> go (f `plusPtr` 1) (t `plusPtr` 1) end else go (f `plusPtr` 1) t end {-# INLINE filter #-} }}} In case of cryptohash-sha256-0.11.100.1 '''t <- go (f `plusPtr` s) p (f `plusPtr` (s + l))''' for literal inlined righ at 'f' call which caused testsuite failure. It seems sensible not to emit the literal more than once into '''.rodata''' section. It won't guard against problems where literal is exported as a part of .hi file but might be good enough for common cases like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 9 22:31:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Sep 2016 22:31:07 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.bbf5c2379f4b41165be24a9ef616af70@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | 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 slyfox): GHC-8.0.1 works as expected: {{{ $ ghc-8.0.1 -fforce-recomp -O1 --make a.hs && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... ("cmp:",True) ("delta:",0) ("values:",0x00000000004a7888,0x00000000004a7888) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 00:24:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 00:24:17 -0000 Subject: [GHC] #12582: HSOC Eventlog live profiling In-Reply-To: <047.39614347d19ac7526209a37004883cae@haskell.org> References: <047.39614347d19ac7526209a37004883cae@haskell.org> Message-ID: <062.d2357c41a115188e8f7b5fb112a35457@haskell.org> #12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: eventlog | profile hsoc 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 Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 01:23:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 01:23:43 -0000 Subject: [GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic In-Reply-To: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> References: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> Message-ID: <065.d4d37f1abeecc2fe799395eb14b0b431@haskell.org> #12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.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:D2521 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2521 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 04:35:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 04:35:53 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.2fe65a654a7590af1039866eaa63fcf9@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 08:32:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 08:32:37 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.12c1133102362e0781c0a7fbfaed2dee@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by slyfox): * failure: None/Unknown => Incorrect result at runtime * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 09:36:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 09:36:17 -0000 Subject: [GHC] #12582: HSOC Eventlog live profiling In-Reply-To: <047.39614347d19ac7526209a37004883cae@haskell.org> References: <047.39614347d19ac7526209a37004883cae@haskell.org> Message-ID: <062.c18a987034f81296f6b0156771d0bc04@haskell.org> #12582: HSOC Eventlog live profiling -------------------------------------+------------------------------------- Reporter: NCrashed | Owner: NCrashed Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: eventlog | profile hsoc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2522 Wiki Page: | -------------------------------------+------------------------------------- Changes (by NCrashed): * differential: => Phab:D2522 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 09:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 09:46:30 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types Message-ID: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Documentation for the base types in `Foreign.C` are incorrect on Hackage. Not really incorrect but only valid for the platform for which Haddock runs. As an example it says for `CLong` {{{ newtype CLong = CLong Int64 }}} Which is Incorrect on Windows. I don't know a technical solution for this, so I'm proposing a non-technical one: Add a warning on the top of the `Foreign-C-Types` to indicate that these types may differ on various platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 09:46:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 09:46:55 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types In-Reply-To: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> References: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> Message-ID: <059.aa8477e50108edfdd17611dddf073767@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | 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 Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 10:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 10:02:41 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types In-Reply-To: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> References: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> Message-ID: <059.c52b3ed6bf41e000f9c5de931392ccfe@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 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:D2523 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2523 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 12:23:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 12:23:23 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.3232a103c93d4b56e22090f7d51fac4b@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 slyfox): Comment 10 at https://ghc.haskell.org/trac/ghc/ticket/11292#comment:10 suggests to disambiguate '''Addr#''' and '''"literals"#''' with different types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 14:27:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 14:27:19 -0000 Subject: [GHC] #4210: LLVM: Dynamic Library Support In-Reply-To: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> References: <045.9da2e8588befc1a62c55be781a6ff87b@haskell.org> Message-ID: <060.dc7baa5dd528b025ee00cd73119ae549@haskell.org> #4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | 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 angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 15:39:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 15:39:35 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.41241f23a1fbcbb004868b05a641b7a8@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I agree that this is a parser bug. For another example, in this program `f1` and `f3` work but `f2` fails: {{{#!haskell {-# LANGUAGE MultiWayIf #-} f1 x = case () of _ | even x , notZero x -> True | otherwise -> False f2 x = if | even x , notZero x -> True | otherwise -> False f3 x = if { | even x , notZero x -> True ; | otherwise -> False } notZero = (/=) 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 17:31:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 17:31:16 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.d9e7b870877808ea7efe45496c925b3f@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): (patch is on the way) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 17:58:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 17:58:37 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.3a59d467675581aacd4586050a7f655e@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: ak3n Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.8.2 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:D2461 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"7b4bb40555eb19b528a976ff1f1b43c8bded6373/ghc" 7b4bb40/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b4bb40555eb19b528a976ff1f1b43c8bded6373" Remove -flocal-ghci-history from default flags Summary: D2461 seemed to (inadvertently, I think) add the `-flocal-ghci-history` flag to the list of `defaultFlags` that are enabled automatically. As a result, every invocation of `ghci` caused a local GHCi history to be saved to the current directory, which probably shouldn't be the default. Test Plan: Run `ghci`, observe the lack of a `.ghci_history` file in your working directory Reviewers: austin, thomie, bgamari Reviewed By: bgamari Subscribers: ak3n Differential Revision: https://phabricator.haskell.org/D2520 GHC Trac Issues: #9089 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 18:04:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 18:04:19 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.01458cbc7050449a4db68377e098f6da@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D2524 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 18:24:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 18:24:17 -0000 Subject: [GHC] #12587: InstanceSigs doesn't work with ambigous types Message-ID: <048.684ad96c32ef897522b527a46dc2a754@haskell.org> #12587: InstanceSigs doesn't work with ambigous types -------------------------------------+------------------------------------- Reporter: vagarenko | 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: -------------------------------------+------------------------------------- Why this code: {{{#!hs {-# LANGUAGE ScopedTypeVariables, InstanceSigs, AllowAmbiguousTypes #-} module Bug where class Foo a class Bar a where bar :: forall b. (Foo b) => a instance Bar Int where bar :: forall b. (Foo b) => Int -- error here bar = undefined where x :: b x = undefined }}} is rejected with message: {{{ Error: * Could not deduce (Foo b0) from the context: Foo b bound by the type signature for: bar :: Foo b => Int at Bug.hs:11:12-35 The type variable `b0' is ambiguous * When checking that: forall b. Foo b => Int is more polymorphic than: forall b. Foo b => Int When checking that instance signature for `bar' is more general than its signature in the class Instance sig: forall b. Foo b => Int Class sig: forall b. Foo b => Int In the instance declaration for `Bar Int' }}} ? Where does `b0` type var come from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 19:10:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 19:10:04 -0000 Subject: [GHC] #12584: Bug (or Unhelpful Error) with TemplateHaskell In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.cefce448181d466c04c1b052d2973e8b@haskell.org> #12584: Bug (or Unhelpful Error) with TemplateHaskell -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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 Shayan-Najd): similarly for {{{#!hs {-# LANGUAGE TemplateHaskell #-} a at b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 19:30:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 19:30:34 -0000 Subject: [GHC] #12584: Bug (or Unhelpful Error) with TemplateHaskell In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.cd5965c585bf96915ae6e2577f28a639@haskell.org> #12584: Bug (or Unhelpful Error) with TemplateHaskell -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 19:33:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 19:33:03 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types In-Reply-To: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> References: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> Message-ID: <059.5025e9dca4a5ad9782873bd78df198e0@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 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:D2523 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"710f21cc3a6f10dac1b31d089458e5fd16f6d3db/ghc" 710f21c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="710f21cc3a6f10dac1b31d089458e5fd16f6d3db" Add platform warning to Foreign.C.Types Summary: The generated documentation for thhe Foreign.C.Types module is generated based on the platform which ran Haddock. This is generating incorrect types for e.g. Windows. Add a disclaimer to the top of the page to ask people to keep this in mind. Test Plan: make documentation and inspect Haddock Reviewers: erikd, austin, hvr, bgamari Reviewed By: erikd Subscribers: RyanGlScott, #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D2523 GHC Trac Issues: #12586 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 19:57:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 19:57:18 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types In-Reply-To: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> References: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> Message-ID: <059.9ed19230cecae0a39a7cc366755e5e72@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | 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): Phab:D2523 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 20:06:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 20:06:41 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.e0b0badd1a60972040cd3243be9e05dc@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #11292 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 20:11:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 20:11:44 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types In-Reply-To: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> References: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> Message-ID: <059.db2048130996a9df9a0383c90f12d448@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: Component: libraries/base | 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): Phab:D2523 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: closed => merge Comment: Merge if possible, just adds documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 21:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 21:16:49 -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.4dd9af20e86b78ec042ce126c1e9d45c@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: 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 RyanGlScott): It should be noted that you don't need a type/kind variable explicitly named `k` to trigger this bug. You can also trigger it with an arbitrarily named variable like so: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Regression2 where import Language.Haskell.TH data family T (a :: b) data instance T b class C a $(do FamilyI #if __GLASGOW_HASKELL__ >= 800 (DataFamilyD tName _ _) #else (FamilyD _ tName _ _) #endif [DataInstD [] _ [tyVar] #if __GLASGOW_HASKELL__ >= 800 _ #endif _ _] <- reify ''T d <- instanceD (cxt []) (conT ''C `appT` (conT tName `appT` return tyVar)) [] return [d]) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Regression2.hs [1 of 1] Compiling Regression2 ( Regression2.hs, Regression2.o ) Regression2.hs:(15,3)-(27,15): Splicing declarations do { FamilyI (DataFamilyD tName_a2RY _ _) [DataInstD [] _ [tyVar_a2RZ] _ _ _] <- reify ''T; d_a322 <- instanceD (cxt []) (conT ''C `appT` (conT tName_a2RY `appT` return tyVar_a2RZ)) []; return [d_a322] } ======> instance C (T (b_avD :: b_avO)) Regression2.hs:15:3: error: Variable ‘b_avD’ used as both a kind and a type Did you intend to use TypeInType? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 10 21:20:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Sep 2016 21:20:38 -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.056a5532bb635a37e501177fc5707342@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: 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 RyanGlScott): As before, `Regression2` does in fact compile with GHC 7.10.3: {{{ $ /opt/ghc/7.10.3/bin/ghc Regression2.hs [1 of 1] Compiling Regression2 ( Regression2.hs, Regression2.o ) Regression2.hs:(15,3)-(27,15): Splicing declarations do { FamilyI (FamilyD _ tName_a39r _ _) [DataInstD [] _ [tyVar_a39s] _ _] <- reify ''T; d_a3id <- instanceD (cxt []) (conT ''C `appT` (conT tName_a39r `appT` return tyVar_a39s)) []; return [d_a3id] } ======> instance C (T (b_apE :: k_apP)) }}} There's something interesting to note here, as in GHC 8.0.1, it tries to splice: {{{#!hs instance C (T (b_avD :: b_avO)) }}} But in GHC 7.10.3, it splices this: {{{#!hs instance C (T (b_apE :: k_apP)) }}} Notice that the kind variable isn't `b` at all, but rather an inferred `k`! So it looks like there was a change in behavior at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 03:09:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 03:09:38 -0000 Subject: [GHC] #12588: GHC bug, compiling Stack master on macOS Sierra Message-ID: <048.d7d0023fbe4567a6d47cd4a46e618cce@haskell.org> #12588: GHC bug, compiling Stack master on macOS Sierra -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{ stack upgrade --git }}} {{{ $ uname -a Darwin cumae.local 16.0.0 Darwin Kernel Version 16.0.0: Tue Aug 23 17:02:44 PDT 2016; root:xnu-3789.1.31~2/RELEASE_X86_64 x86_64 }}} Xcode 8.0 GM, macOS Sierra {{{ Preprocessing library stack-1.2.1... [ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 96] 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 96] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 5 of 96] 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 96] 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/Cabal-1.22.5.0/build/Paths_stack.o ) [ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 96] 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/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/ghc29687_0/libghc_55.dylib, 5): no suitable image found. Did find: /var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/ghc29687_0/libghc_55.dylib: malformed mach-o: load commands size (46680) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 178 action(s). -- While building package stack-1.2.1 using: /private/var/folders/79/6lft40kj3cqb9f08_8yfg3vr0000gn/T/stack- upgrade18342/stack/.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 Sun Sep 11 08:16:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 08:16:33 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.f99d7ef844517e70e2c4a1389cf00d37@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- 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 Iceland_jack): (Example that tripped me up) I wanted to define a `Proxy`-less version of [https://hackage.haskell.org/package/generics-sop-0.2.2.0/docs/Generics- SOP-Classes.html#v:hcpure hcpure]. By muscle memory I quantified over the type variables in the context but the rest.. {{{#!hs hcpure_ :: forall h c xs. (HPure h, AllN h c xs) => (forall (a :: k). c a => f a) -> h f xs hcpure_ = hcpure (Proxy @c) }}} I read my types in linear order: Do I quantify over `a`? (''no'', it's higher rank) Do I quantify over `k`? (''optional'', must appear before `h`, `c` and `f` though). Do I quantify over `c`? (''never mind'' already did) Do I quantify over `f`? (''yes'') Did I do `h`, `f`, `xs` already? This is more analysis than my brain can do quickly :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 08:27:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 08:27:32 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.e534d3ecb9087ee831ee7a2d7677ce8f@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: Phab:D2495 => Phab:D2495 Phab:D2525 Comment: With Phab:D2525 I have not seen the panic in `mkFastStringWith` described in #12537 anymore. I rebuilt Stackage nightly twice on a powerpce64le. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 09:00:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 09:00:45 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes Message-ID: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Does this still happen in HEAD? {{{#!hs import qualified GHC.Generics as GHC import Generics.SOP import Generics.SOP.TH import Data.Proxy gminbound' :: (Generic a, Code a ~ (xs:xss), All2 Bounded (Code a)) => a gminbound' = minBound & I & hcpure (Proxy @Bounded) & apInjs_POP & head & to }}} Fails but doesn't crash with {{{ $ ghci -ignore-dot-ghci -XTypeApplications -XTypeOperators -XDataKinds -XGADTs -XFlexibleContexts /tmp/tX96.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tX96.hs, interpreted ) /tmp/tX96.hs:8:3: error: Variable not in scope: (&) :: t4 -> (a0 -> I a0) -> t3 /tmp/tX96.hs:9:3: error: Variable not in scope: (&) :: t3 -> t5 -> t2 /tmp/tX96.hs:10:3: error: Variable not in scope: (&) :: t2 -> (POP f1 xss0 -> [SOP f1 xss0]) -> t1 /tmp/tX96.hs:11:3: error: Variable not in scope: (&) :: t1 -> ([a1] -> a1) -> t0 /tmp/tX96.hs:12:3: error: Variable not in scope: (&) :: t0 -> (Rep a2 -> a2) -> a Failed, modules loaded: none. Prelude> }}} but crashes with `-fdefer-typed-holes` {{{ $ ghci -ignore-dot-ghci -fdefer-typed-holes -XTypeApplications -XTypeOperators -XDataKinds -XGADTs -XFlexibleContexts /tmp/tX96.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tX96.hs, interpreted ) /tmp/tX96.hs:8:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t4 -> (a0 -> I a0) -> t3 /tmp/tX96.hs:9:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t3 -> t5 -> t2 /tmp/tX96.hs:10:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t2 -> (POP f1 xss0 -> [SOP f1 xss0]) -> t1 /tmp/tX96.hs:11:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t1 -> ([a1] -> a1) -> t0 /tmp/tX96.hs:12:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t0 -> (Rep a2 -> a2) -> a ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): opt_univ fell into a hole {aabX} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} ---- More minimal example, still requires [https://hackage.haskell.org/package /generics-sop-0.2.2.0 generics-sop]: {{{#!hs import Generics.SOP a = minBound & hcpure (Proxy @Bounded) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 09:10:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 09:10:06 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.f945cca99ad2dbf1a2d8f39c89819683@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- 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 Iceland_jack): Simplified version without any dependencies (''generics-sop''): {{{#!hs import Data.Proxy hcpure :: proxy c -> (forall a. c a => f a) -> h f xs hcpure _ _ = undefined a = minBound & hcpure (Proxy @Bounded) }}} This is a good use case for #393, because of the rank-2 type we need to supply two wildcard arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 09:36:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 09:36:23 -0000 Subject: [GHC] #12590: GHC panics, -XTypeInType, possibly "cobox" related Message-ID: <048.b37f6d40857c85af86f441819f65a204@haskell.org> #12590: GHC panics, -XTypeInType, possibly "cobox" related -------------------------------------+------------------------------------- Reporter: heisenbug | 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 get {{{ GHCi, version 8.1.20160902: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Tree ( src/Tree.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160902 for x86_64-apple-darwin): tcTyVarDetails cobox_a15m :: (n_a159[ssk] :: Peano) ~# ('Z :: Peano) }}} on the attached file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 09:37:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 09:37:31 -0000 Subject: [GHC] #12590: GHC panics, -XTypeInType, possibly "cobox" related In-Reply-To: <048.b37f6d40857c85af86f441819f65a204@haskell.org> References: <048.b37f6d40857c85af86f441819f65a204@haskell.org> Message-ID: <063.1c0dd94a07e8f906e56f6e67f3ca4be7@haskell.org> #12590: GHC panics, -XTypeInType, possibly "cobox" related -------------------------------------+------------------------------------- Reporter: heisenbug | 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 heisenbug): * Attachment "Tree.hs" added. provokes panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 12:55:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 12:55:32 -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.a982cd32b3be25cbf1126c72f5bd7645@haskell.org> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: proposal | Status: new Priority: normal | Milestone: 8.2.1 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 mpickering): * status: closed => new * differential: => Phab:D2526 * resolution: wontfix => * milestone: Not GHC => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 12:55:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 12:55:40 -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.9145bbb0224c17c9a9c0494c6f666396@haskell.org> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: proposal | Status: patch Priority: normal | Milestone: 8.2.1 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 mpickering): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 14:40:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 14:40:41 -0000 Subject: [GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic In-Reply-To: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> References: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> Message-ID: <065.98e444aa1ec183a58922b237ff6f5a39@haskell.org> #12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.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:D2521 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"7b7ea8f40e7400b8c183595a85bb2c65c9f9bb29/ghc" 7b7ea8f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b7ea8f40e7400b8c183595a85bb2c65c9f9bb29" Fix derived Ix instances for one-constructor GADTs Summary: Standalone-derived `Ix` instances would panic on GADTs with exactly one constructor, since the list of fields was being passed to a function that uses `foldl1` in order to generate an implementation for `inRange`. This adds a simple check that makes `inRange` be `True` whenever a product type has no fields. Fixes #12583. Test Plan: make test TEST=12583 Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2521 GHC Trac Issues: #12583 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 15:14:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 15:14:49 -0000 Subject: [GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic In-Reply-To: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> References: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> Message-ID: <065.54af6e74af6bd63145ad5c3ccd3b03d9@haskell.org> #12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.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:D2521 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0e7ccf6d233c66b23a60de4e35e039f78ea3e162/ghc" 0e7ccf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e7ccf6d233c66b23a60de4e35e039f78ea3e162" Fix TH ppr output for list comprehensions with only one Stmt A folow-up to D2521 (which addressed #12583), where the `Outputable` `ppr` output was tweaked to display a list comprehension with only one `Stmt` as `[Foo]` instead of `[Foo|]` (which isn't valid Haskell). I forgot to update the corresponding code in `Language.Haskell.TH.Ppr` which pretty-prints `CompE`, however, so this commit takes care of that. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 15:16:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 15:16:52 -0000 Subject: [GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic In-Reply-To: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> References: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> Message-ID: <065.fb7a63cc9a6bfe9079e26102f18c87a1@haskell.org> #12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | deriving/should_compile/T12583 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2521 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => deriving/should_compile/T12583 Comment: The above two commits can be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 21:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 21:45:32 -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.65d7f5474b6494a3806371f1de7d001d@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- 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 Phyx-): It turns out that this is slightly tricky on Linux as well. It seems that the `WRAPPER` scripts generated by `utils/ghc-cabal/Main.hs` is also setting the `LD_LIBRARY_PATH` value to each dependency of the wrapped application. Previously for the RTS this was easy because all of the `RTS .so` were all in the same folder so it hardcoded `lib/ghc-${ver}/rts-1.0/` in the `LD_LIBRARY_PATH`. This presents the obvious question now, what to do with the RTS. Previously because the names were different and they're all in the same subdirectory you could just add the parent and the platform loaded would load the .so based on the filename. The problem is, I have no way of telling, from within the compiled program which RTS you actually intended to use. If I can't do that I can't add the new rts directories to the library path. Any suggestions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 23:19:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 23:19:30 -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.2a843e0683549f2ce491e0103a642c26@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For reference, here is the current error message in GHC 8.0.1/HEAD: {{{ • Couldn't match type ‘* -> *’ with ‘*’ Expected type: Proxy Maybe Actual type: Proxy Maybe Use -fprint-explicit-kinds to see the kind arguments • In the first argument of ‘fun’, namely ‘(Proxy :: Proxy Maybe)’ In the expression: fun (Proxy :: Proxy Maybe) In an equation for ‘bug’: bug = fun (Proxy :: Proxy Maybe) }}} I think this is much clearer, and doesn't incorrectly label the type as a kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 11 23:23:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Sep 2016 23:23:17 -0000 Subject: [GHC] #11672: Poor error message In-Reply-To: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> References: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> Message-ID: <064.0c360ed4691ffa46ec00b5d60b7df3ad@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | ErrorMessages, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For reference, here is the current error message in GHC 8.0.1/HEAD: {{{ • Couldn't match type ‘*’ with ‘Symbol’ Expected type: Proxy ((->) Int Bool) Actual type: Proxy (Int -> Bool) Use -fprint-explicit-kinds to see the kind arguments • In the first argument of ‘f’, namely ‘(Proxy :: Proxy (Int -> Bool))’ In the expression: f (Proxy :: Proxy (Int -> Bool)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (Int -> Bool)) }}} This seems to address the first and third bullet points above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 06:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 06:00:56 -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.21e78be2293cafc963fefb2631a4b790@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- 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 Phyx-): I meant from within the ghc-cabal code while generating the wrappers there's no way for me to tell which rts the program intended to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 08:01:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 08:01:37 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.bc66efe66429b7e478fb81c2efbf185f@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What about `Ptr "foo"# == Ptr "foo"#`? That is, two textually-distinct string literals. Are they distinct or the same? It is probably a mistake for string literals to have type `Addr#`. * Addresses of type `Addr#` certainly should be compared simply by comparing their values * But string should not be compared by comparing their addresses. Still, I suppose that if every string literal in the program gave rise to a single top-level defintion in the program, that might help. See #8472 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 08:02:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 08:02:08 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.9150b1b5458efe858db05e18b4e886a9@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #12585 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 08:05:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 08:05:46 -0000 Subject: [GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality In-Reply-To: <045.ef28efa89ec213234d38356686664780@haskell.org> References: <045.ef28efa89ec213234d38356686664780@haskell.org> Message-ID: <060.caf35999420443505e156e07d1797914@haskell.org> #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Actually this is a duplicate of #11312, which lacks a volunteer to take it forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 08:06:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 08:06:28 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.b26afbb65a626a57f254ce85c9636d05@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #12585 for another report of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 08:06:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 08:06:40 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.6c34024a9ff672bab67039af168065de@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): More intersting string-literal stuff * #9577 * #10922 * #11312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 09:56:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 09:56:23 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices (was: Bug (or Unhelpful Error) with TemplateHaskell) In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.23e8f816eb8ac419a4501eae88ad87bb@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by Shayan-Najd): * priority: normal => high * cc: simonpj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 11:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 11:59:27 -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.2da7c61d3e58b052ee7d6f60c465cd6a@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.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): @ezyang, I'd like to find a solution to this, because otherwise we need some pretty horrible hacks at our end to keep our package DBs ordered. I read your long description in comment:9 (twice!) but I'm afraid I still don't understand what change required this new ordering constraint on package DBs. The original commit (39b71e81ec1044518f065d0055676d713521e483) didn't explain the motivation either. My recollection of the algorithm before was that we throw all the packages together, resolve any clashes by using the package DB ordering, and then throw away packages whose deps are not satisfied, recursively. Could you explain what went wrong that caused GHC to not bootstrap? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 12:32:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 12:32:51 -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.10ca983c2e99f0b2a00cc1f8ab9734f7@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.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): In the old world, it was OK to resolve clashes in the end because we assumed that if two packages had the same IPID, it would be OK to pick one arbitrarily. In other words, we assumed that equal IPIDs implies equal ABIs, making them interconvertible. We always computed the IPID by running `ghc --abi-hash`. Now, we wanted to stop computing IPIDs based on `--abi-hash`. The reason is that cabal-install wants to assign a unique IPID prior to compilation, based on all of the inputs to the compilation (in Nix-style local builds). ABI hashes get in the way because we find them out too late. In an ideal world, we could assume that if two packages have the same IPID, their ABI hashes are the same. But basically any package manager that is not cabal- install with Nix-style local builds can't really give a guarantee like this. So I decided we should just not assume that ABI hashes are the same, even if the IPIDs are the same. Now, the crux of the issue: it is no longer true that if two packages had the same IPID, it would be OK to pick one arbitrarily. That is only true if the ABIs are the same. If the ABIs are not the same, one needs to shadow the other. But how do we know which packages were compiled for package 1, as opposed to package 2? Without package database ordering, we don't know. (Remember with shadowing in GHC 7.8 was just making sure we didn't have conflicting package id derived symbol names; but since dependencies were always recorded as IPID, it was a pretty simple matter to figure out what to remove. Nothing ever got removed if there was an IPID conflict.) As I mentioned earlier, one way we can resolve this is by recording both the IPID and the ABI of the dependencies of each package. Then we can resolve conflicts at the very end. I suppose there are less invasive ideas where we play more fast and loose about how we combine package databases. But does this explain the situation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 12:45:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 12:45:10 -0000 Subject: [GHC] #11691: Documentation indicates RelaxedPolyRec is optional In-Reply-To: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> References: <045.feea30a29b5f57c680da2d1262611dfe@haskell.org> Message-ID: <060.57548d7b375b566074b369085955a082@haskell.org> #11691: Documentation indicates RelaxedPolyRec is optional -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1-rc2 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:D2515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 02f09410fa6b015ad84153c0d7680a5f59d81daa. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 12:46:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 12:46:11 -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.22b6ed39d2f1e77a95fff9ce6b6a6cf4@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: comment:14 merged to `ghc-8.0` as 44e823d39195f8cddd2ae4c587292a3639502050. Reopening due to last few comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 12:46:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 12:46:49 -0000 Subject: [GHC] #12586: Add types warning to Foreign.C.Types In-Reply-To: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> References: <044.270b01b427f42b992b58a4e9eba7c191@haskell.org> Message-ID: <059.ebfe2901fc37780cc825e445ca00bc9f@haskell.org> #12586: Add types warning to Foreign.C.Types -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- 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: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2523 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 14fb8ef376606a4dd873374a863863357d16ed95. Thanks Tamar! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 12:48:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 12:48:24 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.53df5eccaacf3fa82a9a0615e186f8ed@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: Component: Core Libraries | 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 bgamari): Sorry for missing your comment, erikd! Thanks for handling this Edward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:07:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:07:46 -0000 Subject: [GHC] #12413: Compact regions support needs some discussion in the release notes In-Reply-To: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> References: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> Message-ID: <061.4799861cb072601feb0c81ed7ad532cb@haskell.org> #12413: Compact regions support needs some discussion in the release notes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Documentation | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,1 +3,1 @@ - It was merged as cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453. + This feature was merged as cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453. New description: And perhaps elsewhere in the users guide. This feature was merged as cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:11:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:11:58 -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.a35fc8dd8adf6dfac89500ee3bd0e6a8@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): Ok, I understand that IPID does not determine ABI any more, and dependencies only record IPID. This situation bothers me for a couple of reasons. * Now we are relying on the package-db ordering on the command line for dependency safety, whereas previously we could check because we had the ABIs of the dependencies. * We've lost the property that you can just union all the package DBs, which is a bit sad. The idea of a package DB "stack" was really just a temporary situation to deal with the fact that we couldn't link multiple package instances into the same binary so we had to have some way to resolve conflicts; my intention was that eventually the idea of a "stack" would just go away when it wasn't necessary any more. The problem is really that a dependency doesn't uniquely specify its target. We don't want dependencies to be GUIDs because something something determinism, but having a dependency be a pair of (ABI,IPID) as you suggest would be good enough. In the short term, would anything go wrong if we allowed an IPID anywhere in the stack to satisfy a dependency provided it was unique? And if a dependency is not unique, we resolve in the current way, using the DB ordering. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:12:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:12:22 -0000 Subject: [GHC] #12380: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.e34a54a22884f581cc455807c95f0c38@haskell.org> References: <047.e34a54a22884f581cc455807c95f0c38@haskell.org> Message-ID: <062.6781a5e6771efb387b9afe847316c411@haskell.org> #12380: ghc: panic! (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: Hassan58 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => duplicate * related: => #12479 Comment: This is a duplicate of #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:12:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:12:48 -0000 Subject: [GHC] #12588: GHC bug, compiling Stack master on macOS Sierra In-Reply-To: <048.d7d0023fbe4567a6d47cd4a46e618cce@haskell.org> References: <048.d7d0023fbe4567a6d47cd4a46e618cce@haskell.org> Message-ID: <063.3514a4f4657c217a3c62806772d81417@haskell.org> #12588: GHC bug, compiling Stack master on macOS Sierra -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: This is a duplicate of #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:33:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:33:21 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.7b3f9412a36d327ef2778555ff05659d@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: I'm afraid 8.0.2 is out of the question. However, 8.2.1 is a possibility. Of course, any help that you, the reader, can offer would expedite the process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:34:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:34:03 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.a70b21488d2a4b4abaacbb30999b40f7@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: Sadly this won't be happening for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:35:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:35:24 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.0cefbd9732ecfe3ebec4d3e2ae1fee6b@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: | Keywords: runghc 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.0.2 => 8.2.1 Comment: Bumping off to 8.2.1 since the proposed simplification won't happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:40:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:40:59 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.455eff3f378deb523dfb6c71164ce6cd@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I merged the definition suggested by thomie in comment:13 in 3308b30be6a5eef71039923e94f11d9809671ca2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:41:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:41:50 -0000 Subject: [GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables. In-Reply-To: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> References: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> Message-ID: <062.d9aa65128b4a7170bb09584fe8369abd@haskell.org> #12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | DefaultSignatures, TypeApplications Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | generics/T12220 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.0.2 => 8.2.1 Comment: Given that no one feels terribly strongly about this we'll be bumping it off to 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:45:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:45:03 -0000 Subject: [GHC] #12488: Explicit namespaces doesn't enforce namespaces In-Reply-To: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> References: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> Message-ID: <064.3e304417b25d37701f4996983b402e96@haskell.org> #12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- 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 mpickering): Simon says that we should just reject this in the parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:47:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:47:17 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.840083837a39f7e67a735e26ba14dec1@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | 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:D2188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: Bumping off to 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:49:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:49:21 -0000 Subject: [GHC] #12572: `readdir_r` is deprecated In-Reply-To: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> References: <044.0aecfb549344599306dd6c9eea4aea17@haskell.org> Message-ID: <059.781d7419ac959265c89a86e0ed8db5b6@haskell.org> #12572: `readdir_r` is deprecated -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * version: 8.1 => 8.0.1 * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 96850ef96461df54862e5e9f53deb14145bd6925. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:50:22 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.e31a07d17bfc046c73b6b163435f45e4@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | 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.0.2 => 8.0.3 Comment: Unfortunately it doesn't look like we'll have this fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:51:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:51:45 -0000 Subject: [GHC] #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide In-Reply-To: <042.a992a290421e0ee585b6ffd4e20279f8@haskell.org> References: <042.a992a290421e0ee585b6ffd4e20279f8@haskell.org> Message-ID: <057.93c4b57c09eb2eecc0f5676210f0f469@haskell.org> #12090: Document Weverything/Wall/Wextra/Wdefault in user's guide -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.0.3 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: It doesn't look like this will happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 14:53:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 14:53:01 -0000 Subject: [GHC] #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers In-Reply-To: <046.a6a2b187c86fbb5c93bbd55a34566418@haskell.org> References: <046.a6a2b187c86fbb5c93bbd55a34566418@haskell.org> Message-ID: <061.ccf69b8efd1fed4613105b887cc16ce8@haskell.org> #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Bumping to 8.2.1. There's a good chance that this will be addressed by #11660. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 15:18:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 15:18:27 -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.2e542269b4fffc6a0b4ff43d4e127195@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Pushing off to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 15:20:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 15:20:20 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.fa6f492bd4ec4620215942d578faed7f@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Changes (by bgamari): * cc: mpickering (added) Comment: mpickering, do you suppose you could have a look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 15:21:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 15:21:05 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.90652940be2890ba3dd2408af67152e4@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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:"03541cbae50f0d1cdf99120ab88698f29a278159/ghc" 03541cba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03541cbae50f0d1cdf99120ab88698f29a278159" Be less picky about reporing inaccessible code Triggered by the discussion on Trac #12466, this patch makes GHC less aggressive about reporting an error when there are insoluble Givens. Being so agressive was making some libraries fail to compile, and is arguably wrong in at least some cases. See the discussion on the ticket. Several test now pass when they failed before; see the files-modified list for this patch. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:15:34 -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.ae23ccd49b28c2a197ab9d4a20fc7ffc@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c6ac1e5f25e980c69e36581666210749811ee1c6/ghc" c6ac1e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6ac1e5f25e980c69e36581666210749811ee1c6" users_guide: TH now partially supports typed holes As requested in #10267. However we still lack support in typed splices. See #10945 and #10946. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:15:34 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.37b569cb6d2fc668bf62c4aa75254299@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1344 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c6ac1e5f25e980c69e36581666210749811ee1c6/ghc" c6ac1e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6ac1e5f25e980c69e36581666210749811ee1c6" users_guide: TH now partially supports typed holes As requested in #10267. However we still lack support in typed splices. See #10945 and #10946. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:15:34 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.2fab4128a408e130ae33d47288f8a82f@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b451feff269562830e3ca727665ba19a0252d371/ghc" b451fef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b451feff269562830e3ca727665ba19a0252d371" users_guide: #8761 is now fixed Remove a leftover note in the users guide claiming that TH doesn't support pattern synonyms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:15:34 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.02fa3f888286187e5836079291fa3cd2@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.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/T10267 Blocked By: | Blocking: Related Tickets: #10945, #10946 | Differential Rev(s): Phab:D835 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c6ac1e5f25e980c69e36581666210749811ee1c6/ghc" c6ac1e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6ac1e5f25e980c69e36581666210749811ee1c6" users_guide: TH now partially supports typed holes As requested in #10267. However we still lack support in typed splices. See #10945 and #10946. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:15:34 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.c4684684459022cb63de0d4b1b3467ce@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6555c6bb8447ed65d5da4bab462ee9da7dc3f97a/ghc" 6555c6bb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6555c6bb8447ed65d5da4bab462ee9da7dc3f97a" rts: Disable -hb with multiple capabilities Biographical profiling is not thread-safe as documented in #12019. Throw an error when it is used in this way. Test Plan: Validate Reviewers: simonmar, austin, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2516 GHC Trac Issues: #12019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:17:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:17:41 -0000 Subject: [GHC] #12583: Deriving standalone Ix instance for GADT leads to GHC panic In-Reply-To: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> References: <050.1d115d8ce327c2d296706a6e7989ecae@haskell.org> Message-ID: <065.a774e8ce4f7847c8372e664ca42e31bb@haskell.org> #12583: Deriving standalone Ix instance for GADT leads to GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: crash | deriving/should_compile/T12583 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2521 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 706a7305415a8e22b7dc4e2b8406f5b660642d1c and 43149ea634a99e125bf7e1750953945d04df823b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:18:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:18:22 -0000 Subject: [GHC] #12573: Allow the user to pick the address that the RTS reserves for the heap In-Reply-To: <046.6cc0462ada69fe792e001db236aed944@haskell.org> References: <046.6cc0462ada69fe792e001db236aed944@haskell.org> Message-ID: <061.42abfb01a1e7a0971cf872e156e50fc4@haskell.org> #12573: Allow the user to pick the address that the RTS reserves for the heap -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 658f0354326ddfdafec3772cdb86d89f0e424663. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 16:56:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 16:56:38 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.e4c5ea06e63af952e11f47a25c32a910@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Comment (by bgamari): mpickering has said that he doesn't have enough time to look at this in the near future so I may try to dust off my previous fix, Phab:D2133. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 17:05:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 17:05:17 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.60bb35822e5d9e54e4714277cd918f41@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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): * owner: bgamari => Comment: I'm afraid this is something that I won't have time to take up in the near future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 17:37:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 17:37:42 -0000 Subject: [GHC] #10835: Regression in standalone Data deriving for phantom types In-Reply-To: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> References: <048.e488f2f2d397e40d5fcfbc59cce5f092@haskell.org> Message-ID: <063.8196cd62efdb6894592041ba5b018b36@haskell.org> #10835: Regression in standalone Data deriving for phantom types -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 * milestone: => 8.0.1 Comment: With GHC 8.0 the polykinded example can be made to compile by adding a `Typeable` constraint on the kind of `t`, {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving, PolyKinds, TypeInType #-} module M where import Data.Data import Data.Typeable data Phantom t = Phantom deriving Typeable deriving instance (Typeable k, Typeable (t::k)) => Data (Phantom t) }}} It also compiles without `PolyKinds`, although only with a `Data t` constraint, {{{#!hs {-# LANGUAGE DeriveDataTypeable, StandaloneDeriving #-} module M where import Data.Data import Data.Typeable data Phantom t = Phantom deriving Typeable deriving instance (Data t) => Data (Phantom t) }}} If one replaces the `Data` constraint with `Typeable` typechecking fails with, {{{ Hi2.hs:8:1: error: • Could not deduce (Data t) arising from a use of ‘f’ from the context: Typeable t bound by the instance declaration at Hi2.hs:8:1-50 or from: Typeable t1 bound by the type signature for: dataCast1 :: Typeable t1 => (forall d. Data d => c (t1 d)) -> Maybe (c (Phantom t)) at Hi2.hs:8:1-50 Possible fix: add (Data t) to the context of the type signature for: dataCast1 :: Typeable t1 => (forall d. Data d => c (t1 d)) -> Maybe (c (Phantom t)) or the instance declaration • In the first argument of ‘gcast1’, namely ‘f’ In the expression: gcast1 f In an equation for ‘dataCast1’: dataCast1 f = gcast1 f When typechecking the code for ‘dataCast1’ in a derived instance for ‘Data (Phantom t)’: To see the code I am typechecking, use -ddump-deriv }}} The reason for this is that GHC generates the following instance, {{{#!hs instance Typeable t => Data (Phantom t) where ... dataCast1 :: forall s c. (Typeable s) => (forall d. Data d => c (s d)) -> Maybe (c (Phantom t)) dataCast1 f = Data.Typeable.gcast1 f -- where Data.Typeable.gcast1 :: forall k k1 (c :: k -> *) (t :: k1 -> k) (t' :: k1 -> k) (a :: k1). (Typeable t, Typeable t') => c (t a) -> Maybe (c (t' a)) }}} Consequently the derived instance forces the `t ~ d` (WRT the type binders of `dataCast1` above). `dataCast1` requires `Data d`, hence the error. This all seems to be working as expected in GHC 8.0.1. Indeed, 7.8.4 also appears to require a `Data t` constraint despite the claim in the ticket summary, so I think all is well here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 17:50:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 17:50:32 -0000 Subject: [GHC] #12591: Profiled build broken Message-ID: <046.e6322f7e4e3b94a349405b8198f096f8@haskell.org> #12591: Profiled build broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.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: -------------------------------------+------------------------------------- As of 045f83ed39dba537b3da46465bd7a155c754f120 the `BuildFlavour=prof` build appears to be broken. The stage2 build appears to reproducibly fail with, {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -this-unit-id ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id binary-0.8.3.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.2.0 -package-id template- haskell-2.11.0.0 -package-id time-1.6.0.1 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O -fprof-auto-top -fprof-cafs -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/codeGen/StgCmmMonad.hs -o compiler/stage2/build/StgCmmMonad.p_o -dyno compiler/stage2/build/StgCmmMonad.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160912 for x86_64-unknown-linux): kindPrimRep.go k0_10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 17:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 17:51:50 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.d1ca3a4d24cee7e214c968f2edd49d90@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 18:24:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 18:24:01 -0000 Subject: [GHC] #12591: Profiled build broken In-Reply-To: <046.e6322f7e4e3b94a349405b8198f096f8@haskell.org> References: <046.e6322f7e4e3b94a349405b8198f096f8@haskell.org> Message-ID: <061.62ab7a6cd94802e64276f54392cc752c@haskell.org> #12591: Profiled build broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -1,1 +1,1 @@ - As of 045f83ed39dba537b3da46465bd7a155c754f120 the `BuildFlavour=prof` + As of 6555c6bb8447ed65d5da4bab462ee9da7dc3f97a the `BuildFlavour=prof` New description: As of 6555c6bb8447ed65d5da4bab462ee9da7dc3f97a the `BuildFlavour=prof` build appears to be broken. The stage2 build appears to reproducibly fail with, {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -this-unit-id ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id binary-0.8.3.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.2.0 -package-id template- haskell-2.11.0.0 -package-id time-1.6.0.1 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O -fprof-auto-top -fprof-cafs -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/codeGen/StgCmmMonad.hs -o compiler/stage2/build/StgCmmMonad.p_o -dyno compiler/stage2/build/StgCmmMonad.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160912 for x86_64-unknown-linux): kindPrimRep.go k0_10 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 20:03:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 20:03:04 -0000 Subject: [GHC] #12592: Explicit type signature for type classes fails Message-ID: <051.8583909b83ea46deb1c70aaa86a24891@haskell.org> #12592: Explicit type signature for type classes fails -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- GHC 8.0.1: Consider the [https://hackage.haskell.org/package/indexed-0.1 indexed classes]: {{{#!hs class IxFunctor f where imap :: (a -> b) -> f j k a -> f j k b class IxFunctor m => IxPointed m where ireturn :: a -> m i i a class IxPointed m => IxApplicative m where iap :: m i j (a -> b) -> m j k a -> m i k b class IxFunctor w => IxCopointed w where iextract :: w i i a -> a class IxApplicative m => IxMonad m where ibind :: (a -> m j k b) -> m i j a -> m i k b class IxMonad m => IxMonadFree f m | m -> f where iwrap :: f i j (m j k a) -> m i k a }}} GHCi gives their kinds: {{{ IxFunctor :: (k -> i -> * -> *) -> Constraint IxPointed :: (k -> k -> * -> *) -> Constraint IxApplicative :: (k -> k -> * -> *) -> Constraint IxCopointed :: (k -> k -> * -> *) -> Constraint IxMonad :: (k -> k -> * -> *) -> Constraint IxMonadFree :: (k -> k -> * -> *) -> (k -> k -> * -> *) -> Constraint }}} so I attempt to make them explicit: {{{#!hs type IxFunct i = i -> i -> Type -> Type class IxFunctor (f :: IxFunct i) where imap :: (a -> b) -> f j k a -> f j k b }}} Works fine, but if I add it to any of the others it fails: {{{#!hs -- tZRa.hs:15:17: error: … -- • Expected kind ‘i’, but ‘i’ has kind ‘*’ -- • In the first argument of ‘w’, namely ‘i’ -- In the type signature: -- iextract :: w i i a -> a -- In the class declaration for ‘IxCopointed’ -- Compilation failed. class IxFunctor w => IxCopointed (w :: IxFunct i) where iextract :: w i i a -> a -- ... class IxMonad m => IxMonadFree (f :: IxFunct i) (m :: IxFunct i) | m -> f where iwrap :: f i j (m j k a) -> m i k a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 20:20:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 20:20:18 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.4f85faadd95ea59422e73c66b64b25de@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): {{{#!hs type Cat k = k -> k -> Type data FreeCat :: Cat k -> Cat k where Nil :: FreeCat f a a Cons :: f a b -> FreeCat f b c -> FreeCat f a c liftCat :: f a b -> FreeCat f a b liftCat x = Cons x Nil }}} Free category generated by graph of natural numbers {{{#!hs data Node = Unit | N data NatGraph :: Cat Node where One :: NatGraph Unit N Succ :: NatGraph N N }}} {{{#!hs one :: (FreeCat @Node NatGraph) Unit N one = liftCat One }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 22:17:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 22:17:12 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.70085ff4fc5dd0d30e172910db8090ca@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | 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): Plus this {{{ commit 5eeabe250a1de456f70af07bd3f507a32cb8e10e Author: Simon Peyton Jones Date: Mon Sep 12 22:21:15 2016 +0100 Test wibbles for commit 03541cba I must have failed to validate properly, sorry. These testsuite wibbles belong with commit 03541cbae50f0d1cdf99120ab88698f29a278159 Author: Simon Peyton Jones Date: Fri Sep 9 17:42:42 2016 +0100 Be less picky about reporing inaccessible code testsuite/tests/typecheck/should_fail/FDsFromGivens.hs | 5 ++++- testsuite/tests/typecheck/should_fail/FDsFromGivens.stderr | 4 ++++ testsuite/tests/typecheck/should_fail/T10715.hs | 4 +++- testsuite/tests/typecheck/should_fail/T10715.stderr | 4 ++++ testsuite/tests/typecheck/should_fail/T8392a.hs | 2 ++ testsuite/tests/typecheck/should_fail/T8392a.stderr | 4 ++++ 6 files changed, 21 insertions(+), 2 deletions(-) }}} This should, I hope, unglue the log-jam of #12220 and #12533. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 22:20:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 22:20:28 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.98f6436ee9cee77cd0252e8a6600acd1@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | 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/T12466, | T12466a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T12466, T12466a * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 22:37:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 22:37:52 -0000 Subject: [GHC] #12593: ghci spins forever Message-ID: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- When run with {{{ ghci -ignore-dot-ghci -XRankNTypes -XTypeInType -XGADTs -XConstraintKinds t5AE.hs }}} the compiler spins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 22:38:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 22:38:16 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.be2bcc100b228e2cc5e40aafb03dc69b@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- 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 "t5AE.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 22:50:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 22:50:25 -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.427c02eae80b94e301e57dfada96d0ee@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): > Now we are relying on the package-db ordering on the command line for dependency safety, whereas previously we could check because we had the ABIs of the dependencies. Yes, you are right. :( > The idea of a package DB "stack" was really just a temporary situation to deal with the fact that we couldn't link multiple package instances into the same binary so we had to have some way to resolve conflicts; my intention was that eventually the idea of a "stack" would just go away when it wasn't necessary any more. And this is what I get for not being involved in the initial discussion ;) But it is hard for me to see how you could actually do this, because you can always end up in a situation where you have two separate packages with the same symbol name, and now you have to pick one. > In the short term, would anything go wrong if we allowed an IPID anywhere in the stack to satisfy a dependency provided it was unique? And if a dependency is not unique, we resolve in the current way, using the DB ordering. Nothing wrong! It just sounds really annoying to implement. ;) (I guess... we do a pre-pass to figure out conflicts, and then run the shadowing algorithm?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 12 23:20:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Sep 2016 23:20:51 -0000 Subject: [GHC] #12592: Explicit type signature for type classes fails In-Reply-To: <051.8583909b83ea46deb1c70aaa86a24891@haskell.org> References: <051.8583909b83ea46deb1c70aaa86a24891@haskell.org> Message-ID: <066.2a72679fb78eef485b5d7dbea96d27a7@haskell.org> #12592: Explicit type signature for type classes fails -------------------------------------+------------------------------------- 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 goldfire): This is expected behavior. I think the problem is that you're confusing a type with its kind. In the definition for `IxCopointed` above, your kind for w -- `IxFunct i` or `i -> i -> Type -> Type` -- implies that the type of `i` is `i`, which is not what you mean. That is, when you say `w :: IxFunct i`, then the first two arguments to `w` should have ''kind'' `i`, not necessarily ''be'' `i`. Does this clarify? And I don't see a way to improve the error message (beyond the general improvement our error messages would enjoy). If so, please close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 05:28:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 05:28:33 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes Message-ID: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | 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 {-# LANGUAGE DeriveAnyClass, DeriveGeneric #-} import Database.PostgreSQL.Simple import GHC.Generics data Foo = Foo { bar :: Int } deriving (Generic, ToRow) }}} This succeeds using `ghci`, but fails when trying to compile it using `ghc` with the following error message: {{{ • No instance for (Database.PostgreSQL.Simple.ToField.ToField Char) arising from the first field of ‘Foo’ (type ‘Int’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (ToRow Foo) }}} However, it works if I use `instance ToRow Foo` instead of relying upon `DeriveAnyClass`. I've tried this with other types instead of `Int`, using `newtype` instead of `data` and having multiple fields in the datatype. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 06:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 06:47:58 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes In-Reply-To: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> References: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> Message-ID: <059.fd66414efa8feab1e61f77cf883f469b@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | 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 lpsmith): * cc: leon.p.smith@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 06:53:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 06:53:36 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of Message-ID: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10531 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Linker fails on a normal project built with cabal (-O1), both on my home machine (GNU gold (GNU Binutils for Ubuntu 2.22) 1.11) and on travis with GHC 8.0.1: https://travis-ci.org/LambdaHack/LambdaHack/jobs/159457149#L589 and with head: https://travis-ci.org/LambdaHack/LambdaHack/jobs/159457156#L602 It compiles fine with -O0 (but if fails with -O2): https://travis-ci.org/LambdaHack/LambdaHack/jobs/159457144 with older GHCs: https://travis-ci.org/LambdaHack/LambdaHack/jobs/159457155 and after the symbol the linker complains about is removed: https://travis-ci.org/LambdaHack/LambdaHack/jobs/159506870 As seen on travis, the way to reproduce it is just cabal install of https://github.com/LambdaHack/LambdaHack/commit/0d2bbd6eadca7a10292ab67ab1fa708b4c20aaf6 which also shows the offending line. I took the liberty of adding it to 8.0.2 milestone, because if it affects all x86_64 machines, it's pretty serious. Please feel free to downgrade. If the bug is confirmed, I can attempt creating a small reproducing case, but it would require gtk, so it would compile forever anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 07:15:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 07:15:55 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.548eb7f62ce1dcb5fa9f1e6a1b130559@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mistydemeo): I reported #12198, which happened when the ghc being used to build As far as I'm aware, `-split-sections` is off by default, and the Homebrew buildscript doesn't explicitly enable it: https://github.com/Homebrew /homebrew- core/blob/df621e49f7006c9aa7ed7d1f570c955447f160a8/Formula/ghc.rb I don't believe stack is building with it either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 10:37:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 10:37:57 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes In-Reply-To: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> References: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> Message-ID: <059.5042229bb25c035dce5a7bd21c7cbef0@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | 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: | -------------------------------------+------------------------------------- @@ -15,1 +15,1 @@ - • No instance for (Database.PostgreSQL.Simple.ToField.ToField Char) + • No instance for (ToRow Int) New description: {{{#!hs {-# LANGUAGE DeriveAnyClass, DeriveGeneric #-} import Database.PostgreSQL.Simple import GHC.Generics data Foo = Foo { bar :: Int } deriving (Generic, ToRow) }}} This succeeds using `ghci`, but fails when trying to compile it using `ghc` with the following error message: {{{ • No instance for (ToRow Int) arising from the first field of ‘Foo’ (type ‘Int’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (ToRow Foo) }}} However, it works if I use `instance ToRow Foo` instead of relying upon `DeriveAnyClass`. I've tried this with other types instead of `Int`, using `newtype` instead of `data` and having multiple fields in the datatype. -- Comment (by hsyl20): With DeriveAnyClass, GHC tries to infer the context for the instance. From compiler/typecheck/TcDeriv.hs: {{{ -- Unfortunately, it is not clear how to determine the context (in case of -- standard deriving; in standalone deriving, the user provides the context). -- GHC uses the same heuristic for figuring out the class context that it uses for -- Eq in the case of *-kinded classes, and for Functor in the case of -- * -> *-kinded classes. That may not be optimal or even wrong. But in such -- cases, standalone deriving can still be used. }}} Here it seems to infer {{{instance ToRow Int => ToRow Foo }}}, hence the error. Maybe we should add the previous comment into the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 11:21:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 11:21:04 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes In-Reply-To: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> References: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> Message-ID: <059.f8a2d0c634d40dee0ab8f67ab024b292@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | 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): Yes, documenting this better would be a Jollly Good Thing. Also pointing out that if the (necessarily fallible) heuristic for deducing a context fails, you can always us a "standalone deriving" declaration to specify the context yourself; it's a bit like adding a type signature. Ryan or someone -- would you like to suggest a documentation patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 13:32:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 13:32:59 -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.cad5d9cf38b3f29abd4dca1370cc6495@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): > And this is what I get for not being involved in the initial discussion ;) But it is hard for me to see how you could actually do this, because you can always end up in a situation where you have two separate packages with the same symbol name, and now you have to pick one. That's true. In that case, either * The ABIs are the same, and we can just pick one, or * The ABIs are different, in which case we can either * report an error, or * Pick one to keep, and throw away everything that depends on the dropped one Reporting an error is bad - when we had something similar before (7.2? I forget exactly) you could get into a state where GHC fails to start because you have some conflict in your package database. That's why the GHC tries really hard to find a consistent set of packages by throwing things away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 13:54:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 13:54:58 -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.29f95e9e20ba6a20bf9812482af1a201@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): FWIW, in #12518 Harendra wants to bring back erroring, but guarded by a flag ;) Note about timeline: I'm unlikely to be able to patchfix the quick workaround before the end of ICFP (on vacation). I can handle adding ABI hashes to depends though for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 14:18:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 14:18:02 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.648a98fec53bebd1370749d583c8c358@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hesiod): I tried implementing this, however, simply adding the instance in Data.Either leads to an import cycle because {{{Data.String(IsString(..))}}} has to be imported: {{{ Module imports form a cycle: module ‘Data.Either’ (libraries/base/Data/Either.hs) imports ‘Data.String’ (libraries/base/Data/String.hs) which imports ‘Data.List’ (libraries/base/Data/List.hs) which imports ‘Data.Traversable’ (libraries/base/Data/Traversable.hs) which imports ‘Data.Either’ (libraries/base/Data/Either.hs) }}} However, I can't investigate this further atm, so if anyone wants to pick this up, please go ahead. I guess some shuffling around (maybe creating a hidden module for IsString) should solve the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 15:02:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 15:02:36 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.4c40c3512a7c9ea91f0a59224186550e@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Can someone please provide the output of `objdump -x` (or Darwin's equivalent) from the `libghc` in question? I really don't know what could be producing tens of thousands of load commands if not `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 16:59:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 16:59:17 -0000 Subject: [GHC] #7019: Wrong error message when using forall in constraints In-Reply-To: <054.4b1c3a857b1c2e2228d27ac07d9699b7@haskell.org> References: <054.4b1c3a857b1c2e2228d27ac07d9699b7@haskell.org> Message-ID: <069.b66e407f5ffd0ad883f3dd702930c0ae@haskell.org> #7019: Wrong error message when using forall in constraints -------------------------------------+------------------------------------- Reporter: sjoerd_visscher | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T7019, T7019a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This compiles using [https://hackage.haskell.org/package/constraints-0.8/docs/Data-Constraint- Forall.html Data.Constraint.Forall] for the record: {{{#!hs import Data.Constraint import Data.Constraint.Forall newtype Free c a = Free { runFree :: forall r. c r => (a -> r) -> r } deriving Functor class c (Free c a) => C c a instance c (Free c a) => C c a instance Applicative (Free c) where pure :: a -> Free c a pure a = Free ($ a) (<*>) :: Free c (a -> b) -> (Free c a -> Free c b) Free f <*> Free g = Free (\bfr -> f (\ab -> g (bfr . ab))) instance Forall (C c) => Monad (Free c) where return :: a -> Free c a return a = Free ($ a) (>>=) :: forall a b. Free c a -> (a -> Free c b) -> Free c b Free f >>= g = f g \\ inst @(C c) @b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 18:09:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 18:09:39 -0000 Subject: [GHC] #12596: can't find interface-file declaration Message-ID: <046.38012533792a227b36238e24bbed4707@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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: -------------------------------------+------------------------------------- full repro at https://github.com/mwotton/liftwoes/issues/1 ``` /home/mark/projects/liftwoes/src/Lib.hs:14:11: error: • Can't find interface-file declaration for variable Data.Text.Internal.pack 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 first argument of ‘(:)’, namely ‘Data.Text.Internal.pack ((:) 'A' [])’ In the first argument of ‘HS.fromList’, namely ``` {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module Lib where import Data.Data import qualified Data.Set as HS import qualified Data.Text as T import qualified Data.Text.IO as T import Data.Time -- import Instances.TH.Lift import Instances import Language.Haskell.TH.Syntax table = $(do r <- runIO (HS.fromList . T.lines <$> T.readFile "/usr/share/dict/words") [|r|] ) someFunc = do print $ HS.member "foo" table }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 18:10:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 18:10:41 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.2e08de33e77ecced5590495cb8468d3c@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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 mwotton): Instances.hs: {{{#hs module Instances where import Data.Data import qualified Data.Set as HS import Language.Haskell.TH.Syntax instance (Data a,Ord a) => Lift (HS.Set a) where lift = liftData }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 18:11:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 18:11:54 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.a34e4aec4b114586f7b4b69a855892ad@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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 mwotton): Instances.hs: {{{#!hs module Instances where import Data.Data import qualified Data.Set as HS import Language.Haskell.TH.Syntax instance (Data a,Ord a) => Lift (HS.Set a) where lift = liftData }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 18:23:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 18:23:32 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.6a3668c2dd8670f77a579afbab3f0af9@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:16 trommler]: > With Phab:D2525 I have not seen the panic in `mkFastStringWith` described in #12537 anymore. I rebuilt Stackage nightly twice on a powerpce64le. Another rebuild yielded one panic in `mkFastStringWith`. So it was a bit to early to declare victory :-( The situation has improved though. Previously I saw a handful of packages out of 1900 fail with that panic and now it is only one in around 4000 builds. My theory is that the write barrier is not sufficient in a memory model like PowerPC. The write barrier makes sure that the writes before it were performed in main memory before the barrier. But a different processor might still have stale values in its own caches and thus see an inconsistent state. We could insert read (load-load) barriers between the pointer access and data access but that might not be sufficient either. Think of a stale pointer cached in a processor cache that will be loaded before the read barrier will lead to an inconsistent state if data after the barrier comes from main memory. We need to define a semantics for MutVar/Array and then add the necessary barriers, which might compile to nothing depending on the memory model of the target platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 21:14:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 21:14:12 -0000 Subject: [GHC] #12015: Add conditional CallStack constraints to common partial utility functions In-Reply-To: <046.b74d0515b345cdd045765b55c27f0b21@haskell.org> References: <046.b74d0515b345cdd045765b55c27f0b21@haskell.org> Message-ID: <061.3310b0ab8c0a225da301b472818bcc96@haskell.org> #12015: Add conditional CallStack constraints to common partial utility functions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Phab:D2527 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2527 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 13 22:52:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Sep 2016 22:52:25 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.4f673cdab9e1bf629c94a489d1aa63ec@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2528 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 14 01:28:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Sep 2016 01:28:24 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.d98ebc8fe9269d7d08bb5d276b21e672@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 14 02:47:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Sep 2016 02:47:39 -0000 Subject: [GHC] #12597: -Wmissing-signatures uses forall even when invalid in source Message-ID: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> #12597: -Wmissing-signatures uses forall even when invalid in source -------------------------------------+------------------------------------- Reporter: nomeata | 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 `-Wmissing-signatures` warning is great to learn about the signatures that things should have, and is especially useful when teaching Haskell to beginners. Unfortunately, it uses explicit quantification (`forall`) even when in the compiled module, this is not valid: {{{ $ echo 'foo x = x' > Foo.hs $ ghci -Wall Foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:1:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: foo :: forall t. t -> t Ok, modules loaded: Main. *Main> $ echo -e 'foo :: forall t. t -> t\nfoo x = x' > Foo.hs $ ghci -Wall Foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:1:16: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . Failed, modules loaded: none. }}} The type signature provided by `-Wmissing-signatures` should be in a form that is valid in the context of the function that is missing the signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 14 06:20:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Sep 2016 06:20:25 -0000 Subject: [GHC] #12598: configure script: --enable-unregisterised default printed incorrectly Message-ID: <049.74a8794f08f225f7c1e273ea6f418ff2@haskell.org> #12598: configure script: --enable-unregisterised default printed incorrectly -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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 help text for the --enable-unregisterised flag to configure renders incorrectly. Instead of printing the actual default, it instead prints the name of the variable holding the default: {{{ --enable-unregisterised Build an unregisterised compiler (enabled by default on platforms without registerised support) [default="$UnregisterisedDefault"] }}} This happens because the help text is generated via a call to the `AC_HELP_STRING` macro: {{{#!m4 AC_HELP_STRING([--enable-unregisterised], [Build an unregisterised compiler (enabled by default on platforms without registerised support) [default="$UnregisterisedDefault"]]) }}} According to the autoconf documentation, "the second argument of `AS_HELP_STRING` is treated as a whitespace separated list of text to be reformatted, and is not subject to macro expansion." (https://www.gnu.org /savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Pretty- Help-Strings.html) - hence why the name of the variable is included in the output instead of its value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 14 16:36:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Sep 2016 16:36:36 -0000 Subject: [GHC] #12152: panic: Loading temp shared object failed In-Reply-To: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> References: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> Message-ID: <062.4af0fd711b0ecb6c57fedc5588e73778@haskell.org> #12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: v.dijk.bas@… (added) Comment: I'm having a similar / the same problem after upgrading to NixOS-16.09. Details are here: https://github.com/NixOS/nixpkgs/issues/18558 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 14 23:05:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Sep 2016 23:05:23 -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.88f85993b932c6a65a228a7d139f7560@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by richardfung): No problem at all, I managed to figure it out on my own! Thank you for all the help so far. I suspect I'm overthinking this or am missing something, but won't we still have this issue if we have multiple modules but one explicitly specifies -fignore-interface-pragmas? My understanding is that the issue can manifest itself in two ways: either we load an optimized module first and unoptimized second, thus using inlinings even with -O0, or unoptimized first and optimized second, in which case we should inline with -O but we can't because we did not read in the pragmas. Couldn't the second case still happen with the suggested fix if the unoptimized module also specified -fignore-interface-pragmas explicitly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 00:45:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 00:45:41 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.6846fea3b44750348f55000cd4ecd099@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by basvandijk): * status: closed => new * owner: trommler => * resolution: fixed => Comment: As also mentioned in #12152 I'm getting the following panic with GHC-8.0.1 which looks very similar to the error discussed in this ticket: {{{ $ git clone https://github.com/LumiGuide/haskell-opencv.git $ cd haskell-opencv $ nix-shell -I nixpkgs=../nixpkgs # a checkout of a recent nixos-16.09 $ rm -rf dist/ $ cabal build -v Package has never been configured. Configuring with default flags. If this fails, please run configure manually. /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc --numeric- version looking for tool ghc-pkg near compiler in /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin found ghc-pkg in /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc-pkg /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc-pkg --version /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc --supported- languages /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc --info Reading available packages... /nix/store/pkymfih8lf7j3ib6bfab7srri4xiyw34-pkg-config-0.29/bin/pkg-config --version /nix/store/pkymfih8lf7j3ib6bfab7srri4xiyw34-pkg-config-0.29/bin/pkg-config --list-all /nix/store/pkymfih8lf7j3ib6bfab7srri4xiyw34-pkg-config-0.29/bin/pkg-config --modversion poppler-cairo Wand-6.Q16 'ImageMagick++-6.Q16' python2 formw 'ncurses++' openssl libkeymap libgvc MagickWand-6.Q16 blkid form libxdot opencv ImageMagick menu smartcols libsystemd-login gimpui-2.0 libcdt libgvpr devmapper com_err libcurl libssl libsystemd-journal polkit- gobject-1 libecpg libsystemd polkit-agent-1 libpathplan nix-main libpci poppler panelw Wand libcap xorg-server e2p ImageMagick-6.Q16 liblzma gimpthumb-2.0 ncurses lvm2app MagickCore sqlite3 python libpq libcgraph xtables libprocps libkmod libip4tc libecpg_compat libpgtypes nix-store libcrypto poppler-splash libudev panel ext2fs libiptc poppler-glib 'Magick++-6.Q16' python-2.7 fdisk uuid libsystemd-daemon nix-expr poppler- cpp libip6tc mount fuse MagickWand gimp-2.0 fontconfig udisks2 ncursesw ss 'ImageMagick++' MagickCore-6.Q16 'Magick++' menuw libsystemd-id128 'ncurses++w' Choosing modular solver. Resolving dependencies... creating dist/setup creating dist creating dist/setup copy ./Setup.hs to ./dist/setup/setup.hs /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc --make -odir ./dist/setup -hidir ./dist/setup -i -i. -package-id Cabal-1.24.0.0 ./dist/setup/setup.hs -o ./dist/setup/setup -threaded [1 of 1] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o ) Linking ./dist/setup/setup ... ./dist/setup/setup configure --verbose=2 --builddir=dist --ghc --prefix=/home/bas.van.dijk/.cabal --user --extra-prog-path=/home/bas.van.dijk/.cabal/bin --dependency=aeson=aeson-0.11.2.1-11xZO4dSHJ36B3esP34sNx --dependency=base=base-4.9.0.0 --dependency=base64-bytestring=base64-bytestring-1.0.0.1-In9M41tLtcS9QYt3QpGpNY --dependency=bindings-DSL=bindings-DSL-1.0.23-GUrVdpTUVQC2JWoov2sGwA --dependency=bytestring=bytestring-0.10.8.1 --dependency=containers=containers-0.5.7.1 --dependency=deepseq=deepseq-1.4.2.0 --dependency=inline-c=inline-c-0.5.5.7-3JCuNEZtXHO4YTLZSRWOQ2 --dependency=inline-c-cpp=inline-c-cpp-0.1.0.0-2wSjs2z7tfoLnsB36U1XGl --dependency=linear=linear-1.20.5-2Z9jl9x0ElZ4xkEQ6d4gVk --dependency=primitive=primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa --dependency=repa=repa-3.4.1.1-FdCcjPvmfDZGBwGc0CsqjV --dependency=template-haskell=template-haskell-2.11.0.0 --dependency=text=text-1.2.2.1-JAnD1x1IHr6H3rdrqlXcyH --dependency=transformers=transformers-0.5.2.0 --dependency=vector=vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6 --disable-tests --exact-configuration --disable-benchmarks Configuring opencv-0.0.0... Dependency aeson ==0.11.2.1: using aeson-0.11.2.1 Dependency base ==4.9.0.0: using base-4.9.0.0 Dependency base64-bytestring ==1.0.0.1: using base64-bytestring-1.0.0.1 Dependency bindings-DSL ==1.0.23: using bindings-DSL-1.0.23 Dependency bytestring ==0.10.8.1: using bytestring-0.10.8.1 Dependency containers ==0.5.7.1: using containers-0.5.7.1 Dependency deepseq ==1.4.2.0: using deepseq-1.4.2.0 Dependency inline-c ==0.5.5.7: using inline-c-0.5.5.7 Dependency inline-c-cpp ==0.1.0.0: using inline-c-cpp-0.1.0.0 Dependency linear ==1.20.5: using linear-1.20.5 Dependency primitive ==0.6.1.0: using primitive-0.6.1.0 Dependency repa ==3.4.1.1: using repa-3.4.1.1 Dependency template-haskell ==2.11.0.0: using template-haskell-2.11.0.0 Dependency text ==1.2.2.1: using text-1.2.2.1 Dependency transformers ==0.5.2.0: using transformers-0.5.2.0 Dependency vector ==0.11.0.0: using vector-0.11.0.0 Dependency opencv -any: using version 3.1.0 Using Cabal-1.24.0.0 compiled by ghc-8.0 Using compiler: ghc-8.0.1 Using install prefix: /home/bas.van.dijk/.cabal Binaries installed in: /home/bas.van.dijk/.cabal/bin Libraries installed in: /home/bas.van.dijk/.cabal/lib/x86_64-linux- ghc-8.0.1/opencv-0.0.0-2zTtfFNABNdFAnLU4MNJ6b Private binaries installed in: /home/bas.van.dijk/.cabal/libexec Data files installed in: /home/bas.van.dijk/.cabal/share/x86_64-linux-ghc-8.0.1/opencv-0.0.0 Documentation installed in: /home/bas.van.dijk/.cabal/share/doc/x86_64-linux-ghc-8.0.1/opencv-0.0.0 Configuration files installed in: /home/bas.van.dijk/.cabal/etc No alex found Using ar found on system at: /nix/store/v77miigq2dx55ga1hxfv3k7v9a873472-binutils-2.27/bin/ar No c2hs found Using cpphs version 1.20.2 found on system at: /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/cpphs Using gcc version 5.4.0 given by user at: /nix/store/45qrn064f92kfxnjg99z39zxda671h6f-gcc-wrapper-5.4.0/bin/g++ Using ghc version 8.0.1 found on system at: /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc Using ghc-pkg version 8.0.1 found on system at: /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc-pkg No ghcjs found No ghcjs-pkg found No greencard found Using haddock version 2.17.2 found on system at: /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/haddock No happy found Using haskell-suite found on system at: haskell-suite-dummy-location Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy- location No hmake found Using hpc version 0.67 found on system at: /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/hpc Using hsc2hs version 0.68 found on system at: /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/hsc2hs Using hscolour version 1.24 found on system at: /run/current-system/sw/bin/HsColour No jhc found Using ld given by user at: /nix/store/45qrn064f92kfxnjg99z39zxda671h6f-gcc-wrapper-5.4.0/bin/g++ No lhc found No lhc-pkg found Using pkg-config version 0.29 found on system at: /nix/store/pkymfih8lf7j3ib6bfab7srri4xiyw34-pkg-config-0.29/bin/pkg-config Using strip version 2.27 found on system at: /nix/store/v77miigq2dx55ga1hxfv3k7v9a873472-binutils-2.27/bin/strip Using tar found on system at: /nix/store/blzs121zpxzms8axnblp1pbbzphrsb2r-gnutar-1.29/bin/tar No uhc found creating dist/setup ./dist/setup/setup build --verbose=2 --builddir=dist --jobs=2 Component build order: library creating dist/build creating dist/build/autogen Building opencv-0.0.0... /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc-pkg init dist/package.conf.inplace Preprocessing library opencv-0.0.0... creating dist/build/OpenCV/Core creating dist/build/OpenCV creating dist/build/OpenCV/Core ... ... Lots of calls to hsc2hs ... Building library... creating dist/build /nix/store/91grrinb827jsdr44yd2lqls9i7z2az0-ghc-8.0.1/bin/ghc \ --make \ -fbuilding-cabal-package \ -O \ -j2 \ -static -dynamic-too \ -dynosuf dyn_o -dynhisuf dyn_hi \ -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build \ -i \ -idist/build \ -isrc \ -idist/build/autogen \ -Idist/build/autogen \ -Idist/build \ -Iinclude \ -I/nix/store/gyqgb314gb2jny8xjix3bdrly50p9mrz- opencv-3.1.0/include/opencv \ -I/nix/store/gyqgb314gb2jny8xjix3bdrly50p9mrz-opencv-3.1.0/include \ -optP-include \ -optPdist/build/autogen/cabal_macros.h \ -this-unit-id opencv-0.0.0-2zTtfFNABNdFAnLU4MNJ6b \ -hide-all-packages \ -package-db dist/package.conf.inplace \ -package-id aeson-0.11.2.1-11xZO4dSHJ36B3esP34sNx \ -package-id base-4.9.0.0 \ -package-id base64-bytestring-1.0.0.1-In9M41tLtcS9QYt3QpGpNY \ -package-id bindings-DSL-1.0.23-GUrVdpTUVQC2JWoov2sGwA \ -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 \ -package-id deepseq-1.4.2.0 \ -package-id inline-c-0.5.5.7-3JCuNEZtXHO4YTLZSRWOQ2 \ -package-id inline-c-cpp-0.1.0.0-2wSjs2z7tfoLnsB36U1XGl \ -package-id linear-1.20.5-2Z9jl9x0ElZ4xkEQ6d4gVk \ -package-id primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa \ -package-id repa-3.4.1.1-FdCcjPvmfDZGBwGc0CsqjV \ -package-id template-haskell-2.11.0.0 \ -package-id text-1.2.2.1-JAnD1x1IHr6H3rdrqlXcyH \ -package-id transformers-0.5.2.0 \ -package-id vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6 \ -XHaskell2010 -XBangPatterns -XDataKinds -XFlexibleContexts \ -XFlexibleInstances -XLambdaCase -XOverloadedStrings \ -XPackageImports -XPolyKinds -XScopedTypeVariables \ -XTupleSections -XTypeFamilies -XTypeOperators \ OpenCV OpenCV.Calib3d OpenCV.Core.ArrayOps OpenCV.Core.Types OpenCV.Core.Types.Mat OpenCV.Core.Types.Mat.HMat OpenCV.Core.Types.Mat.Repa OpenCV.Core.Types.Matx OpenCV.Core.Types.Point OpenCV.Core.Types.Rect OpenCV.Core.Types.Size OpenCV.Core.Types.Vec OpenCV.Exception OpenCV.Features2d OpenCV.HighGui OpenCV.ImgCodecs OpenCV.ImgProc.ColorMaps OpenCV.ImgProc.Drawing OpenCV.ImgProc.FeatureDetection OpenCV.ImgProc.GeometricImgTransform OpenCV.ImgProc.ImgFiltering OpenCV.ImgProc.MiscImgTransform OpenCV.ImgProc.MiscImgTransform.ColorCodes OpenCV.ImgProc.ObjectDetection OpenCV.ImgProc.StructuralAnalysis OpenCV.ImgProc.Types OpenCV.JSON OpenCV.Photo OpenCV.TypeLevel OpenCV.Unsafe OpenCV.Video OpenCV.Video.MotionAnalysis OpenCV.VideoIO.VideoCapture OpenCV.Internal OpenCV.Internal.Mutable OpenCV.Internal.C.Inline OpenCV.Internal.C.PlacementNew OpenCV.Internal.C.PlacementNew.TH OpenCV.Internal.C.Types OpenCV.Internal.Calib3d.Constants OpenCV.Internal.Core.ArrayOps OpenCV.Internal.Core.Types OpenCV.Internal.Core.Types.Constants OpenCV.Internal.Core.Types.Mat OpenCV.Internal.Core.Types.Mat.Depth OpenCV.Internal.Core.Types.Mat.Marshal OpenCV.Internal.Core.Types.Mat.ToFrom OpenCV.Internal.Core.Types.Matx OpenCV.Internal.Core.Types.Matx.TH OpenCV.Internal.Core.Types.Point OpenCV.Internal.Core.Types.Point.TH OpenCV.Internal.Core.Types.Rect OpenCV.Internal.Core.Types.Rect.TH OpenCV.Internal.Core.Types.Size OpenCV.Internal.Core.Types.Size.TH OpenCV.Internal.Core.Types.Vec OpenCV.Internal.Core.Types.Vec.TH OpenCV.Internal.Exception OpenCV.Internal.ImgCodecs OpenCV.Internal.ImgProc.MiscImgTransform OpenCV.Internal.ImgProc.MiscImgTransform.TypeLevel OpenCV.Internal.ImgProc.MiscImgTransform.ColorCodes OpenCV.Internal.ImgProc.Types OpenCV.Internal.Photo.Constants \ -Wall \ -fwarn-incomplete-patterns \ -funbox-strict-fields \ -O2 [ 1 of 64] Compiling OpenCV.Internal.Photo.Constants ( dist/build/OpenCV/Internal/Photo/Constants.hs, dist/build/OpenCV/Internal/Photo/Constants.o ) [ 2 of 64] Compiling OpenCV.Internal.ImgProc.MiscImgTransform ( dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.o ) [ 3 of 64] Compiling OpenCV.Internal.ImgCodecs ( dist/build/OpenCV/Internal/ImgCodecs.hs, dist/build/OpenCV/Internal/ImgCodecs.o ) [ 4 of 64] Compiling OpenCV.Internal.Core.Types.Constants ( dist/build/OpenCV/Internal/Core/Types/Constants.hs, dist/build/OpenCV/Internal/Core/Types/Constants.o ) [ 5 of 64] Compiling OpenCV.Internal.C.PlacementNew ( src/OpenCV/Internal/C/PlacementNew.hs, dist/build/OpenCV/Internal/C/PlacementNew.o ) [ 6 of 64] Compiling OpenCV.Internal.C.PlacementNew.TH ( src/OpenCV/Internal/C/PlacementNew/TH.hs, dist/build/OpenCV/Internal/C/PlacementNew/TH.o ) [ 7 of 64] Compiling OpenCV.Internal.Mutable ( src/OpenCV/Internal/Mutable.hs, dist/build/OpenCV/Internal/Mutable.o ) [ 8 of 64] Compiling OpenCV.Internal.Core.ArrayOps ( dist/build/OpenCV/Internal/Core/ArrayOps.hs, dist/build/OpenCV/Internal/Core/ArrayOps.o ) [ 9 of 64] Compiling OpenCV.Internal ( src/OpenCV/Internal.hs, dist/build/OpenCV/Internal.o ) [10 of 64] Compiling OpenCV.Internal.Calib3d.Constants ( dist/build/OpenCV/Internal/Calib3d/Constants.hs, dist/build/OpenCV/Internal/Calib3d/Constants.o ) [11 of 64] Compiling OpenCV.Internal.C.Types ( src/OpenCV/Internal/C/Types.hs, dist/build/OpenCV/Internal/C/Types.o ) [12 of 64] Compiling OpenCV.Internal.Core.Types.Matx ( src/OpenCV/Internal/Core/Types/Matx.hs, dist/build/OpenCV/Internal/Core/Types/Matx.o ) [13 of 64] Compiling OpenCV.Internal.Core.Types.Matx.TH ( src/OpenCV/Internal/Core/Types/Matx/TH.hs, dist/build/OpenCV/Internal/Core/Types/Matx/TH.o ) [14 of 64] Compiling OpenCV.Internal.Core.Types.Point ( src/OpenCV/Internal/Core/Types/Point.hs, dist/build/OpenCV/Internal/Core/Types/Point.o ) [15 of 64] Compiling OpenCV.Internal.Core.Types.Point.TH ( src/OpenCV/Internal/Core/Types/Point/TH.hs, dist/build/OpenCV/Internal/Core/Types/Point/TH.o ) [16 of 64] Compiling OpenCV.Internal.Core.Types.Size ( src/OpenCV/Internal/Core/Types/Size.hs, dist/build/OpenCV/Internal/Core/Types/Size.o ) [17 of 64] Compiling OpenCV.Internal.Core.Types.Size.TH ( src/OpenCV/Internal/Core/Types/Size/TH.hs, dist/build/OpenCV/Internal/Core/Types/Size/TH.o ) [18 of 64] Compiling OpenCV.Internal.Core.Types.Vec ( src/OpenCV/Internal/Core/Types/Vec.hs, dist/build/OpenCV/Internal/Core/Types/Vec.o ) [19 of 64] Compiling OpenCV.Internal.Core.Types.Vec.TH ( src/OpenCV/Internal/Core/Types/Vec/TH.hs, dist/build/OpenCV/Internal/Core/Types/Vec/TH.o ) [20 of 64] Compiling OpenCV.Internal.C.Inline ( src/OpenCV/Internal/C/Inline.hs, dist/build/OpenCV/Internal/C/Inline.o ) [21 of 64] Compiling OpenCV.Core.Types.Size ( src/OpenCV/Core/Types/Size.hs, dist/build/OpenCV/Core/Types/Size.o ) [22 of 64] Compiling OpenCV.Core.Types.Vec ( src/OpenCV/Core/Types/Vec.hs, dist/build/OpenCV/Core/Types/Vec.o ) [23 of 64] Compiling OpenCV.TypeLevel ( src/OpenCV/TypeLevel.hs, dist/build/OpenCV/TypeLevel.o ) [24 of 64] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.TypeLevel ( src/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.o ) [25 of 64] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.o ) [26 of 64] Compiling OpenCV.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/ImgProc/MiscImgTransform/ColorCodes.o ) [27 of 64] Compiling OpenCV.Internal.Core.Types.Mat.Depth ( src/OpenCV/Internal/Core/Types/Mat/Depth.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Depth.o ) [28 of 64] Compiling OpenCV.Internal.Exception ( src/OpenCV/Internal/Exception.hs, dist/build/OpenCV/Internal/Exception.o ) [29 of 64] Compiling OpenCV.Exception ( src/OpenCV/Exception.hs, dist/build/OpenCV/Exception.o ) [30 of 64] Compiling OpenCV.Internal.Core.Types.Mat.Marshal ( dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.o ) [31 of 64] Compiling OpenCV.Core.Types.Point ( src/OpenCV/Core/Types/Point.hs, dist/build/OpenCV/Core/Types/Point.o ) [32 of 64] Compiling OpenCV.Internal.Core.Types ( src/OpenCV/Internal/Core/Types.hs, dist/build/OpenCV/Internal/Core/Types.o ) [33 of 64] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1001/ghc8697_0/libghc_200.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [36 of 64] Compiling OpenCV.Internal.Core.Types.Rect ( src/OpenCV/Internal/Core/Types/Rect.hs, dist/build/OpenCV/Internal/Core/Types/Rect.o ) [37 of 64] Compiling OpenCV.Internal.Core.Types.Rect.TH ( src/OpenCV/Internal/Core/Types/Rect/TH.hs, dist/build/OpenCV/Internal/Core/Types/Rect/TH.o ) [38 of 64] Compiling OpenCV.Core.Types.Rect ( src/OpenCV/Core/Types/Rect.hs, dist/build/OpenCV/Core/Types/Rect.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1001/ghc8697_0/libghc_206.so: undefined symbol: inline_c_OpenCV_Core_Types_Point_19_5c3d561e8841e5271fd465bfb109504b1d56b3f6 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [39 of 64] Compiling OpenCV.Core.Types.Matx ( src/OpenCV/Core/Types/Matx.hs, dist/build/OpenCV/Core/Types/Matx.o ) }}} The details are in https://github.com/NixOS/nixpkgs/issues/18558. It's worth repeating here that I've successfully build `haskell-opencv` with GHC-8.0.1 before on an older version of `nixpkgs`. So it has probably something to do with how GHC is packaged in `nixpkgs` or with the used `binutils`. However, a GHC panic should also warrant a ticket on the GHC bug tracker so here it is. Although this ticket is about GHCi and I'm using GHC do note that `haskell-opencv` makes use of template-haskell in lots of places which I believe is using GHCi internally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 00:51:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 00:51:02 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.196c9e794612a4c3c7ce973b2ea903ac@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 01:40:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 01:40:05 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.a8572048ae0e4f28d43b76c920d2ac8d@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mistydemeo): GHC is deleting the temp shared object immediately after the build fails; is there a flag I can set to keep it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 05:39:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 05:39:12 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.12c9b5f7de6f24cd45330aaf796f5588@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mistydemeo): Okay, got it - I fetched the actual `ghc` invocation from `cabal` and added `-keep-tmp-files`. I've attached the output of `otool -l`, which contains the load commands, and the dylib itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 05:54:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 05:54:48 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.74cdefd5bb120aaf762ae1361ecf9e83@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mistydemeo): * Attachment "load_commands.txt" added. Output of otool -l libghc_29.dylib -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 05:55:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 05:55:46 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.e2404ea17740aea7f570c9ae67754231@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mistydemeo): * Attachment "objdump_x.txt" added. Output of gobjdump -x (GNU objdump, not LLVM objdump) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 05:57:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 05:57:01 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.c1238ca8cb658b365140ff7e494ed716@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mistydemeo): * Attachment "libghc_29.dylib.xz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 07:40:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 07:40:28 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.6795820e45d0b6c5a5588fa7d4bc0baf@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | 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 adamgundry): I'm inclined to agree that we could just change this, and mention in the new docs that the function had different behaviour in older versions of `base`. While we're at it, perhaps it is worth explicitly documenting the fact that `setEnv` is not thread safe? This may be obvious to others, but it wasn't to me, and has been causing segfaults in a production Haskell application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 07:53:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 07:53:28 -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.bd51c9ca5e8d8019d056ff6c2aaeb8d9@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > I suspect I'm overthinking this or am missing something, but won't we still have this issue if we have multiple modules but one explicitly specifies -fignore-interface-pragmas? This has been a long thread and I'm having trouble understanding your question. E.g. what is "this issue" in the above? Would you like to ask the question again, from scratch as it were, illustrated by a concrete example? And presumably when you say "won't we ''still'' have" you mean "won't we still have it when we have done X". But what precisely is X? Perhaps you could lay that out too. Then your question wouldn't depend on having paged in 36 previous comments :-). Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 08:09:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 08:09:09 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.11b20e169a82c53e365cd52e584eba4a@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | 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 simonmar): * owner: => simonmar Comment: I think I see the problem: `genSwitch` is assuming that it can modify the register it got from evaluating the scrutinee, but it has no right to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 09:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 09:23:46 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.2a14be0bf5bbf5c9ade77491ce10cc4b@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2529 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D2529 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 12:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 12:23:46 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.df2bbdee0f7b4b3691bdbcfe56b17b32@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2529 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"86836a2ecc089b917866a2cb65b716fd5f04cc56/ghc" 86836a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="86836a2ecc089b917866a2cb65b716fd5f04cc56" Fix codegen bug in PIC version of genSwitch (#12433) Summary: * getNonClobberedReg instead of getSomeReg, because the reg needs to survive across t_code * Use a new reg for the table offset calculation instead of clobbering the reg returned by expr (this was the bug affecting #12433) Test Plan: New unit test; validate Reviewers: rwbarton, bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2529 GHC Trac Issues: #12433 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 12:44:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 12:44:20 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.647b6d3c4d885e397c63facda8cc7fe1@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2529 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 14:41:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 14:41:41 -0000 Subject: [GHC] #12015: Add conditional CallStack constraints to common partial utility functions In-Reply-To: <046.b74d0515b345cdd045765b55c27f0b21@haskell.org> References: <046.b74d0515b345cdd045765b55c27f0b21@haskell.org> Message-ID: <061.49903e7c7a86e62bd810aa274604191d@haskell.org> #12015: Add conditional CallStack constraints to common partial utility functions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Phab:D2527 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Landed in 626db8f82e734e48eef5ce7676a5233f98fe7145. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 15:08:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 15:08:47 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.ca81e943d7fbc8f8283613dc434459e2@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | 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 Iceland_jack): [https://www.reddit.com/r/haskell/comments/52una4/question_from_a_beginner_is_there_a_way_to_make_a/d7nid20 example]: > You could do: > > {{{#!hs > data LeafNode a = LeafNode { leafMeta :: LeafMetaData, things :: [a] } > }}} > > And then put the constraint in your functions instead: > > {{{#!hs > myFun :: MyTypeClass a => LeafNode a -> b > myFun = undefined > }}} {{{#!hs myFun :: MyTypeClass a => LeafNode a -> b }}} would be valid syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 15:37:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 15:37:39 -0000 Subject: [GHC] #12370: Implement LetUp in DmdAnal (or document why we do not do it) In-Reply-To: <046.4d0b4649e15ed41a4a32187881ac4332@haskell.org> References: <046.4d0b4649e15ed41a4a32187881ac4332@haskell.org> Message-ID: <061.6c563405c119815cb0086c1e01f7f7f5@haskell.org> #12370: Implement LetUp in DmdAnal (or document why we do not do it) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: 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:D2395 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 15:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 15:59:27 -0000 Subject: [GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) In-Reply-To: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> References: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> Message-ID: <060.bc722ef65cecd3600334a3b015d200a7@haskell.org> #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 nomeata): JFTR: Still present in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 16:24:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 16:24:03 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.4bfe6f047a6aeada44356ed98e23fa07@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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:"a72d798ce948b054f47d7acd72799384cf06deea/ghc" a72d798c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a72d798ce948b054f47d7acd72799384cf06deea" Comments in TH.Syntax (Trac #12596) See Note [Data for non-algebraic types] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 16:26:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 16:26:21 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.0246db0b8098a6dd9eeaa7539c97f7d2@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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: | -------------------------------------+------------------------------------- @@ -3,1 +3,1 @@ - ``` + {{{ @@ -12,1 +12,3 @@ - ``` + }}} + + The code is New description: full repro at https://github.com/mwotton/liftwoes/issues/1 {{{ /home/mark/projects/liftwoes/src/Lib.hs:14:11: error: • Can't find interface-file declaration for variable Data.Text.Internal.pack 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 first argument of ‘(:)’, namely ‘Data.Text.Internal.pack ((:) 'A' [])’ In the first argument of ‘HS.fromList’, namely }}} The code is {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module Lib where import Data.Data import qualified Data.Set as HS import qualified Data.Text as T import qualified Data.Text.IO as T import Data.Time -- import Instances.TH.Lift import Instances import Language.Haskell.TH.Syntax table = $(do r <- runIO (HS.fromList . T.lines <$> T.readFile "/usr/share/dict/words") [|r|] ) someFunc = do print $ HS.member "foo" table }}} -- Comment (by simonpj): Yes, `bytemyapp` on the [https://github.com/mwotton/liftwoes/issues/1 github repo] is right. Here's a shorter example {{{ {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module T12596 where import qualified Data.Set as HS import qualified Data.Text as T import Language.Haskell.TH.Syntax table = $(do let r2 :: T.Text r2 = "he" :: T.Text liftData r2 ) }}} * `liftData` is defined in `Language.Haskell.TH.Syntax`: {{{ liftData :: Data a => a -> Q Exp liftData = dataToExpQ (const Nothing) }}} * So we need `Data Text`. The `Data` class is intended to describe algebraic data types, but the `text` package cleverly uses it to make `Text` behave like an algebraic data type, even though it isnt'. * Using the `toConstr` method of `instance Data Text` (in module `Data.Text`), it pretends that `Text` has a data constructor called `pack :: String -> Text`. This function is defined in `Data.Text`. * But `toConstr :: Data a => a -> Constr` and `Constr` is a record giving only the ''string name'' of the constructor. {{{ data Constr = Constr { conrep :: ConstrRep , constring :: String , confields :: [String] -- for AlgRep only , confixity :: Fixity -- for AlgRep only , datatype :: DataType } }}} It was really only intended for 'show'. * But here it's being used `Language.Haskell.TH.Syntax.dataToQa` to make a Template Haskell `Name` for `pack`. It uses `mkNameG_v` passing the string for the "data constructor" (`pack`) but the module for the type constructor. That is, `dataToQa` assumes that the data constructor is defined in the same module as the type constructor, which is usually reasonable. Moreover, it has no other choice because `Constr` simply doesn't record the full, original `Name` of the data constructor. So that's the story. It took me some while to puzzle it out! And it's clearly unhelpful to users. Meanwhile, what can we do? * Refactor the `text` package so that the function mentioned in `Data.Text.packConstr` is actually defined in the same module as the data type `Text` itself. * (Better.) Make `Data.Data.Constr` contain a Template Haskell `Name` for the data constructor, rather than just a `String`. Doing that would mean moving `Language.Haskell.TH.Syntax.Name` (and associated types and functions) to package `base`. This would make sense to me; class `Data` is really about meta-programming. The `constring` record selector could be come an ordinary function, so almost all programs would work fine. Any opinions.? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 16:37:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 16:37:19 -0000 Subject: [GHC] #12597: -Wmissing-signatures uses forall even when invalid in source In-Reply-To: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> References: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> Message-ID: <061.fb7b441d5a155665615d93832a2f386d@haskell.org> #12597: -Wmissing-signatures uses forall even when invalid in source -------------------------------------+------------------------------------- Reporter: nomeata | 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): Good point. Easy fix in-flight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 16:41:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 16:41:47 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.44d78c0e6cd6a9550d4d6ca7ee96a5df@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- 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): To make it easier to read the ticket, the code is very short. {{{ {-# LANGUAGE GADTs, ConstraintKinds, PolyKinds, TypeInType, KindSignatures, RankNTypes #-} module T12593 where import Data.Kind newtype Free k p a b where Free :: (forall q. k q => (forall c d. p c d -> q c d) -> q a b) -> Free k p a b run :: k2 q => Free k k1 k2 p a b -> (forall (c :: k) (d :: k1). p c d -> q c d) -> q a b run (Free cat) = cat }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 16:43:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 16:43:02 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.fb3aa1312ad60b49128db7a91f7a724a@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- 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 simonpj): * cc: goldfire (added) Comment: Yes, I can reproduce this with HEAD. It seems that we are updating a unification variable so that it points to itself. I see {{{ Following filled tyvar k_arL[tau:1] = (k_apN[sk] |> Sym U(hole:{arZ}, *, (((k_arR[tau:1] -> k_arU[tau:1] -> TYPE t_arG[tau:1]) -> Constraint) -> (k_arL[tau:1] -> k_arO[tau:1] -> TYPE t_arJ[tau:1]) -> *) -> Constraint)_N) }}} And that is disaster. Remarkable example! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 16:57:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 16:57:05 -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.b03693eec0b6851e8c3b34f5fed71cb9@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by richardfung): Ah yes sorry I shall try to keep my comments more self contained. The ticket addresses the issue that the unfolding info seen depends on previously compiled modules with --make. As I understand it, this can either cause ghc to inline when it shouldn't (in -O0) or to be unable to inline when it should. For example, if we have modules A and B, both which import module C, and we assume A is built first, then whether B sees the interface pragmas of C is dependent on whether they were read in when compiling A. If A is built with -O0, then even if B is built with -O it can not inline things from C because it doesn't have the unfolding info. Alternatively, if A is built with -O and B is built with -O0, B will still see the unfolding info and use it. The suggested fix is to disable -fignore-interface-pragmas being implied by -O0 and to make sm_inline = False when -O0. I do believe this solves both of the scenarios described above, but I'm concerned that if A is built with -fignore-interface-pragmas, and B is built with -O, B will still not have the unfolding info from C when compiling. This would be identical to what's currently happening when A is built with -O0 and B with -O. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 17:44:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 17:44:28 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore Message-ID: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Andrey wrote requesting the following, > For top-level `.gitignore`: > {{{ > # ------------------------------------------------------------------------------------- > # Hadrian's stuff. Note, **/stageN/ folders will be relocated to _build/ after > # resolving https://github.com/snowleopard/hadrian/issues/113 > # ------------------------------------------------------------------------------------- > _build/ > hadrian/ > **/stage?/ > }}} > > For `.gitignore` in affected submodules (array, deepseq, directory, filepath, > hoopl, hpc, process, utils/hsc2hs): > > {{{ > # ------------------------------------------------------------------------------------- > # Hadrian's stuff. Note, stageN/ folders will be relocated to top-level _build/ > # after resolving https://github.com/snowleopard/hadrian/issues/113 > # ------------------------------------------------------------------------------------- > stage?/ > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 17:45:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 17:45:04 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.1a4437a87c5efbb673e63713a09995ba@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As indicated in the comments, these entries would disappear when https://github.com/snowleopard/hadrian/issues/113 is resolved. Consequently, I'm not entirely sure this is something we really want to do since it will pollute a large number of repositories outside of GHC. I'm going to see what it would take to resolve the issue in hopes that we can avoid adding the gitignores. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 17:45:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 17:45:13 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.231088aac99fddda179cbfecf03b3360@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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 bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 17:45:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 17:45:44 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.a332511a80197b138d7d272904e9e88b@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: #8040 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #8040 Comment: It seems like one of the first things to look at is #8040. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 17:49:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 17:49:15 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.77fb0d88abe21313f8a8868204e43272@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: #8040 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 17:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 17:50:46 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.c816f15d3c1f74813e200b8ba6a73dbb@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2529 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as a0472f8dd29037412c61cbd42537863ad18b74f0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 18:56:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 18:56:49 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.6980c21cd9f9edbf2defe7e21574743e@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as c51caafae7669d4246f4efd3d1a6858020780e02. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 18:57:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 18:57:00 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.3e90cfd4ebce74aff67b1433857bcf98@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 18:57:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 18:57:40 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.da1b4a1c313b3720fa4b2ebf0354b106@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | ErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: This won't be happening for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:03:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:03:42 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.0a8438de938572dbe99672cfcbe6c21d@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.6.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:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2530 Comment: See Phab:D2530 for a possible fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:03:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:03:51 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.ce708427f46d18d1f8c07af2d1e686ed@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.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:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:04:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:04:22 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.361ead0626f1e03330134be11b9bcbe1@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: #8040 | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2530 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:14:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:14:23 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.e5bb8d28a3635001a15aa68465fc69cd@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, oddly enough I encounter a completely unrelated segfault(!) while building `functor-infix` when trying to reproduce this. GHC appears to crash right after linking. It seems your project is cursed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:22:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:22:08 -0000 Subject: [GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) In-Reply-To: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> References: <045.547298c8cb37685b01e9dab587a5f31f@haskell.org> Message-ID: <060.cec57ab18bcd1bac8daedd17cc7e75c5@haskell.org> #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 nomeata): From looking hard at these examples, I would say it “just” floating out getting into the way for applying rules, which is a general problem. At least for the `artificial_example`. Hard to predict if the casts would get in the way if the float out would not prevent the rule from firing in the simple case, but one step at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:36:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:36:23 -0000 Subject: [GHC] #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) In-Reply-To: <046.d1ae7430915d73dc87cb51fdc7878bad@haskell.org> References: <046.d1ae7430915d73dc87cb51fdc7878bad@haskell.org> Message-ID: <061.8fe17c7bf222138541d2f3a800a7615d@haskell.org> #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | 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): * status: new => closed * resolution: => fixed Comment: This is actually fixed, at least in 7.10, most likely by changeset:a27b2985511800fa3b740fef82ad3da9c8683302/ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 19:45:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 19:45:35 -0000 Subject: [GHC] #5974: Casts, rules, and parametricity In-Reply-To: <046.3b532cdbabf8e03bcada1a28adeccdd5@haskell.org> References: <046.3b532cdbabf8e03bcada1a28adeccdd5@haskell.org> Message-ID: <061.626023459a69300b53a038a8f45c7e94@haskell.org> #5974: Casts, rules, and parametricity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.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 a small remark: The rule {{{ {-# RULES "foo" forall (f:: y -> z) (xs :: [x]) . map f (coerce xs) = map (coerce f) xs #-} }}} mentioned above is accepted by GHC-8, and takes this form in Core: {{{ "foo" [ALWAYS] forall (@ y_axE) (@ z_axF) (@ x_axG) ($r$dCoercible_dJK :: ([x_axG] :: *) ~R# ([y_axE] :: *)) (f_axC :: y_axE -> z_axF) (xs_axD :: [x_axG]). map @ y_axE @ z_axF f_axC (xs_axD `cast` ($r$dCoercible_dJK :: ([x_axG] :: *) ~R# ([y_axE] :: *))) = map @ x_axG @ z_axF (f_axC `cast` (Nth:0 (Sym $r$dCoercible_dJK) -> _R :: ((y_axE -> z_axF) :: *) ~R# ((x_axG -> z_axF) :: *))) xs_axD }}} which looks somewhat nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 20:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 20:59:08 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.f69f2f6325873730e9ce303c184de54f@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I managed to reproduce this. It has something to do with BangPatterns apparently. Here is a reproducer with just two modules: {{{ -- U.hs module U where u :: Int u = 1 -- Main.hs {-# LANGUAGE BangPatterns #-} import U main = print $ let !x = u in x }}} `ghc-8.0.1 -O Main` fails with the same sort of linker error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 21:02:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 21:02:10 -0000 Subject: [GHC] #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) In-Reply-To: <046.d1ae7430915d73dc87cb51fdc7878bad@haskell.org> References: <046.d1ae7430915d73dc87cb51fdc7878bad@haskell.org> Message-ID: <061.84f5ce859dc5165976c0472ed52c561e@haskell.org> #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | 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): Great! Might you add a test case to make sure it ''stays'' fixed? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 21:12:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 21:12:30 -0000 Subject: [GHC] #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) In-Reply-To: <046.d1ae7430915d73dc87cb51fdc7878bad@haskell.org> References: <046.d1ae7430915d73dc87cb51fdc7878bad@haskell.org> Message-ID: <061.5895ba5ace255986a4e6d835b6e9b991@haskell.org> #7611: Rewrite rules application prevented by type variable application (map id vs. map (\x -> x)) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: fixed | 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 Joachim Breitner ): In [changeset:"97b47d277d6b0ced3ce73175f78b23ecff84cfa3/ghc" 97b47d27/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="97b47d277d6b0ced3ce73175f78b23ecff84cfa3" Add test case for #7611 basically using the machinery from the test case of #2110. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 21:12:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 21:12:30 -0000 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@haskell.org> Message-ID: <059.82305fbcf3d89e902d757de25990cb21@haskell.org> #2110: Rules to eliminate casted id's -------------------------+------------------------------------------------- Reporter: | Owner: igloo | Type: | Status: closed feature request | Priority: | Milestone: 7.10.1 lowest | Component: | Version: 6.8.2 Compiler | Resolution: | Keywords: fixed | Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: | Test Case: tests/simplCore/should_run/T2110 None/Unknown | Blocked By: | Blocking: Related Tickets: | #8767 | -------------------------+------------------------------------------------- Comment (by Joachim Breitner ): In [changeset:"97b47d277d6b0ced3ce73175f78b23ecff84cfa3/ghc" 97b47d27/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="97b47d277d6b0ced3ce73175f78b23ecff84cfa3" Add test case for #7611 basically using the machinery from the test case of #2110. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 21:18:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 21:18:08 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.ead8e8bc8b473dba801b2e4d772d39af@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great test case thank you Reid. It's something to do with desugaring of bang patterns. Stay tuned. I'm on a plane tomorrow... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 21:36:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 21:36:00 -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.725da768aa926ba6cc3ee3ae01a2ee87@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by simonpj): You're right. Maybe we should move `-fignore-interface-pragmas` to `-dignore-interface-pragmas`; that is, make it a debug flag not intended for generic users but rather for people who know what they are doing. Or else remove it altogether. I don't mind which; I have never used it myself. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 15 23:53:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Sep 2016 23:53:05 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.6a1b33c1d309ac4567348c7badf6ba4c@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Comment (by bgamari): On Phab:D2133 Simon said (paraphrasing), > Consider these two export lists > a. {{{module M( Vec2( Nil, Cons ) ) where ...}}} > > b. {{{module M( Vec2( Nil, Cons ), pattern Cons ) where ...}}} > {{{ > These should generate precisely the same .hi file, but they don't. They look like > a. {{{ > exports: > Vec2{Cons Nil} > }}} > b. {{{ > exports: > Cons > Vec2{Cons Nil} > }}} It's not entirely clear to me that this is true. Consider these two export lists, 1. {{{module M( Vec2( Nil, Cons ) ) where ...}}} 2. {{{module M( Vec2, pattern Nil, pattern Cons ) where ...}}} These two mean quite different things for the end-user when they go to import this module. Namely, they will need to use, respectively, 1. {{{import M(Vec2(Cons))}}} 2. {{{import M(Cons)}}} Note that the user cannot import the definitions from export list (1) with import list (2) and vice versa. This means that if the user gives us export list (b) from above and we map it to the same exports as produced by export list (a), we have made a non- obvious decision for the user, who now cannot use import list (2) to import `Cons` from `M`. It is possible we have even acted against `M`'s author's will, which was to allow both import lists. While we're discussing this, I'd also point out that there is a bit of inconsistency in how we treat bundled things. Consider, {{{#!hs module AModule ( ARecord(..) ) where data ARecord = ARec { hello :: Int } }}} In this case one could use either {{{#!hs import AModule (hello) -- or... import AModule (ARecord(hello)) }}} to import `hello` (although the `ARec` constructor must be imported in "bundled" style). While this makes some amount of sense (since selectors can be easily thought of as either free-floating functions or parts of data), it does make me wonder whether we should be equally liberal in the case of patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 01:49:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 01:49:14 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization Message-ID: <043.07cdd679c81a8644725c82782d392414@haskell.org> #12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | 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 `foo` function in the following code does not get specialized completely by `ghc -O2`, even though all the overloaded functions in the module are marked `INLINE`. Specifically, it gets compiled into a call to a function with an `Eq Int` dictionary passed at runtime. {{{#!hs module Foo where class Eq1 f where eq1 :: (Eq a) => f a -> f a -> Bool data F a = F !a !a data G f a = G !(f a) !(f a) instance Eq1 F where eq1 = \(F a b) (F c d) -> -- In order to reproduce the problem, the body of this function needs to be -- large enough to prevent GHC from voluntarily inlining it. larger $ larger $ larger $ larger $ larger $ larger $ a == c && b == d {-# INLINE eq1 #-} larger :: a -> a larger = id {-# NOINLINE larger #-} instance (Eq1 f) => Eq1 (G f) where eq1 = \(G a b) (G c d) -> eq1 a c && eq1 b d {-# INLINE eq1 #-} foo :: G F Int -> G F Int -> Bool foo a b = eq1 a b }}} Looking at the dumps, it looks like there may be a problem is the specializer. It creates a specialization of `eq1` with the type `(Eq a) => G F a -> G F a -> Bool` rather than the fully-specialized type: `G F Int -> G F Int -> Bool` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 02:08:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 02:08:25 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.5b4ee127ac7a361651027f6fa1a4bf44@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 akio): Perhaps this is related to #10434. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 05:36:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 05:36:35 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.c930d4f9361810efb40c7bd8dcf1a527@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: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: liyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 13:19:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 13:19:45 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.22486c7cbad64eb4eb8a497144ab4de7@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 13:20:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 13:20:04 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.3cf5c82478300bab145a9bc2180cfb11@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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, we certainly //could// migrate `Language.Haskell.TH.Syntax.Name` to `base`. We could also just bundle the package and module name of the function into `Data.Data.Constr` (i.e., `conpackage` and `conmodule`) as `String`s and avoid any migration (at the cost of some code duplication). Either option sounds palatable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 13:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 13:21:01 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.5a30a0c0459766b89f837cef415a9595@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I haven't thought about this very long, but can't you use environments to achieve what you want? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 13:22:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 13:22: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.8455bd93a9df4bf646fa7d59edd27f28@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): If you're not working on it right now, I might hack on it on the plane to ICFP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 13:43:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 13:43:11 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.a943dcebba7376b1c78f92d937d6c86e@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | 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): An intermediate position, which I think I prefer, would be to define a type of "global" names, somthing like this {{{ data GlobalName = GN { gn_pkg :: PkgName , gn_mod :: ModName , gn_occ :: OccName } }}} and use that in `base`. Then a Template Haskell `Name` coudl be a `GlobalName`, but it could also be a number of other TH-specific forms which don't belong in `base`. Doing this would break some (but perhpas not many) TH clients. I'm not sure if it's worth it. Perhaps an intermediate position is to define `GlobalName` in `base` and use it in `Constr`, but not (yet) inflict it on TH. That's more like your "duplicate it" approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 14:12:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 14:12:26 -0000 Subject: [GHC] #11403: Provide a way to make fast in-calls into Haskell In-Reply-To: <047.229ab9cf5012cda52cb555166898d5f0@haskell.org> References: <047.229ab9cf5012cda52cb555166898d5f0@haskell.org> Message-ID: <062.41cee0bc458a5649880f1b3cd1105e43@haskell.org> #11403: Provide a way to make fast in-calls into Haskell -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 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 simonmar): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: We now have a way to call `tryPutMVar()` from C without creating a new Haskell thread: https://phabricator.haskell.org/rGHC454033b54e2f7eef2354cc9d7ae7e7cba4dff09a I think this is the best we can do here, so I'll close the ticket. Feel free to re-open if this doesn't work for your use case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 14:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 14:45:49 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.2ffa17f165d132c2a70f260cb63aba14@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Carter astutely pointed out that `config.mk` enables GHC's `SplitObjs` build system setting on those platforms that support it (of which OS X is one). The real question is why this only started breaking now. I checked the Mach-O specification and there is no mention of any limit on the number of load commands, so presumably this is some artificial limit imposed by the linker. Carter suggested that perhaps Sierra moved to the LLVM linker, `lld`, but I see no mention of this error message in the `lld` repository. Very mysterious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 15:10:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 15:10:25 -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.1370db78153139aa1946e81ff821c128@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): Feel free! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 15:28:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 15:28:08 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.8ec1c38b73cad77c3462d270393b9a03@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- 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 Iceland_jack): I'm glad my penchant for disaster can be put to good use -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 16:12:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 16:12:17 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.7ceed56ee901b417257330fb5db7401e@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: Actually, it looks like we have little choice but to disable split sections on all OS X builds since we won't know what linker is being used to do the final link until runtime. Sadly this means that Darwin binary distribution sizes will grow but that's a price that OS X users will just need to pay. I'll get a patch in to 8.0.2 doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 16:17:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 16:17:19 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.0d5e206d80a409133eca744363330fba@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As it turns out there is already autoconf logic to disable to detect related Apple brokenness in `configure.ac` (#4013). That being said, it seems quite insufficient since, as related above, there's no reason to believe that the linker at `configure`-time is the same linker that will be used by the built compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 16:19:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 16:19:25 -0000 Subject: [GHC] #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file In-Reply-To: <044.b3c446bdd3dce3cd5904fc0efd480ecf@haskell.org> References: <044.b3c446bdd3dce3cd5904fc0efd480ecf@haskell.org> Message-ID: <059.58809f527d0c305aa5337c2493c44d5f@haskell.org> #4013: build fails on OS X: Invalid Mach-O file:Address out of bounds while relocating object file ----------------------------------------+------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by bgamari): It seems that Apple has broken split-sections again; see #12479. Also, it's not clear that an autoconf check is enough to guarantee that users aren't affected by this issue. There's no reason to believe that the linker at `configure`-time is the same linker that will be used by the built compiler (consider, for instance, the case of a binary distribution built on a working toolchain but downloaded and used on a broken toolchain). I think we have little choice but to just disable split sections on OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 16:20:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 16:20:52 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.0032fc91af4051e440dfde2c885536e7@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.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:D2530 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ea310f9956179f91ca973bc747b0bc7b061bc174/ghc" ea310f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ea310f9956179f91ca973bc747b0bc7b061bc174" Remove directories from include paths Previously this was a relative path which worked in the GHC tree, but failed elsewhere. This caused trouble for out-of-tree users as well as Hadrian, which wants to move build artifacts out of the working directory. Fixes #8040. Test Plan: Validate Reviewers: thomie, austin, snowleopard, hvr Reviewed By: snowleopard, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2530 GHC Trac Issues: #8040 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 17:14:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 17:14:42 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.4860a5fee1831109da7848427c7cec27@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2532 Comment: I think we want something like Phab:D2532 although I'm still investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 17:16:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 17:16:29 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.babc68f7ce7169948c15124ed7a0fd59@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I've still seen failures of `setnumcapabilities001` since comment:3 was pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 17:57:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 17:57:45 -0000 Subject: [GHC] #12601: explicit foralls do not distinguish applicable types Message-ID: <044.1491c1ceb391983b8df70a1a35b67802@haskell.org> #12601: explicit foralls do not distinguish applicable types -------------------------------------+------------------------------------- Reporter: dmwit | 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: -------------------------------------+------------------------------------- From [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #visible-type-application the documentation for TypeApplications]: "When printing types with -fprint-explicit-foralls enabled, type variables not available for visible type application are printed in braces. Thus, if you write myLength = length without a type signature, myLength‘s inferred type will be forall {f} {a}. Foldable f => f a -> Int." This implies that type variables that ''are'' available for type application are ''not'' printed braces (though I admit that it doesn't say so outright!). With that in mind, I find the following behavior confusing: {{{ > :set -XTypeApplications -fprint-explicit-foralls > :t (1 :: Num a => a) (1 :: Num a => a) :: forall {a}. Num a => a > (1 :: Num a => a) @Int 1 }}} The :t query seems to indicate that the type variable is not available, but the evaluation query seems to indicate that it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 16 20:11:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Sep 2016 20:11:51 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.1bec56bb7ebe0df3686eb25841be09f9@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Austin says, {{{ bgamari: FWIW, the load commands stuff is part of dyld, not LLVM at all. Which makes sense because this is a dynamic linking problem at load time, and not one with the object linker trying to statically link some objects together at runtime ("Loading temp shared object failed..." implies it actually built the dylib). The bad part about this is Apple hasn't published the new source code for dyld in Sierra, so there's no rhyme or reason as to why just yet. Look at 'ImageLoaderMachO::sniffLoadCommands' here: http://opensource.apple.com/source/dyld/dyld-353.2.1/src/ImageLoaderMachO.cpp?txt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 04:19:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 04:19:01 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types In-Reply-To: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> References: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> Message-ID: <066.83a13a561f0ce826cb4a3c2b6cc31766@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack 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 Iceland_jack): [http://stackoverflow.com/questions/12963733/writing-cojoin-or-cobind- for-n-dimensional-grid-type/13102103#13102103 (p ->)] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 10:38:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 10:38:16 -0000 Subject: [GHC] #11819: Full validation issues for 8.0.1 In-Reply-To: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> References: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> Message-ID: <061.06dd4f0674382ec0d4ec871d6f7cb097@haskell.org> #11819: Full validation issues for 8.0.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): 7afb7adf45216701e4f645676ecc0668f64b424d fixes the in-scope set failure on `PatBind`: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.0.1.20160916 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:2008:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2044:17 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:1986:3 in ghc:TyCoRep in_scope InScope [apd :-> a_apd[sk], apm :-> a_apm[tau:3], apn :-> t_apn[tau:3]] tenv [ap4 :-> t_apn[tau:3], apd :-> a_apm[tau:3]] tenvFVs [ap5 :-> t_ap5[tau:3], apm :-> a_apm[tau:3], apn :-> t_apn[tau:3]] cenv [] cenvFVs [] tys [a_apd[sk] -> a_apd[sk]] cos [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for PatBind(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 10:42:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 10:42:41 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.853647ea643527f7d6d5c67411f20ead@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.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: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): 7afb7adf45216701e4f645676ecc0668f64b424d fixes `top_instantiate` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 11:57:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 11:57:34 -0000 Subject: [GHC] #12558: GHCi Segmentation fault/access violation in generated code In-Reply-To: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> References: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> Message-ID: <059.fb4642cec737d9fbf488ba68f48182dc@haskell.org> #12558: GHCi Segmentation fault/access violation in generated code -------------------------------+----------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+----------------------------- Comment (by Phyx-): Hi, Thanks for the report. I have completely missed this. Unfortunately this repro is way way to large. I'm even having trouble reproducing it from the released `8.0.1` due to all the dependencies required for that package. Does your project contain any C sources? Can you try and make a repo with a smaller dependency chain? one without the need of `old-time` would be especially great since there are a few issues compiling that and GHC 8. Likely the segfault is coming from one of your dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 11:58:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 11:58:02 -0000 Subject: [GHC] #12558: GHCi Segmentation fault/access violation in generated code In-Reply-To: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> References: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> Message-ID: <059.db849d720261217ff7320cd30dd2017d@haskell.org> #12558: GHCi Segmentation fault/access violation in generated code -------------------------------+----------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+----------------------------- Changes (by Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 13:20:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 13:20:39 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.17a8a2977ca68dc54ee6fcb4301d8be8@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by simonmar): Oh dear. Which ways? What errors? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:30:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:30:14 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.82bcafe59facd681fa7b18e75833a7a0@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2533 Comment: @varosi sorry this took so long. If you still have the system would you be willing to test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:41:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:41:19 -0000 Subject: [GHC] #12602: Add NUMA support to Windows Message-ID: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> #12602: Add NUMA support to Windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: 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: #11054 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add support for NUMA for Windows. Core APIs are here https://msdn.microsoft.com/en- us/library/windows/desktop/aa363804(v=vs.85).aspx and map pretty closely to the Linux ones for our needs. Support is just filling in the gaps in the new functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:41:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:41:39 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.47f31d0c47c73a3f84795711876bd526@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:41:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:41:45 -0000 Subject: [GHC] #12602: Add NUMA support to Windows In-Reply-To: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> References: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> Message-ID: <059.3fe5ae36fe5d967f8b33208a99cfc8bb@haskell.org> #12602: Add NUMA support to Windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- 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: #11054 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:51:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:51:47 -0000 Subject: [GHC] #12602: Add NUMA support to Windows In-Reply-To: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> References: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> Message-ID: <059.69bdc406841703ce33d6d3cd5496f905@haskell.org> #12602: Add NUMA support to Windows -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11054 | Differential Rev(s): Phab:D2534 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * failure: None/Unknown => Other * differential: => Phab:D2534 * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:51:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:51:58 -0000 Subject: [GHC] #12602: Add NUMA support to Windows In-Reply-To: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> References: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> Message-ID: <059.c301e5c68f29eca9c50768da869b7ae9@haskell.org> #12602: Add NUMA support to Windows -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11054 | Differential Rev(s): Phab:D2534 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:52:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:52:23 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.740323cd8aee1df6f0685c1d167beb54@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #12602 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 15:52:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 15:52:57 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.f6225277582a8babf46320bef46d4737@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Phab:D2534 adds NUMA support for Windows. Again I don't have a system to test this on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 16:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 16:16:20 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.88f46749b12a10d871942135ec6e23e0@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ok, If I'm reading this correctly, GCC can already emit stack checks. https://gcc.gnu.org/onlinedocs/gnat_ugn/Stack-Overflow-Checking.html So isn't adding `-fstack-check` enough? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 18:07:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 18:07:42 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.7aec4b7829c9cbb89a17a5e52b934f1e@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Right, so using `-fstack-check` seems to emit calls to `___chkstk_ms` before stack alignments. {{{ 633de0: 48 83 e0 f0 and $0xfffffffffffffff0,%rax 633de4: e8 07 0c 0d 00 callq 7049f0 <___chkstk_ms> 633de9: 48 29 c4 sub %rax,%rsp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 18:10:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 18:10:04 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code Message-ID: <046.944cd4788eed55470361e7f38358ac43@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mikolaj reported that he was seeing significantly different code generated in the case of a manual `INLINE` versus manually inlining. I haven't looked into what the cause it and this isn't necessarily problematic; this is just a reminder to look into what is happening. See https://github.com/LambdaHack/LambdaHack/blob/97724fe8c73e80b329ddf326a8eb001020870b2d/Game/LambdaHack/Common/Color.hs#L99. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 18:13:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 18:13: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.2207590d2f5b8ba348af10230534b4ff@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 18:49:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 18:49:37 -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.a10aa26b4d110dfad0aecd5f69aeab72@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -2,1 +2,1 @@ - in the case of a manual `INLINE` versus manually inlining. I haven't + in the case of an `INLINE` pragma versus manually inlining. I haven't New description: Mikolaj reported that he was seeing significantly different code generated in the case of an `INLINE` pragma versus manually inlining. I haven't looked into what the cause it and this isn't necessarily problematic; this is just a reminder to look into what is happening. See https://github.com/LambdaHack/LambdaHack/blob/97724fe8c73e80b329ddf326a8eb001020870b2d/Game/LambdaHack/Common/Color.hs#L99. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 18:58:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 18:58:21 -0000 Subject: [GHC] #10167: Error with dash character In-Reply-To: <045.7058519873a76f56757172245184b3a3@haskell.org> References: <045.7058519873a76f56757172245184b3a3@haskell.org> Message-ID: <060.b42fd3fc1f4898c2e1f95553ca4c2698@haskell.org> #10167: Error with dash character -------------------------------------+------------------------------------- Reporter: elvinz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #6037 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Doesn't seem to happen on `8.0.1` so I'm closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 21:50:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 21:50:49 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.d0a07664621c1340abcfd13de9245edd@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Phab:D2535 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * differential: => Phab:D2535 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 21:51:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 21:51:22 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.cf66eb674b851bfe45f9e7c2350caea2@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Phab:D2535 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 17 22:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Sep 2016 22:51:42 -0000 Subject: [GHC] #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb In-Reply-To: <045.b9ace2f66b6a60a932a378c060eb5914@haskell.org> References: <045.b9ace2f66b6a60a932a378c060eb5914@haskell.org> Message-ID: <060.4ee550eec058e3d5db9146d61a97cead@haskell.org> #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb ---------------------------------+---------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11627 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): I don't get a segfault, I get: {{{ $ cat T11627b.comp.stderr [1 of 1] Compiling Main ( T11627b.hs, T11627b.o ) T11627b.hs:1:1: error: Failed to load interface for ‘Prelude’ Perhaps you haven't installed the profiling libraries for package ‘base-4.9.0.0’? Use -v to see a list of the files searched for. T11627b.hs:9:1: error: Failed to load interface for ‘GHC.Types’ Perhaps you haven't installed the profiling libraries for package ‘ghc-prim-0.5.0.0’? Use -v to see a list of the files searched for. T11627b.hs:10:1: error: Failed to load interface for ‘System.Mem’ Perhaps you haven't installed the profiling libraries for package ‘base-4.9.0.0’? Use -v to see a list of the files searched for. }}} on a normal devel2 build. Do I need a different kind for prof? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 00:04:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 00:04:54 -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.ff0907b33922c91d83544e1edd68c0e8@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Now on the branch https://github.com/LambdaHack/LambdaHack/tree/ghc- bug-12603 the manually inlined code is 3 times faster than the code with INLINE. I tried creating a small example by starting just with the offending module and Main.hs with a loop, but it's not enough, so I gave up for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 01:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 01:00:14 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.b73700fa146e61b15afe29cdef082e3f@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I took a look and it looks like `haddock`'s `ppClassDecl` gets: {{{ Enum MinimalSig ClassOpSig [succ] ClassOpSig [pred] ClassOpSig [toEnum] ClassOpSig [fromEnum] ClassOpSig [enumFrom] ClassOpSig [enumFromThen] ClassOpSig [enumFromTo] ClassOpSig [enumFromThenTo] }}} for `Enum`, but {{{ Eq MinimalSig TypeSig [==] TypeSig [/=] }}} for `Eq`. So we either want to: 1. handle `TypeSig` in `haddock`, or 2. always return `ClassOpSig` for typeclass methods I believe 2. is preferable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 08:26:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 08:26:26 -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.620cb0dc91ae6b5fb12927714fa8b45d@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: mikolaj.konarski@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 08:26:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 08:26:56 -0000 Subject: [GHC] #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine In-Reply-To: <054.1a3de7e547d9846e701648e955069452@haskell.org> References: <054.1a3de7e547d9846e701648e955069452@haskell.org> Message-ID: <069.1ad848719a6ac9164247277b39b4f5c3@haskell.org> #9421: Problems and workarounds when installing and using a 32bit GHC on 64bit Linux machine -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: | MikolajKonarski Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: 9614 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: mikolaj.konarski@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 08:27:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 08:27:20 -0000 Subject: [GHC] #7430: GHC API reports CPP errors in confusing ways In-Reply-To: <054.b42c4bcfb151eb512103f6c292b13b85@haskell.org> References: <054.b42c4bcfb151eb512103f6c292b13b85@haskell.org> Message-ID: <069.b6d6f47b6e24cc33772d2700ff6a7ca4@haskell.org> #7430: GHC API reports CPP errors in confusing ways -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: mikolaj.konarski@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 08:27:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 08:27:35 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.5619b733c9e071405a6529ef5e9f9a19@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: mikolaj.konarski@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 10:03:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 10:03:01 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.aca5cdc428fa860c767a63a606e85db2@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I have access to 44 physical cores (2 processor) system and I'll test it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 10:05:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 10:05:22 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.78f00680f1de640b51a578c535737d69@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Are those changes introduced in GHC 8.0.1 or I have to use some nightly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 10:19:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 10:19:10 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.de47a537f6fdde97d2a7845966fe649f@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ah, it's currently not merged yet. But I will produce two builds for you. They'll be built in debug mode so logs can be generated if needed. But I won't be able to before tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 13:57:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 13:57:32 -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.759715a4d21a225d7ec84e1c3b3b40e2@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is indeed very odd. I'd love to see a test case. Thanks! -- I know it's real work to create one Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 14:44:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 14:44:47 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.fe35e68d5a2bf8043326310390a0eef3@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): We did some investigation last night in IRC and came to the conclusion that the runtime loader in Sierra has a new limit on the `sizeofcmds` field which is the total size of all the load commands in the dynamic library. Looking at the `otool -l` output in an earlier attachment, we can see that the main contributors to the size are primarily the RPATH entries and to a lesser extent the LOAD_DYLIB entries. There are over 100 of each, and the paths in the RPATH entries are quite long (I guess this is why stack is affected in particular). So, I don't expect that disabling split objects will help at all, unfortunately. There seems to just be a limit on the total size of RPATH entries we can use. In fact Cabal is the one choosing these RPATHs, not GHC itself. So this will require some kind of change to Cabal to decrease the total size of the RPATH entries it produces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 15:09:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 15:09:10 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.6bf0f178172ff6c2224518f7a6702286@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- 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): Hmm. In HEAD (and therefore I think 8.0 but I'm not certain) an out-of- scope variable is an error, so we get {{{ T12589.hs:11:14: error: Variable not in scope: (&) :: t0 -> t1 -> t }}} regardless of `-fefer-typed-holes`. If I change it to be {{{ a = _foo minBound (hcpure (Proxy @Bounded)) }}} using a named wildcard, with `-defer-typed-holes` in HEAD I get {{{ s:12:5: warning: [-Wtyped-holes] * Found hole: _foo :: t0 -> t1 -> t Where: `t0' is an ambiguous type variable `t1' is an ambiguous type variable `t' is a rigid type variable bound by the inferred type of a :: t at T12589.hs:12:1-43 Or perhaps `_foo' is mis-spelled, or not in scope * In the expression: _foo In the expression: _foo minBound (hcpure (Proxy @Bounded)) In an equation for `a': a = _foo minBound (hcpure (Proxy @Bounded)) * Relevant bindings include a :: t (bound at T12589.hs:12:1) T12589.hs:12:20: warning: [-Wdeferred-type-errors] * Cannot instantiate unification variable `t1' with a type involving foralls: (forall a. Bounded a => f0 a) -> h0 f0 xs0 GHC doesn't yet support impredicative polymorphism * In the second argument of `_foo', namely `(hcpure (Proxy @Bounded))' In the expression: _foo minBound (hcpure (Proxy @Bounded)) In an equation for `a': a = _foo minBound (hcpure (Proxy @Bounded)) }}} which is what I'd expect. I have not investigated the "falling ito a hole" error becuase it just doesn't happen in HEAD. So could someone test with 8.0.1? If it's ok there then let's just add a regression test and declare it fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 15:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 15:55:43 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.b5d40014a4f42b9b13227bea68471863@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Actually GHC also sets RPATHs on the temporary dynamic libraries it builds (see `linkDynLib`), which is the instance in this ticket. So both GHC and Cabal will need some kind of workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 16:29:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 16:29:56 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.d1633e1595c45d2b4abaedcb1dd56abd@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 20:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 20:08:26 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.38143a8573acbc519a3cabc536d39b0c@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.2 Comment: As described in #12019 `-hb` is not thread-safe. As of 6555c6bb8447ed65d5da4bab462ee9da7dc3f97a the RTS will fail with a proper error message when it is used with more than one capability, so I think this can be safely closed. #12019. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 20:16:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 20:16:21 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.868b8dad2cb351d2d88f189e9382fe0f@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: erikd => * status: closed => new * resolution: fixed => * milestone: 8.0.2 => Comment: Reopening since this is still an issue; we just happen to fail more gracefully now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 21:25:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 21:25:59 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.42b3fa292c1b960aa8a897e345e73c8b@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @varosi I've uploaded a build which contains both the NUMA code and processer group supports here https://1drv.ms/u/s!AuQz_u- 9HaJPmZJodxEWgq4OJ4KDkQ for processor groups you don't need to do anything aside from passing `-N` to the rts. and to test NUMA support pass `--numa`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 21:31:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 21:31:29 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.e3f69ac2c3a2ae90b4a5b71d585ac96c@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): The fix on the 8.0 branch broke the build on my Mac. Reverting it for now for my local build. But surely it's impacted other folks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 22:44:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 22:44:29 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.b5bf99f66953ae5b1dc89d0d42fb0a40@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 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): Note that https://ghc.haskell.org/trac/ghc/ticket/11660 will merge the two pretty-printers so it is best to fix this (if still necessary) after that patch has been applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 22:50:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 22:50:13 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.d5da0ee564135a11b6e4a6aa845205cc@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2528 Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * cc: johnleo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 22:50:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 22:50:29 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.2d157e85c52db3fae069d5b480cf0d1a@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by carter): * status: closed => new * resolution: fixed => Comment: This commit breaks builds on OS X 10.11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 18 22:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Sep 2016 22:59:08 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.48828afad6e77ac3a0260cd08a4e61b6@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2528 Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Recognizing that this is a work in progress, if possible it would be nice to address some of the unicode issues noted in https://ghc.haskell.org/trac/ghc/ticket/12550 as part of this change. I'm happy to fix any remaining issues but will hold off until the patch is merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 00:47:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 00:47:28 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.bd17d7147d947b025322e8ae84e9eddf@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * Attachment "rep.hs" added. Test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 00:49:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 00:49:31 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.750b909cf02ad2c189759f2b494146ec@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Here is a test case that does not require criterion. With `ghc-8.0.1 -O2 -ddump-simpl`, you can see that `foo` is compiled into code that uses a top-level CAF containing `GHC.Enum.eftInt 0# 799#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 01:20:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 01:20:29 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.cc37f9dc908260a1d2e00808221d1b71@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): {{{ rts/ProfHeap.c: In function 'initHeapProfiling': rts/ProfHeap.c:389:49: error: error: 'PAR_FLAGS {aka struct _PAR_FLAGS}' has no member named 'nCapabilities' if (doingLDVProfiling() && RtsFlags.ParFlags.nCapabilities > 1) { ^ }}} I think the patch / CPP somehow doesn't quite work on the build ways matrix of the RTS in the expected way, i'll try to poke at it myself if i have time, but it def died -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 02:37:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 02:37:33 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.bff5fd1e0eb82c313c8389723f3f04ea@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -6,1 +6,1 @@ - {{{ + {{{#!hs @@ -16,3 +16,3 @@ - where - go !n | n == bex = return () - | otherwise = f n >> go (n+1) + where + go !n | n == bex = return () + | otherwise = f n >> go (n+1) New description: Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{#!hs -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 04:40:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 04:40:40 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.b7a0f07f7b90d0f6d3803b3ddf7fb36b@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): It looks like this is the same issue as described in #7206. The branch mentioned in https://ghc.haskell.org/trac/ghc/ticket/7206/#comment:13 fixes my test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 12:08:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 12:08:36 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.eb7736c04ce21a24208087d2d301b15e@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good to know that's it. The program in rep.hs is rather unusual because it has a ''constant'' list, not dependent on input data. Real programs usually depend on input data. So this probem may be less of a probem in practice than in benchmarks. It would be great if someone felt able to dig into #7206 and figure out why it's not a straight win Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 15:58:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 15:58:34 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.2a3b668b29a9201ae7a771a7ae5396b3@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Another Stackage Nightly build with ghc 8.0.1 patched with Phab:D2495 and Phab:D2525: {{{ ghc: internal error: MUT_VAR_CLEAN object entered! (GHC version 8.0.1 for powerpc64le_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This error seems to be even more difficult to trigger on Open Build Service. I have not seen this locally on my PowerMac (running powerpc64 Linux). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 16:12:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 16:12:28 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.1cf29360a0a4df11febcd68fb04fed63@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:30 simonpj]: > Real programs usually depend on input data. So this probem may be less of a probem in practice than in benchmarks. Just wanted to chime in that I found this problem in a real-world program, where I looped over all 32-bit integers. Similarly, these known-at- compile-time iteration lists may appear in inner loops of algorithms or data structures (like B-trees with fixed B, or image convolution kernels with fixed size, e.g. 3x3 image templates). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 17:31:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 17:31:23 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.abea0097b3571dcb7744e10dcb1997e8@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @varosi, could you hold of on testing the binary. I have just realized while re-reading the documents on the subject that processor groups aren't uniformly distributed. And this patch assumes they are and that they are all the entire group is filled before another is needed. Seems Intel had the same issue, I'll respin the patch this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 19:09:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 19:09:31 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.709a92a19ba185c1d1500aebd0dbe219@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Okay, no problem! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 23:07:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 23:07:40 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.1268ca8a983c66b97bf562ccf53e197d@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Build System | 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): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: => 8.0.2 Comment: These need to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 19 23:58:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Sep 2016 23:58:49 -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.162ecdcb1d80236a6b8834c1a7f63351@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I have a patch. It doesn't solve the problem completely, but it solves the problem in `loadArchive()`. Failures in that function now cause an error return and a message to be written via `errorBelch()`. This isn't great, but it is better than the current situation. Currently running `./validate --slow` to test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 04:13:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 04:13:33 -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.7bee1cf7c83dd70cb733653d3fcc9db2@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 maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 04:15:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 04:15:36 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.1ad3e1e810f177b728ad7b8106d1871a@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 maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 07:30:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 07:30:08 -0000 Subject: [GHC] #8457: -ffull-laziness does more harm than good In-Reply-To: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> References: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> Message-ID: <059.331044431de7af268957be42ddb71552@haskell.org> #8457: -ffull-laziness does more harm than good -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 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 edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 07:30:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 07:30:30 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.1fd4a90eb61d09e7550724815851e27d@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * related: => 8457 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 07:31:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 07:31:04 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.09f81711400bba664d6cba4eacd5f60d@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * related: 8457 => #8457 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 11:17:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 11:17:26 -0000 Subject: [GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables. In-Reply-To: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> References: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> Message-ID: <062.1bfe9085fa983629c5fbb1bec6ae18c0@haskell.org> #12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | DefaultSignatures, TypeApplications Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | generics/T12220 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.0.2 Comment: It ended up being not so bad to merge afterall. Merged to `ghc-8.0` as 54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 11:18:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 11:18:14 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.4d1018243237f1d6d64e4dcc7a9c94e9@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 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/T12466, | T12466a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.0.2 Comment: comment:37 merged to `ghc-8.0` as 0e4e03a2a810ffa8ae16815d2ce4aad11d4b1065. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 11:19:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 11:19:07 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.4bb56841e9285c3aa1afe302103c8189@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rename/should_compile/T12533 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: We managed to sort out the issues described in comment:6. comment:3 merged to `ghc-8.0` as 0e4e03a2a810ffa8ae16815d2ce4aad11d4b1065. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 13:02:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 13:02:27 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.8d7e0f16b1baf71a308155c92c74410b@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): To give an update on this: * Haddock gets the right data from GHC (at least the first time) * The data appears to get mangled only when Haddock saves it to an interface file and then reads it in a different invocation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 14:39:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 14:39:31 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.868d153c5a93ff8c89657797b52ca1ed@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Ok, I know what happened here, but my poor internet connection prevents me from committing. https://github.com/haskell/haddock/commit/3fd2ed3213778c090ed5e27bd8a9e5bdee5c5135 fixed Haddock after `wildcard-refactor`, but missed a (non-obvious) spot. The relevant part is in `ppClassDecl` where `TypeSig` was changed to `ClassOpSig` to accommodate GHC changes. And it works when Haddock uses GHC API to get type information. Unfortunately there's another way Haddock can get the information and that's using an interface file. There's some logic in `Haddock/Convert.hs` to deal with that, the relevant function is `tyThingToLHsDecl`. That's where Haddock will choose to use `TypeSig` for a type signature of a typeclass method. Here is a patch that fixes this: {{{ diff --git a/haddock-api/src/Haddock/Convert.hs b/haddock- api/src/Haddock/Convert.hs index 88cedc7..41e98c6 100644 --- a/haddock-api/src/Haddock/Convert.hs +++ b/haddock-api/src/Haddock/Convert.hs @@ -81,7 +81,7 @@ tyThingToLHsDecl t = case t of (map (noLoc . getName) l, map (noLoc . getName) r) ) $ snd $ classTvsFds cl , tcdSigs = noLoc (MinimalSig mempty . noLoc . fmap noLoc $ classMinimalDef cl) : - map (noLoc . synifyIdSig DeleteTopLevelQuantification) + map (noLoc . synifyTcIdSig DeleteTopLevelQuantification) (classMethods cl) , tcdMeths = emptyBag --ignore default method definitions, they don't affect signature -- class associated-types are a subset of TyCon: @@ -316,6 +316,8 @@ synifyName = noLoc . getName synifyIdSig :: SynifyTypeState -> Id -> Sig Name synifyIdSig s i = TypeSig [synifyName i] (synifySigWcType s (varType i)) +synifyTcIdSig :: SynifyTypeState -> Id -> Sig Name +synifyTcIdSig s i = ClassOpSig False [synifyName i] (synifySigType s (varType i)) synifyCtx :: [PredType] -> LHsContext Name synifyCtx = noLoc . map (synifyType WithinType) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 15:16:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 15:16:41 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit (was: ghc-openGL build Segmentation Fault for openSUSE ppc64le) In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.4964ab50f4a6c8c0d71c6109c83531b2@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I could reproduce the segmentation fault on a powerpc64 big-endian Linux machine and I can also reproduce it with other packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 15:48:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 15:48:28 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.22a2031f5ead851728b694c743157e52@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => Comment: Hmm, and in another package: {{{ ghc: internal error: ARR_WORDS object entered! (GHC version 8.0.1 for powerpc64le_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It looks like quite a few more memory barriers are missing. I don't have enough time right now to work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 16:41:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 16:41:49 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.6eeb7cbcc4d58b0b99216e50d5a442c3@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jonathan): Just for reference, I built GHC with `split-sections` disabled with no luck as previously expected. As @rwbarton mentioned, this occurs when there are a large number of dependencies which overflow past the RPATH limits (building Stack itself is a good test). Has a ticket been created for Cabal yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 18:50:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 18:50:53 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.a4259ab6218962e673ce5d6341a0307d@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"6886bba8ea2965177c00edceb98509b48957b515/ghc" 6886bba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6886bba8ea2965177c00edceb98509b48957b515" Bump Haddock submodule to fix rendering of class methods Fixes #12519 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 18:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 18:53:12 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.52b61b6e8592c6b8f5596ae3435ca048@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer 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 mpickering): * status: new => merge Comment: The patch works as advertised. Thanks Bartosz! I merged this into the `ghc-head` branch and updated the submodule on the GHC master branch. Ben, I think that just leaves cherry-picking the appropriate commits onto the 8.0 branch(s). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 19:17:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 19:17:29 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.1b0325bb08ade1443453d4ed8e23bbee@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The OS X linker has an option '''-dylib_file''' ''install_name:file_name'' Specifies that a dynamic shared library is in a different location than its standard location. Use this option when you link with a library that is dependent on a dynamic library, and the dynamic library is in a location other than its default location. ''install_name'' specifies the path where the library normally resides. ''file_name'' specifies the path of the library you want to use instead. For example, if you link to a library that depends upon the dynamic library libsys and you have libsys installed in a nondefault location, you would use this option: '''-dylib_file /lib/libsys_s.A.dylib:/me/lib/libsys_s.A.dylib'''. So GHC could do something like this. When it needs to link a temporary shared library against a Haskell package, rather than using `-Ll -Wl,-rpath -Wl,l` to add the package's library directory `l` to the rpath, since `l` typically has a form like `/home/rwbarton/.cabal/lib/x86_64 -linux-ghc-7.8.4/text-1.1.1.3`, instead add the parent directory of `l` to the rpath and use `-dylib_file` to link against the library with an install name of `@rpath/text-1.1.1.3/libHStext-1.1.1.3-ghc7.8.4.dylib`. Since the parent directories of the package libraries will generally be mostly the same (like `/home/rwbarton/.cabal/lib/x86_64-linux-ghc-7.8.4`), they can be deduplicated to save most of the size of the load commands. This is kind of a hack that relies on the directory structure that Cabal produces to be effective, but it has the advantage of being a local change. Cabal would also need some similar change in order for the final libraries that it links to be loadable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 19:56:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 19:56:39 -0000 Subject: [GHC] #12604: panic when building repa-fftw Message-ID: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry, if I reported it wrongly. It is my first bug. -- While building package repa-fftw-3.2.3.2 using: /home/kosh/.stack/setup-exe-cache/x86_64-linux-nix/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux- nix/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/kosh/haskell/spRepa/.stack-work/logs /repa-fftw-3.2.3.2.log Configuring repa-fftw-3.2.3.2... Building repa-fftw-3.2.3.2... Preprocessing library repa-fftw-3.2.3.2... [1 of 1] Compiling Data.Array.Repa.FFTW ( Data/Array/Repa/FFTW.hs, .stack-work/dist/x86_64-linux- nix/Cabal-1.24.0.0/build/Data/Array/Repa/FFTW.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): filterImports/combine (Array, Array{Array, AByteString, ACursored, ADelayed, AForeignPtr, AInterleave, ASmall, APart, AUnboxed, AUndefined, AVector, cursoredExtent, loadCursor, makeCursor, shiftCursor}, Nothing) (Array, Source{Source, Array, deepSeqArray, extent, index, linearIndex, unsafeIndex, unsafeLinearIndex}, Nothing) 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 Tue Sep 20 19:57:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 19:57:07 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.ad224289b5c1588d2308e85a3a8893c7@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by koshmar): * Attachment "spRepa.cabal" added. cabal file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 19:57:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 19:57:26 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.e3bb44d8329dc364f984f97bd4d838cb@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by koshmar): * Attachment "stack.yaml" added. stack file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 20:07:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 20:07:06 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.375e15a13d3ab92715645af447d5c02f@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by koshmar): * failure: Building GHC failed => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 20:18:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 20:18:38 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.97b827b328b1a26be83dd08710f5123f@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Seems likely to be #11959 without looking at the example at all. Does that look sensible to you? Also, reproduction instructions which use stack are not useful as it is not easy to use a custom build of GHC with stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 20:30:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 20:30:12 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.09ef5568defe0fdb0d4ef917af1f7112@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by koshmar): Not really. I am very new to haskell. If you will advice me what to do, I would like to do it. I can attach my source code, which is like 50 lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 20:30:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 20:30:52 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.aa881913e28d161cd8c083f3963cd6db@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by koshmar): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 20:38:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 20:38:19 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.7d3245a438a31ed9d47abd2743082d7f@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Comment (by simonpj): See also #12604 which is almost certainly a dup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 20:45:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 20:45:28 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.e4f1f52c175cec58ee9e3623ab156ce4@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm looking a bit more closely. Sorry for the red herring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 21:02:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 21:02:23 -0000 Subject: [GHC] #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` Message-ID: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` -------------------------------------+------------------------------------- Reporter: jberryman | 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.1.20160920: http://www.haskell.org/ghc/ :? for help Prelude> let (#) = (+) Prelude> :set -XUnboxedSums Prelude> let (#) = (+) :3:7: error: parse error on input ‘)’ }}} I first noticed this in an import statement: {{{ import Data.Functor.Utils (Max(..), Min(..), (#.)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 21:04:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 21:04:56 -0000 Subject: [GHC] #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` In-Reply-To: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> References: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> Message-ID: <063.704bb08d54dd5966cf8c47bab4784144@haskell.org> #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` -------------------------------------+------------------------------------- Reporter: jberryman | 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 rwbarton): Well, `UnboxedTuples` does the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 21:47:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 21:47:40 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.ac291b8802807b178dbe0dc1379e41a9@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is a minimal reproduction. It is two files. 1. `M.hs` {{{ {-# LANGUAGE TypeFamilies #-} module M ( -- * Abstract array representation Array (..) , Source(..) ) where class Source r where data Array r data C instance Source C where data Array C = ACursored { cursoredExtent :: Int } }}} 2. `Test.hs` {{{ module Test where import M (Array) }}} Reproduce with `ghc Test.hs`. Error being {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): filterImports/combine (Array, Array{Array, ACursored, cursoredExtent}, Nothing) (Array, Source{Source, Array}, Nothing) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Thanks for the report koshmar! Hopefully Simon will know a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 21:57:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 21:57:35 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.06bb1f4f88c5a14f41309d8e658f888e@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf 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 jberryman): Does this have much to do with overloaded labels? As rwbarton points out, it seems any occurence of "(#" has issues: {{{ ubuntu at ip-172-31-8-51:~/work/ghc-my$ ghci GHCi, version 8.1.20160920: http://www.haskell.org/ghc/ :? for help Prelude> :set -XUnboxedTuples Prelude> let (#) = (+) :2:7: error: parse error on input ‘)’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 22:01:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 22:01:05 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.d0d647f56fa05d32fd07591e36f96bd8@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by erikd): @trommler, how are you triggering these errors? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 22:04:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 22:04:48 -0000 Subject: [GHC] #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` In-Reply-To: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> References: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> Message-ID: <063.86d3f11401e26145128b8a29d0c06282@haskell.org> #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` -------------------------------------+------------------------------------- Reporter: jberryman | 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 jberryman): Oh I see you're right, and maybe this is a dup of https://ghc.haskell.org/trac/ghc/ticket/12459 However even if that's expected under `UnboxedTuples`, this seems to be a worse situation under `UnboxedSums`. I'm looking at https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes under "Unpacking ... This part is not yet implemented..." it seems to me the intention is to allow `UnboxedSums` to automatically optimize (has this been implemented in HEAD yet btw?): {{{ data T1 a = Some a | None data T2 a = C {-# UNPACK #-} !(T1 a) }}} So a user might like to enable on a source tree for purposes of optimization; they don't need or want access to any new syntax. Let me know if I should open any new tickets. Feel free to do whatever you think with this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 22:12:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 22:12:23 -0000 Subject: [GHC] #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` In-Reply-To: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> References: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> Message-ID: <063.a088f873ebca4086455d19174da770dd@haskell.org> #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` -------------------------------------+------------------------------------- Reporter: jberryman | 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 jberryman): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 22:40:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 22:40:24 -0000 Subject: [GHC] #12606: Linux (ELF) Support for "ghc -static -shared" Message-ID: <046.d447037062698bef3ad5e600ea6fd991@haskell.org> #12606: Linux (ELF) Support for "ghc -static -shared" ----------------------------------------+--------------------------------- Reporter: tmobile | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On some platforms it is possible to create a stand-alone shared library out of some object `Foo.o` including foreign exports with something like: `ghc -static -shared Foo.o ...` The resulting library will have `Foo`'s dependencies including `base` as well as the RTS statically linked in. On BSDs this is possible because generating position independent code is the default there, and on Windows this is possible because the dynamic loader uses some magic that doesn't require position independent code. Unfortunately on Linux this is not possible because `libHSbase`, `libHSrts`, etc. are not built with `-fPIC` unless one specifically asks for it when building GHC. As far as I know this is the only way to get `-static -shared` to work on this platform. There are use cases for compiling Haskell code into a single shared object that does not have additional runtime dependencies. Suppose one wishes to write a plugin for a program in Haskell. It would be nice to provide the plugin as a single shared object, rather than requiring GHC's libraries to be present at runtime as well. An easy solution might be adding a switch to the configure script or `build.mk` to make it easier to build GHC+libs with `-fPIC` on Linux. Ideally it would be possible to build and install both PIC and non-PIC libraries and have GHC choose the correct one at link time based on the flags and target platform, since PIC code carries a small space/performance overhead and isn't necessary on Linux in most cases. I don't know my way around GHC(outside of the GHC API) or the build system that well yet, but if adding extra build system flags and GHC link-time flag handling code to make this work is an acceptable solution I'm happy to spend the time to get this working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 23:15:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 23:15:58 -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.3981c5fd39d12f6aba8498c6d05031f0@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): I had a good conversation with Richard and Stepanie about this ticket. Our conclusions. * Alex's cunning examples demonstrate that it's very difficult (perhaps impossible) to come up with a dependency analysis that always does the Right Thing. Even if it's possible we should not do it because (a) it'd be hard to implement and (b) it'd be extremely hard to explain exactly which programs should be OK. * Bottom line. Instead of getting in deeper, pull back. Do somthing that is simple to explain, predicatable, and simple to implement, even if it' a little less convenient. * Richard's long remarks in comment:15 actually relate to somethiug rather different called (I think) "induction recursion". It is cool but it should have a separate ticket. Richard can you do that? '''Proposal''' Get the programmer to do "phasing" explicitly if it is necessary. Specifically * Introduce a top-level '''binding separator''', thus {{{ f x = x + 1 ============ g x = f x }}} The `==========` is the binding separator. * Concrete syntax to be decided. But we have this very thing already, thus {{{ f x = x+1 $([d| |]) -- Empty Template Haskell top level splice g x = f x }}} New concrete syntax is just to make it less wierd. * Semantics. Everything before the separator is renamed and typechecked before anything after. * When typechecking data/class/instance decls, we revert to something close to the situation before Alex's patch: 1. `class`, `type`, `data`, and `data instance` declarations are SCCd and typechecked in order 2. When that is complete typecheck class `instance` and `type instance` declarations. Note that `data instance` decls come in the first wave (addressing the example in the Description), but the slippery `type instance` declarations happen only afterwards * I think we could perhaps include ''closed'' type families in step (1); c.f. comment:12. Not certain. In Alex's example in comment:8 the `type instance F` would happen last, which would fail (consistently so). To fix it, use a separator: {{{ module B where import Data.Kind import A data Q data family F (t :: Type) :: Closed t -> Type type instance Open Q = Bool ============ -- The separator ensures that data instance F Q r is -- typechecked after the type instance Open Q data instance F Q r where F0 :: F Q 'True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 20 23:38:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Sep 2016 23:38:48 -0000 Subject: [GHC] #12604: panic when building repa-fftw In-Reply-To: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> References: <046.c22c43ea7876680f259086dbb82c8f2a@haskell.org> Message-ID: <061.cdf5c8220e2ae30d9ea33b7a9479bee7@haskell.org> #12604: panic when building repa-fftw -------------------------------------+------------------------------------- Reporter: koshmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thanks. This is actually a dup of #12127, which is fixed and merged, so it'll be in the 8.0.2 release. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 01:01:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 01:01:06 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.c7a9d0ba6c842694a051cb62ca4be264@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | Phab:D2537 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2478 => Phab:D2478 Phab:D2537 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 01:01:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 01:01:45 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.08bd39f885779097234cf6615277c61f@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths ----------------------------+--------------------------------------------- Reporter: rcook | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T12504 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Phab:D2537 Wiki Page: | ----------------------------+--------------------------------------------- Changes (by Phyx-): * testcase: /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc => T12504 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 07:40:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 07:40:52 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.8565f040db16b47cbcf408df7920adc7@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths ----------------------------+--------------------------------------------- Reporter: rcook | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T12504 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Phab:D2537 Wiki Page: | ----------------------------+--------------------------------------------- Comment (by Tamar Christina ): In [changeset:"8bd3d417e67e5e938dd5bfc640c3efbb683ee309/ghc" 8bd3d417/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8bd3d417e67e5e938dd5bfc640c3efbb683ee309" Fix failing test T12504 Summary: Test T12504 does it's checking in the Makefile using grep but still specified an stdout. the stdout has the old output and would always fail. Since the stdout isn't needed, let's not check it. Test Plan: make test TEST=T12504 Reviewers: bgamari, austin, erikd, rcook Reviewed By: rcook Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2537 GHC Trac Issues: #12504 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 08:15:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 08:15:59 -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.055b32befb9d5ee0c1b2c324c5d18c91@haskell.org> #12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: MADV_FREE 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 trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 08:33:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 08:33:04 -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.48242a41147941a5dcdc5ca9feef0d90@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by int-index): What about the example in comment:19? Adding binding separators didn't fix the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 12:22:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 12:22:06 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.6f3a1265b8b7297d5b069deaff9edb2c@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:20 erikd]: > @trommler, how are you triggering these errors? Unfortunately, I cannot directly observe these errors. I see them on Open(SUSE) Build Service where a build runs inside a qemu VM on a POWER8. The issue is very rare, 1700 packages build just fine and around 30 to 50 fail. Most of the failures are in `Setup`, which we compile for each package, and very few (less than 3) fail with a panic. Rebuilding the package works with high probability. On my PowerMac quad core I see a segfault in `./Setup build -v -j4` which is what is reported in #12537. In that ticket a compiler panic in `mkFastStringWith` is reported but I have not been able to provoke a panic on my machine. Is it worth trying some more runs and hope to observe a panic to rule out that qemu is doing something odd? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 13:15:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 13:15:05 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.44c7c42c9cba6b021b17bc8175f4f78a@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Perhaps this would be a good excuse to address #11587. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 13:39:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 13:39:28 -0000 Subject: [GHC] #12607: Memory effects in doomed STM transactions Message-ID: <048.8420da21b30e1acff617432d38e2d2e2@haskell.org> #12607: Memory effects in doomed STM transactions -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: STM, allocate | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Problem == GHC's STM implementation does "lazy" validation meaning that speculative execution can continue even after observing an inconsistent view of memory. Transactions in the state are called "doomed transactions". While the runtime tries to avoids some effects in doomed transactions, such as entering an infinite loop, it does not successfully control all memory effects. In particular there are many (I do not have an exhaustive list) allocations that eventually end up in the `allocate` function which is nicely documented with the following: > `allocate()` never > fails; if it returns, the returned value is a valid address. If > the nursery is already full, then another block is allocated from > the global block pool. If we need to get memory from the OS and > that operation fails, then the whole process will be killed. https://github.com/ghc/ghc/blob/master/rts/sm/Storage.c#L819 A doomed transaction that demands a large allocation that the OS cannot fulfill will kill the process. Here is a program that reliably fails for me: {{{#!hs -- oom.hs {-# LANGUAGE BangPatterns #-} import GHC.Conc import Control.Concurrent import qualified Data.ByteString as B forever act = act >> forever act check True = return () check False = retry main = do tx <- newTVarIO 0 ty <- newTVarIO 1 tz <- newTVarIO 0 done <- newTVarIO False _ <- forkIO $ forever $ atomically $ do -- Only read tx and ty x <- readTVar tx y <- readTVar ty if x > y -- This should always be False then do -- We only get here in a doomed transaction. Commenting out the next two lines -- but leaving the write to done and the program runs as expected because the -- doomed transaction is detected at commit time. let !big = B.length $ B.replicate maxBound 0 -- The big allocation! writeTVar tz big writeTVar done True else return () let mut = forever $ atomically $ do y <- readTVar ty x <- readTVar tx if x > 1000 then do -- When we get big enough, start over. writeTVar tx 0 writeTVar ty 1 -- Always holds semantically that tx < ty else do -- increment x and y both writeTVar ty (succ y) writeTVar tx (succ x) -- tx < ty -- Give lots of opportunities to witness inconsistent memory. _ <- forkIO mut _ <- forkIO mut _ <- forkIO mut atomically $ readTVar done >>= check putStrLn "Done" }}} Running leads to out of memory: {{{#!bash > ghc oom.hs -fno-omit-yields -threaded [1 of 1] Compiling Main ( oom.hs, oom.o ) Linking oom.exe ... > ./oom.exe +RTS -N oom.exe: out of memory }}} == Fixing == When a potentially bad memory effect is about to happen in some thread, we need to ensure that we validate any running transaction and if it fails have some way to back out of the operation and abort the transaction. This might be tricky on two fronts 1) finding all the critical allocations and 2) finding places where we can both detect (1) and abort the transaction. The places I'm concerned about most are array allocation such as the `ByteString` in the example and maybe `Integer` allocation. Another fix is a different STM implementation altogether that (at a performance cost or trade-off) doesn't allow doomed transactions (to appear Haskell Symposium 2016 :D). I think we can at least address this particular example without going so far. A related issue is more general memory leaks from doomed transactions. Consider a program with a memoized Fibonacci function. The semantics of the transactions written by the programmer may ensure that no value higher then 10 is ever demanded of that function, yet in a doomed transaction the invariant goes wrong and the program demands 100. The program will detect the doomed transaction eventually in this case, but not before it has allocated a large live blob never to be touched again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 13:59:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 13:59:44 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.43fa2edd24d6c61b92fba898e80b3adb@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | 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 clinton): Oh yes, silly me. As you said, replacing the class with: {{{ f :: TF (x, a) -> () f _ = () }}} also illustrates the bug. This still causes the compiler to loop forever in GHC HEAD 21st September 2016 (8.1.20160921) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 16:30:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 16:30:14 -0000 Subject: [GHC] #12608: Fatal error installing haskell-stack using brew OS X 10.12 Message-ID: <044.4c20e0fb83ff16ad682bb4736d285ab1@haskell.org> #12608: Fatal error installing haskell-stack using brew OS X 10.12 ----------------------------------------+--------------------------------- Reporter: slayd | 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: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Last 15 lines from /Users/seriley/Library/Logs/Homebrew/haskell- stack/03.cabal: [ 6 of 96] Compiling Paths_stack ( dist/dist-sandbox- 85bb401b/build/autogen/Paths_stack.hs, dist/dist-sandbox- 85bb401b/build/Paths_stack.o ) [ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, dist/dist- sandbox-85bb401b/build/Path/Find.o ) [ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, dist/dist- sandbox-85bb401b/build/Path/Extra.o ) [ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-85bb401b/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/tmp/ghc49548_0/libghc_69.dylib, 5): no suitable image found. Did find: /tmp/ghc49548_0/libghc_69.dylib: malformed mach-o: load commands size (47208) > 32768 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 Sep 21 16:35:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 16:35:39 -0000 Subject: [GHC] #12608: Fatal error installing haskell-stack using brew OS X 10.12 In-Reply-To: <044.4c20e0fb83ff16ad682bb4736d285ab1@haskell.org> References: <044.4c20e0fb83ff16ad682bb4736d285ab1@haskell.org> Message-ID: <059.58ed05813e0293588014b945480f9af6@haskell.org> #12608: Fatal error installing haskell-stack using brew OS X 10.12 ---------------------------------+---------------------------------------- Reporter: slayd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | 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: => duplicate Comment: Thanks for the report. This is a duplicate to #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 16:55:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 16:55:28 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.cf82feb0a6527514be61bbd51a4ff58b@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- 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): * failure: Other => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 16:56:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 16:56:13 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.60966c122bd1448037c0340897d25f76@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- 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: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * failure: GHC rejects valid program => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 19:39:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 19:39:14 -0000 Subject: [GHC] #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` In-Reply-To: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> References: <048.c1c6fb8f03d8e398aaf2bd06a1bc7f07@haskell.org> Message-ID: <063.e1d92a192fc0bbf264812022293a3432@haskell.org> #12605: UnboxedSums causes parse error on hash operator e.g. `let (#) = (+)` -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.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 rwbarton): * status: new => closed * resolution: => invalid Comment: Presumably you won't need to enable any language extensions in order to take advantage of optimizations that use unboxed sums. There are already important optimizations that introduce unboxed tuples, and they don't require a language extension. These language extensions just allow you to write unboxed sums/tuples in the surface syntax. I guess I'll close this ticket since I don't think we should do anything here, though I don't feel too strongly about it. By the way, the workaround for the original issue is to add a space before `#.`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 19:43:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 19:43:50 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.42d8926384d06e439d1c167bae39612b@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Absolutely, but it might be tough to do on short notice; I'm guessing it requires a coordinated change to Cabal, and might break other build systems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 20:12:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 20:12:49 -0000 Subject: [GHC] #11505: Boot file problem In-Reply-To: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> References: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> Message-ID: <062.5726e7f5f0df04dc8d21c018d26c8a41@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): I can repro what looks like a similar issue on HEAD, but I don't have a good test yet. I'm experimenting building GHC with the following build flavour: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O2 -XStrictData -XUnboxedSums -funbox-strict-fields -fexpose-all-unfoldings -flate-dmd-anal -fmax-simplifier-iterations=8 -funfolding-use-threshold=120 -fstatic-argument-transformation -fsimpl- tick-factor=100000 GhcLibHcOpts = -O2 -XUnboxedSums -funbox-strict-fields -flate-dmd- anal -fmax-simplifier-iterations=8 -funfolding-use-threshold=120 -fsimpl- tick-factor=100000 BUILD_PROF_LIBS = NO HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} Where the error pops up building stage2: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-i d ghc-8.1 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -i compiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icom piler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/. /autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id a rray-0.5.1.1 -package-id base-4.9.0.0 -package-id binary-0.8.3.0 -package- id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package- id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.2.0 -package-id template-haskell-2.11.0.0 -package-id time -1.6.0.1 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc- DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timi ng -O2 -XStrictData -XUnboxedSums -funbox-strict-fields -fexpose-all- unfoldings -flate-dmd-anal -fmax-simplifier-iterations=8 -funfolding-use- threshold=120 -fstatic-argument-transformation -fsimpl -tick-factor=100000 -no-user-package-db -rtsopts -Wnoncanonical- monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c comp iler/basicTypes/ConLike.hs -o compiler/stage2/build/ConLike.o -dyno compiler/stage2/build/ConLike.dyn_o compiler/basicTypes/ConLike.hs:50:1: error: Type constructor ‘ConLike’ has conflicting definitions in the module and its hs-boot file Main module: data ConLike = RealDataCon {-# UNPACK #-}DataCon | PatSynCon {-# UNPACK #-}PatSyn Boot file: data ConLike = RealDataCon !DataCon | PatSynCon !PatSyn The constructors do not match: The strictness annotations for ‘RealDataCon’ differ The strictness annotations for ‘PatSynCon’ differ <> compiler/ghc.mk:577: recipe for target 'compiler/stage2/build/ConLike.o' failed make[1]: *** [compiler/stage2/build/ConLike.o] Error 1 }}} Yet I can't repro with the original test case above, even when I pass all the flags I specify in the flavor above: {{{ $ ~/inplace/bin/ghc-stage1 -O2 -XStrictData -XUnboxedSums -funbox-strict- fields -fexpose-all-unfoldings -flate-dmd-anal -fmax-simplifier- iterations=8 -funfolding-use-threshold=120 -fstatic-argument- transformation -fsimpl-tick-factor=100000 -c /tmp/Foo.hs-boot ...and so on for Bar.hs and Foo.hs }}} No error is thrown. I don't understand enough of the way ghc-stage1 is being called in the ghc build's invocation to know where to begin experimenting further with this. Note, you have to put spaces around occurences of `#.` from `Data.Functor.Utils` for UnboxedSums to get the compile to go this far, but otherwise my ghc tree is unmodified from 14c2e8e0c11b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 20:15:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 20:15:29 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.2937d223214ef33c53d0f3dcb04e7684@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by martinceresa): Hi! I've found the error. It seems that when looking for warning messages in DynFlags.hs/wWarningFlagsDeps for 'Opt_WarnMissingLocalSignatures' it finds first the depecrated version message. Swapping those two lines, getting something like this: {{{#!hs wWarningFlagsDeps :: [(Deprecation, FlagSpec WarningFlag)] ..... flagSpec "missing-local-signatures" Opt_WarnMissingLocalSignatures, depFlagSpec "missing-local-sigs" Opt_WarnMissingLocalSignatures "it is replaced by -Wmissing-local-signatures", ..... }}} solves this problem, but it is not the best solution. It is clear that there is an implicit order when looking for warning massages, and we need to check that function to see why it selects just the first it finds. I am new to GHC development so I am still fighting with the code, and it may be worth open a new ticket to modify such function, and solve possibly any other 'bad warning massage'. Cheers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 21:38:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 21:38:31 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.917c4eb563afd4499d7fe41bf350af54@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by erikd): @trommler Yes, that may well be worth while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 23:25:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 23:25:44 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.10015456106e6eb2167731e66b2d9c7e@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.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): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2539 Comment: The problem here is that `RnExpr.patSynErr` returns a `EWildPat`, which shouldn't appear in the AST post-renaming. See Phab:D2539 for one possible fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 21 23:25:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Sep 2016 23:25:54 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.e3923fbb813bfac2e1e9f2926e4bb58d@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 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): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => 8.0.1 * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 00:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 00:00:42 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.05c2742b25e2ec77bffd649f9f6a527b@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by glguy): * cc: glguy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 02:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 02:13:05 -0000 Subject: [GHC] #11505: Boot file problem In-Reply-To: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> References: <047.7c6fed66d91a976ad91442747e4824b0@haskell.org> Message-ID: <062.f7b4401cf999d04ae08e5156b688ed35@haskell.org> #11505: Boot file problem -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): FWIW freezing stage1 and adding the following to the top of `compiler/basicTypes/ConLike.hs` and `compiler/basicTypes/ConLike.hs-boot` got me past that to a successfully built (though panic-throwing stage2) {{{ {-# LANGUAGE NoStrictData #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 09:11:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 09:11:33 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled Message-ID: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | 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 code: {{{#!hs module Main (main) where data Foo = Foo { _foo :: String , _bar :: String } deriving (Eq, Show) main :: IO () main = do let x = Foo "apple" "bear" putStrLn $ "x = " ++ show x }}} Saved as `unused-fields.hs` Then with ghc 8.0.1: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 }}} The following command will compile without error or warning: {{{ $ ghc -Wall -Werror -o unused-fields ./unused-fields.hs }}} But if `DuplicateRecordFields` is enabled, then: {{{ $ ghc -Wall -Werror -o unused-fields ./unused-fields.hs -XDuplicateRecordFields [1 of 1] Compiling Main ( unused-fields.hs, unused-fields.o ) [flags changed] unused-fields.hs:21:11: warning: [-Wunused-top-binds] Defined but not used: ‘_foo’ unused-fields.hs:22:11: warning: [-Wunused-top-binds] Defined but not used: ‘_bar’ : error: Failing due to -Werror. }}} I would have no warnings, since `_foo` and `_bar` have underscore prefixes, which is a documented way of selectively disabling this warning. (c.f. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /using-warnings.html#ghc-flag--Wunused-top-binds). Details requested by https://ghc.haskell.org/trac/ghc/wiki/ReportABug: {{{ $ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.0.0 (clang-800.0.38) Target: x86_64-apple-darwin15.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin }}} GOOD (without -XDuplicateRecordFields) {{{ $ ghc -dcore-lint -v -Wall -Werror -o unused-fields ./unused-fields.hs Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *unused-fields.hs !!! Chasing dependencies: finished in 0.68 milliseconds, allocated 0.777 megabytes Stable obj: [Main] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-09-22 08:27:24 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file unused-fields.hs *** Checking old interface for Main: [1 of 1] Skipping Main ( unused-fields.hs, unused-fields.o ) Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (2016-09-22 08:45:48 UTC) Main [DotO unused-fields.o] Linking unused-fields ... Created temporary directory: /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0 *** C Compiler: /nix/store/a5f6qqgzgmmvw0xkvlfdsjzaprmnlz2s-clang-wrapper-3.7.1/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0/ghc_1.c -o /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0/ghc_2.o -fno- common -U__PIC__ -D__PIC__ -I/nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/include *** Linker: /nix/store/a5f6qqgzgmmvw0xkvlfdsjzaprmnlz2s-clang-wrapper-3.7.1/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o unused-fields -Wl,-no_compact_unwind unused-fields.o -L/nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -L/nix/store/8dkzvp7d7vpprc8cblmjcyyyzyy9940i-libiconv-osx-10.9.5/lib -L/nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1 /integer-gmp-1.0.0.1 -L/nix/store/8b7big21k9ipi44mqlnp8njbkncwhh27-gmp-6.1.0/lib -L/nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -L/nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/rts /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0/ghc_2.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.1 -lHSghc- prim-0.5.0.0 -lHSrts -lCffi -liconv -lgmp -lm -ldl link: done *** Deleting temp files: Deleting: /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0/ghc_2.o /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0/ghc_1.c *** Deleting temp dirs: Deleting: /var/folders/6q/jpykk8bn6dq68ynzm6c1r7c40000gn/T/ghc62639_0 }}} BAD {{{ $ ghc -dcore-lint -v -Wall -Werror -o unused-fields ./unused-fields.hs -XDuplicateRecordFields Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /nix/store/vvn40k4257a2f6dlps52jnff6qa41ph3-ghc-8.0.1/lib/ghc-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *unused-fields.hs !!! Chasing dependencies: finished in 1.05 milliseconds, allocated 0.777 megabytes Stable obj: [Main] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-09-22 08:27:24 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file unused-fields.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( unused-fields.hs, unused-fields.o ) [flags changed] *** Parser [Main]: !!! Parser [Main]: finished in 1.27 milliseconds, allocated 0.517 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 128.27 milliseconds, allocated 49.950 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 141, types: 94, coercions: 0} *** Core Linted result of Desugar (after optimization): !!! Desugar [Main]: finished in 5.14 milliseconds, allocated 1.194 megabytes unused-fields.hs:22:11: warning: [-Wunused-top-binds] Defined but not used: ‘_foo’ unused-fields.hs:23:11: warning: [-Wunused-top-binds] Defined but not used: ‘_bar’ : error: Failing due to -Werror. Upsweep partially successful. *** Deleting temp files: Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 09:24:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 09:24:57 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.d577883926ca419aedb911a669e459bc@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 09:36:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 09:36:25 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.b37025d836826b597a0bf6d4e648c492@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The function which uses this ordering is `flagSpecOf`. An acceptable solution would be to sort `wWarningFlagsDeps` there so that non deprecated flags are preferred to the deprecated versions. Fixing the second problem looks more tricky, we can talk about it more once you've sorted out the first problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 14:15:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 14:15:13 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.4cd319bad5796de2f78fb545eb7b268f@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): > This is kind of a hack that relies on the directory structure that Cabal produces to be effective, but it has the advantage of being a local change. Cabal would also need some similar change in order for the final libraries that it links to be loadable. Unfortunately, in general it is the user/builder calling Cabal that gets to choose the layout, so it's hard to pick a fixed scheme. That said, we can in principle compute an optimal (or near-optimal) set of shared prefixes. We start with the info from the ghc-pkg db (InstalledPackageInfo) which has the full path to the libraries (or enough info to compute it). Then we would take the set of those paths, make a trie, count the number of elements beneath each trie node and take as shared prefixes all the ones with a count of > 1. Or something like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 14:35:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 14:35:32 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.39900630cbd3adf17409b8eb837645e4@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Package system | 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 duncan): Note that some more sharing is possible, given typical layouts. For example for nix or for cabal new-build we install into a store. {{{ $store/$pkgid-$hash/libHSpkgname-ver.so }}} (Currently it's actually worse than this since the libname includes hashes too, which should be unnecessary given the separated dirs) I'm not sure if this is possible with ELF, but if we can include part of the directory into the libname / location, and a separate RUN_PATH then we could use a scheme like: {{{ RUN_PATH /home/me/.cabal/store SO_NEEDED pkgname-ver-hash/libHSpkgname-ver.so SO_NEEDED ... }}} This does appear to be possible with MachO, ie like: {{{ LC_RPATH /home/me/.cabal/store LC_LOAD_DYLIB @rpath/pkgname-ver-hash/libHSpkgname-ver.dynlib }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 15:28:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 15:28:29 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.9f151dc9ab0ee32eb2770b2cf88eecd6@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by awson): Since I have now quite a bit of spare time, I've decided to look into this. Indeed, binutils `ld` is wrong here. I've created [https://sourceware.org/bugzilla/show_bug.cgi?id=17955#c1 the patch to binutils] which fixes things for me. OTOH, mention should be made that R_X86_64_PC64 reloc is '''not supported''' by MS in PE-COFF and neither MS `link` nor LLVM `lld` can handle it (the former simply ignores it and the latter complains about unsupported relocation type). Thus the proper way to fix it is to use a workaround similar to that used in NCG (see my comment above) to make LLVM generate R_X86_64_PC32 relocs instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 15:36:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 15:36:20 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.1492dfa816c78da11e5733ebf9505eff@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Comment (by mpickering): I don't think your comment is correct Ben. You say that > Note that the user cannot import the definitions from export list (1) with import list (2) and vice versa. But if the pattern synonym is bundled then you can import it with the `pattern` keyword just like record selectors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 15:51:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 15:51:21 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.69d18ec3bd2337a468863096b5a53690@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Package system | 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 rwbarton): According to my experiments (I only tested on Debian x86_64 with GNU ld, not gold) you can set up the NEEDED entry in that way if either * `libHSpkgname-ver.so` was built with `-soname pkgname-ver-hash /libHSpkgname-ver.so`, or * `libHSpkgname-ver.so` was built without any `-soname` set, and you link to it with {{{ -L/home/me/.cabal/store -l:pkgname-ver-hash/libHSpkgname-ver.so }}} If you set a SONAME when building `libHSpkgname-ver.so`, then it seems to be impossible to create a NEEDED entry of any other value when building a library that has it as a dependency. So if the SONAME is `libHSpkgname- ver.so`, you have to add the directory that the library lives in to the run path, as far as I can tell. I don't know how portable any of this behavior is. GHC sets the SONAME to `libHSpkgname-ver.so`, originally due to 6efacfe8bcbe66dfc3b52397ccbd34a58890520d. I don't know if it would be okay to unset it or to include the directory name in the SONAME. In any case it seems simplest to solve the problem by just putting all the shared libraries in the same directory... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 15:53:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 15:53:01 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.8d587653571b9f828636e9b7186c0279@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I suppose another dumb hack would be to just create symlinks to all our dependencies in the GHC temporary directory and set that as the RPATH... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 19:36:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 19:36:27 -0000 Subject: [GHC] #12610: Emit tab warning promptly Message-ID: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Parser) | 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): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs p = let x = 4 [tab]y = 5 in 12 }}} produces `error: parse error on input ‘y’` and nothing else. The problem is caused by a tab appearing to the user to line up `x` with `y` but actually placing `y` in the wrong column. The user typically will scratch their head and then post a question on StackOverflow. There they'll be told to use `-fwarn-tabs`, but ''that option won't help'' (and it's probably already on) because GHC will exit with a parse error before it gets around to giving the warning. I suspect the solution is probably to emit the tab warning in the lexer, but one of the parsing gurus will probably know better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 22:57:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 22:57:51 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.6741f25e882674c5502b6706c393a067@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmcgilchrist): I'd like to have a go at fixing this issue. Just so I understand it correctly a fix for this would involve supporting both `specialisation` spelling for that command line argument. I believe I have something working for `-Wmissed-specializations` and `-Wall-missed-specializations`. I couldn't find any specific tests that cover these command line arguments, is there any? As a follow up, I'm not sure if it's required, but there are other flags that appear to have the UK spelling of `specialise` like `specialise- aggressively` and `cross-module-specialise` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 22 23:06:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Sep 2016 23:06:59 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.f1371d437b5b77500b292d51f7b3cc4d@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcgilchrist): * Attachment "0001-Support-US-spelling-for-specialise-flags.patch" added. Initial patch for supporting US spellings of specialise -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 00:05:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 00:05:34 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.4da3aa09e44bb984dd72ea802f794d65@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Please fix all flags to support both spellings! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 00:45:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 00:45:59 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.6f9a31d02b005d3cf93fb4ed30eee3c0@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by khibino): * version: 7.10.3 => 8.0.1 @@ -16,1 +16,1 @@ - I make this report using examples in GHC 7.10.3, + I make this report using examples in '''GHC 7.10.3''', New description: When the code like bellow is executed, the '''shiftR''' call causes SIGABRT. c128.hs {{{#!hs import Data.Bits x:: Integer x = 1 - (1 `shiftL` (128 + 64)) main :: IO () main = print $ x `shiftR` 128 }}} I make this report using examples in '''GHC 7.10.3''', and I found the same problem in '''GHC 8.0.1''' too. backtrace using GDB {{{ % ghc -O0 c128.hs [1 of 1] Compiling Main ( c128.hs, c128.o ) Linking c128 ... % gdb ./c128 GNU gdb (Debian 7.10-1+b1) 7.10 ... Reading symbols from ./c128...(no debugging symbols found)...done. (gdb) run Starting program: /home/hibi/src/haskell/crash/Haskell/c128 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff6ed4478 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 ../sysdeps/unix/sysv/linux/raise.c: そのようなファイルやディレクト リはありません. (gdb) bt #0 0x00007ffff6ed4478 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff6ed58fa in __GI_abort () at abort.c:89 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () #3 0x000000000046e004 in salz_info () #4 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () (gdb) disas Dump of assembler code for function integer_gmp_mpn_rshift_2c: 0x0000000000471630 <+0>: push %r13 ... 0x00000000004716d8 <+168>: jne 0x4716c0 0x00000000004716da <+170>: callq 0x402c80 => 0x00000000004716df <+175>: nop 0x00000000004716e0 <+176>: lea 0x0(,%rdx,8),%rdx ... End of assembler dump. (gdb) }}} I found '''abort''' call in '''integer_gmp_mpn_rshift_2c'''. ghc-7.10.3/libraries/integer-gmp2/cbits/wrappers.c {{{#!c mp_limb_t integer_gmp_mpn_rshift_2c (mp_limb_t rp[], const mp_limb_t sp[], const mp_size_t sn, const mp_bitcnt_t count) { ... // round if non-zero bits were shifted out if (nz_shift_out) if (mpn_add_1(rp, rp, rn, 1)) abort(); /* should never happen */ return rp[rn-1]; } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 03:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 03:59:56 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.4e22b856847aaa5b67a25e5ab5cbf061@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- 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: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by clinton: @@ -5,3 +5,1 @@ - {-# LANGUAGE TypeFamilyDependencies #-} - {-# LANGUAGE FlexibleInstances #-} - {-# LANGUAGE AllowAmbiguousTypes #-} + {-# LANGUAGE TypeFamilyDependencies #-} @@ -9,1 +7,1 @@ - main = return $ f (Just 'c') + main = return $ f (Just 'c') @@ -11,2 +9,2 @@ - data D1 x - data D2 + data D1 x + data D2 @@ -14,3 +12,3 @@ - type family TF x = t | t -> x - type instance TF (D1 x, a) = Maybe (TF (x, a)) - type instance TF (D2, ()) = Char + type family TF x = t | t -> x + type instance TF (D1 x, a) = Maybe (TF (x, a)) + type instance TF (D2, ()) = Char @@ -18,2 +16,2 @@ - class C p where - f :: TF (x, a) -> () + f :: TF (x, a) -> () + f _ = () New description: I'm not sure if this is a bug or hanging the compiler is expected here. This was the minimal example that causes GHC to hang: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} main = return $ f (Just 'c') data D1 x data D2 type family TF x = t | t -> x type instance TF (D1 x, a) = Maybe (TF (x, a)) type instance TF (D2, ()) = Char f :: TF (x, a) -> () f _ = () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 04:00:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 04:00:35 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.fdf46aede0e92e4eb9f49d39982da66a@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- 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: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clinton): Further simplified code in bug report, removed unnecessary extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 04:39:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 04:39:59 -0000 Subject: [GHC] #5402: Exit code is wrong with dynamically loaded libraries In-Reply-To: <046.fcfe062e18a663b6808bccc7c015d7fa@haskell.org> References: <046.fcfe062e18a663b6808bccc7c015d7fa@haskell.org> Message-ID: <061.1e059f08bdcd3ee8e31f9de0f062c345@haskell.org> #5402: Exit code is wrong with dynamically loaded libraries -------------------------------------+------------------------------------ Reporter: Lennart | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.2 Component: Runtime System | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: ffi/should_run/5402 Blocked By: | Blocking: -------------------------------------+------------------------------------ Comment (by Simon Marlow ): In [changeset:"9cbcdb4863064753df0fff9054b7b7c6b3188b64/ghc" 9cbcdb48/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cbcdb4863064753df0fff9054b7b7c6b3188b64" shutdownHaskellAndExit: just do a normal hs_exit() (#5402) If we want to keep the RTS alive a bit longer by having another hs_init()/hs_exit() pair in a library that will destruct itself after main() has exited, then the forced shutdown here thwarts that. I think we just "fixed" #5402 in the wrong way before, this should be better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 04:39:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 04:39:59 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone In-Reply-To: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> References: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> Message-ID: <061.32ae2ef32fa9867c8d1aa965e0b7f4e4@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"3a17916bb5fd4bda9d21359a82f5b5f38cc0fdad/ghc" 3a17916b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3a17916bb5fd4bda9d21359a82f5b5f38cc0fdad" Improved documentation for Foreign.Concurrent (#12547) We had better docs for the underlying functions in GHC.ForeignPtr, but this wasn't propagated to the re-exported versions in Foreign.Concurrent. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 04:46:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 04:46:25 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.8d7a1c75c36495d7a46f80882d7565c3@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by chak): Replying to [comment:13 rwbarton]: > We did some investigation last night in IRC and came to the conclusion that the runtime loader in Sierra has a new limit on the `sizeofcmds` field which is the total size of all the load commands in the dynamic library. Looking at the `otool -l` output in an earlier attachment, we can see that the main contributors to the size are primarily the RPATH entries and to a lesser extent the LOAD_DYLIB entries. There are over 100 of each, and the paths in the RPATH entries are quite long (I guess this is why stack is affected in particular). > > So, I don't expect that disabling split objects will help at all, unfortunately. There seems to just be a limit on the total size of RPATH entries we can use. > > In fact Cabal is the one choosing these RPATHs, not GHC itself. So this will require some kind of change to Cabal to decrease the total size of the RPATH entries it produces. I suspect that this particular use of RPATHs is a remnant of trying to deal with dylibs on macOS as its done on Linux. On macOS, there is a pretty simple fix to this (which is what I use in Haskell for Mac btw). The library name of a dylib in macOS can include a path component. So, instead of just using the filename of a library by itself as its install name, simply use the filename '''prefixed''' by the package directory. So, instead of `base-x.y.z-ABCD.dylib` use `base-x.y.z/base-x.y.z-ABCD.dylib`. Then, only one RPATH is needed, namely the GHC LIBDIR (or wherever the package db is). This keeps the load command size down and solves the problem in #11587. (Incidentally, this approach in combination with using `@loader_path` in RPATH specs also allows to make relocate package dbs, which is important if you want to ship a macOS app that includes dynamically linked Haskell code.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 04:46:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 04:46:46 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.af7f6c0f6e29c1707e3a0d442d687c29@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by chak): * cc: chak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 05:36:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 05:36:40 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.f1371d437b5b77500b292d51f7b3cc4d@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcgilchrist): * Attachment "0001-Support-US-spelling-for-specialise-flags.patch" removed. Initial patch for supporting US spellings of specialise -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 05:36:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 05:36:40 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.15769f2f0ff6524203fe415af5219176@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcgilchrist): * Attachment "0001-Support-US-spelling-for-specialise-flags.patch" added. Initial patch for supporting US spellings of specialise -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 05:42:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 05:42:03 -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.308ae68c320fd42ab0a128a1c7649c93@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's another example of the phasing problem, this one posted by [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-September/026399.html Dave Menendez]: {{{ {-# LANGUAGE TemplateHaskell, TypeInType, TypeFamilies #-} module DH where import Data.Kind (Type) type family K t :: Type type family T t :: K t -> Type data List type instance K List = Type type instance T List = [] -- Error on this line -- Error is: -- * Expected kind K List -> Type, but [] has kind `* -> *` -- In the type `[]` -- In the type instance declaration for `T` }}} The reasson is the we need teh `K List` instance to typecheck the `T List` instance. Adding a separator just before the `instance T List` declaration makes it work -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 09:55:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 09:55:01 -0000 Subject: [GHC] #12611: expression calculation error Message-ID: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> #12611: expression calculation error ----------------------------------------+---------------------------- Reporter: Tom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- Prelude> 20^65-exp(65*log(20)) 6.211571712111507e70 Obviously, correct result is 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 09:56:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 09:56:10 -0000 Subject: [GHC] #12611: expression calculation error In-Reply-To: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> References: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> Message-ID: <057.ae538ff6e46b69b3f3df2be6a38a575f@haskell.org> #12611: expression calculation error -----------------------------+---------------------------------------- Reporter: Tom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Description changed by Tom: @@ -2,0 +2,1 @@ + New description: Prelude> 20^65-exp(65*log(20)) 6.211571712111507e70 Obviously, correct result is 0. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 09:56:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 09:56:39 -0000 Subject: [GHC] #12611: expression calculation error In-Reply-To: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> References: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> Message-ID: <057.a9f421f188f885b2481bbc903630deec@haskell.org> #12611: expression calculation error -----------------------------+---------------------------------------- Reporter: Tom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Description changed by Tom: @@ -1,1 +1,1 @@ - Prelude> 20^65-exp(65*log(20)) + Prelude> 20^{65}-exp(65*log(20)) New description: Prelude> 20^{65}-exp(65*log(20)) 6.211571712111507e70 Obviously, correct result is 0. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 10:04:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 10:04:22 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.c8b4270809b3d72444477e1126a40247@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): Given that I'm the one who wrote GHC's {{{@rpath}}}-relative {{{install_name}}} code, and Cabal's {{{RPATH}}}-handling code, I want to point out one problem that needs some thought before we make all the {{{install_name}}}s {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}: sometimes, the libraries that we link against aren't in their installed location yet. And there is one particular case when this is a problem: when a Cabal {{{testsuite}}} executable is dynamically linked against the library under development. In this case, the {{{libname-x.y.z.dylib}}} is still in {{{./dist/build}}}. Now, because (currently) the {{{install_name}}} is simply {{{@rpath/libname-x.y.z.dylib}}}, we can simply execute the {{{testsuite}}} executable where the {{{DYLD_LIBRARY_PATH}}} contains {{{./dist/build}}}. If the {{{install_name}}} is going to be changed to {{{@rpath/libname-x.y.z/libname-x.y.z.dylib}}}[1], then we have to take care of the above-mentioned problem. [1] Another solution is of course to put (or symlink) all the {{{.dylib}}}s in the {{{$lib}}} directory instead of {{{$lib/libname-x.y.z}}}, which I've seen being suggested, but is something I personally don't like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 10:18:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 10:18:16 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.3bc2cbfc8915501d24ff3e90228ee966@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): Also, I'll be attending the hackathon on 8 and 9 October (after Haskell Exchange 2016), so if this problem isn't already fixed by that time, I volunteer to work on a patch during the hackathon. I won't have time to work on it on any other date or time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 10:48:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 10:48:20 -0000 Subject: [GHC] #12611: expression calculation error In-Reply-To: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> References: <042.39b04d179d98cfa5acaa44cee7ed3191@haskell.org> Message-ID: <057.00e86577e0b592cd959464c35228bff3@haskell.org> #12611: expression calculation error -----------------------------+---------------------------------------- Reporter: Tom | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by hsyl20): * status: new => closed * resolution: => invalid Comment: This is a precision issue with Double numbers: {{{ > 2^21-exp(21*log(2)) :: Double 0.0 > 2^22-exp(22*log(2)) :: Double -9.313225746154785e-10 > 2^22 :: Double 4194304.0 > exp(22*log(2)) :: Double 4194304.000000001 }}} You get the same result with other languages: {{{ php > echo (20**65 - exp(65*log(20))) ; 6.1252998827766E+70 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 14:34:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 14:34:18 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.c4dc1b70ce085b70bea97785646e9321@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch 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: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"9766b0c81476c208b2b29ff66d97251209a79707/ghc" 9766b0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9766b0c81476c208b2b29ff66d97251209a79707" Fix #12442. The problem is described in the ticket. This patch adds new variants of the access points to the pure unifier that allow unification of types only when the caller wants this behavior. (The unifier used to also unify kinds.) This behavior is appropriate when the kinds are either already known to be the same, or the list of types provided are a list of well-typed arguments to some type constructor. In the latter case, unifying earlier types in the list will unify the kinds of any later (dependent) types. At use sites, I went through and chose the unification function according to the criteria above. This patch includes some modest performance improvements as we are now doing less work. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 14:36:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 14:36:46 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.b9fd53335c445a7d1e3c7bfaf3f7b266@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12442 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T12442 * status: patch => closed * resolution: => fixed Comment: Finally got around to dotting the i's and crossing the t's here. We're all set. I don't think this is worth merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 15:07:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 15:07:50 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.30063306a599f69513addd8c707fa2ab@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * status: new => closed * resolution: => invalid Comment: Ok, I believe there is no ghc bug here, although admittedly these issues are incredibly subtle. The memory leak comes from the full laziness optimization, as @int-e points out. The interaction with -fprof-auto that I observed comes from interaction of cost centres with the state hack. And the difference between Michael's two examples turns out to be unimportant; if you split example one into two separate modules so that the optimizer gets less change to optimize the heck out of it, the memory behaviour of both examples is identical. I've written a long blog post that explores these issues in great detail; will publish soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 15:10:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 15:10:05 -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.9c61f1060f6777f8db5f41144f1b0915@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by alexvieth): Replying to [comment:28 simonpj]: > It is cool but it should have a separate ticket. Richard can you do that? It's here: #11962 Simon, what do you think of my idea from comment 25? > Bottom line. Instead of getting in deeper, pull back. Do somthing that is simple to explain, predicatable, and simple to implement, even if it' a little less convenient. The proposed phasing annotations might be convenient for ghc developers but they'd be inconvenient and surprising for ghc users. I appreciate that, at the term level, I don't need to worry about the order of my definitions. I'd like the same to be true at type level if possible, and I think it is possible. I'm just not sure if it will be simple to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 17:19:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 17:19:54 -0000 Subject: [GHC] #9248: Document -XHaskell98 and -XHaskell2010 in flag reference In-Reply-To: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> References: <047.f98b7df1c3966676c7fecca73ea7b44a@haskell.org> Message-ID: <062.a4902bf8f424dbb73dc83761eb1eae98@haskell.org> #9248: Document -XHaskell98 and -XHaskell2010 in flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #1880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: This should really be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 17:22:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 17:22:25 -0000 Subject: [GHC] #7181: Add documentation on heap-profile file format. In-Reply-To: <051.247007a210239a29682524bb180e55fc@haskell.org> References: <051.247007a210239a29682524bb180e55fc@haskell.org> Message-ID: <066.3d23d0cf73bae952c2b59dc3d3ce5cd3@haskell.org> #7181: Add documentation on heap-profile file format. -------------------------------------+------------------------------------- Reporter: schernichkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.4.2 Resolution: | 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): * milestone: => 8.2.1 Comment: We should be able to close this with the 8.2 release as we will support sending heap profiler census data to the eventlog, the encoding of which is documented in the users guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 17:22:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 17:22:49 -0000 Subject: [GHC] #7181: Add documentation on heap-profile file format. In-Reply-To: <051.247007a210239a29682524bb180e55fc@haskell.org> References: <051.247007a210239a29682524bb180e55fc@haskell.org> Message-ID: <066.0da9777b7f414ff6eb7357d82e999a33@haskell.org> #7181: Add documentation on heap-profile file format. -------------------------------------+------------------------------------- Reporter: schernichkin | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.4.2 Resolution: wontfix | 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: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 18:57:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 18:57:26 -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.5cad1d17c62a23ea3b0404c46ef66371@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): RE comment:25: * I have no idea how to actually implement this idea. Type constructors, axioms, etc have no late-bound holes in them and it would be architeturally difficult to change that, becuase they are all tied together so they point to each other in a graph. Difficult to update. * More seriously, I do not know whother the resulting system would be sound. The kinding of one instance depends on executing another instance; and vice versat. At at minimum I'd want to see a ''specification'' in langauge that a type-theory person could understand, and a sketch proof of soundness. * Stephanie Weirich and Ricahrd Eisenberg are world experts of this stuff. We sat down and ICFP and made zero progress. That doesn't mean that no progress is possible; but it does mean that it's premature to implement anything until we undersatnd the theory. * It's important to bre able to explain to programmers exactly what will kind-check and what will not. The fact that the implementation is already jolly tricky, and yet does not do the job, is a worry. Making it much more complicated still feels wrong to me. Better to withdraw to something that is (a) simple to explain and (b) simple to implement. That leaves a clear research challenge for some research student to tackle. > I appreciate that, at the term level, I don't need to worry about the order of my definitions. I agree. But I don't know anything better. If Ricahrd gets his way, thing will happen at the term level, when typing `f` requires executing `g` anf vice versa. Except it's worse at the type level becaues of open type families. I specualte that you'll never need a phasing annotation if you only need closed type families. Maybe that's why this issue doesn't show up for Coq, Agda etc? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 19:04:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 19:04:38 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.507613be8da61c585314376cedcc998c@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Edsko: when you've written the post, do link it from this ticket so that people following the trail can find it. (Both as a comment and in the main Description, I suggest.) Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 19:17:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 19:17:11 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types Message-ID: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | 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 rejects the following code: {{{#!hs class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a }}} with this error message {{{ • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ }}} See [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-September/026402.html e-mail discussion]. This is connected to #12088, at least as far as defining instances of C. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 19:32:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 19:32:08 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types In-Reply-To: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> References: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> Message-ID: <066.493f10e3fa37ee86c790a64bd38bf968@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 19:56:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 19:56:05 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.f36571fcb32490e936aee76f6eb72ae5@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12442 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard there are no comments to explain what is going on here. The brief comments that are there suggest that it's just an efficiency thing: when unifying `t1 :: k1` with `t2 :: k2`, if you happen to know that `t1 = t2` (in the `eqType`, defnitional equality sense) then no need to match them. Saves work. But there is much more to it than that! You say, cryptically, that "sometimes it is downright wrong". But you need to say that in the code, and support it with a few examples that demonstrate how wrong it is, and justify the cases where you use the laxer matching. Could you do that? This is subtle stuff, and I'm anxious about making it robust to future modification. Also, all the remaining calls to `tcMatchTy` now have to guarantee an invariant, that the kinds are `eqType`. I see nothing at the calls sites drawing attention to that claim, and justifying why, at that call site, it holds. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 21:10:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 21:10:13 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.079dd0f6fdba6eaa983487a1413317dd@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer, ORF 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: newcomer => newcomer, ORF * cc: adamgundry (added) Comment: Adam, might you look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 21:20:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 21:20:52 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.3e22fd2ee7e9ad00af5cb09b024db280@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): tmcgilchrist, please you put your patch on phabricator? You can find instructions on the [https://ghc.haskell.org/trac/ghc/wiki/Phabricator wiki]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 22:31:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 22:31:37 -0000 Subject: [GHC] #12613: Fix spelling of INLIN(E)ABLE in comments Message-ID: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> #12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | 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: -------------------------------------+------------------------------------- The correct spelling is `INLINABLE`. It is confusing to read comments which refer to `INLINEABLE`. How to fix this: 1. `git grep INLINEABLE` 2. Open all the files and change to `INLINABLE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 22:40:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 22:40:43 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.4ea77ccc5d59689377ce9ffd8e7b581e@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | Owner: tmcgilchrist 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcgilchrist): * owner: => tmcgilchrist -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 22:49:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 22:49:40 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.f7c3af4db35988bab7793afad468b634@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | Owner: tmcgilchrist 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmcgilchrist): Submitted as https://phabricator.haskell.org/D2542 Think I followed the instructions correctly, please let me know if I didn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 22:56:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 22:56:32 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.42e9881ad8db2d8922f0997152e132cc@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | Owner: tmcgilchrist 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2542 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D2542 Comment: Looks like you did everything right. I left some comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 22:59:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 22:59:38 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.4695feca9366aedea041bf234aa58933@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Parser) | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Actually, the problem ''seems'' to be that the lexer adds tab warnings to some sort of warning log, and then `GHC.parser` only calls `getMessages` to retrieve a warning log summary when the parse is successful. We should probably change that to get at least some of the warnings in case of an unsuccessful parse. If it's impossible to change the type of `GHC.parser` between minor versions, then we could either add a function with the right type to use for `ghc` proper, or we could temporarily change `GHC.parser` to dump certain warnings into the error bucket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 23:12:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 23:12:54 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.62602fab8bd2a86bf1abdf116c419da7@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Parser) | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Good catch, that ought to be fixed. I’d say: Do the proper fix first on HEAD, and then think about the form of a possible backport. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 23 23:18:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Sep 2016 23:18:43 -0000 Subject: [GHC] #12613: Fix spelling of INLIN(E)ABLE in comments In-Reply-To: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> References: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> Message-ID: <064.a8ff434ca37d290682f47eaa054f8a5b@haskell.org> #12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | 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 nomeata): JFTR: It’s not only in comments; it is used as pragmas in many files: {{{ libraries/base/Control/Monad.hs:{-# INLINEABLE foldM #-} libraries/base/Control/Monad.hs:{-# INLINEABLE foldM_ #-} libraries/base/Control/Monad.hs:{-# INLINEABLE replicateM #-} libraries/base/Control/Monad.hs:{-# INLINEABLE replicateM_ #-} libraries/base/Control/Monad.hs:{-# INLINEABLE unless #-} libraries/base/Control/Monad.hs:{-# INLINEABLE mfilter #-} libraries/base/Data/Bits.hs:{-# INLINEABLE toIntegralSized #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftA #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftA2 #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftA3 #-} libraries/base/GHC/Base.hs:{-# INLINEABLE when #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftM #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftM2 #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftM3 #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftM4 #-} libraries/base/GHC/Base.hs:{-# INLINEABLE liftM5 #-} libraries/base/GHC/Base.hs:{-# INLINEABLE ap #-} libraries/base/GHC/List.hs:{-# INLINEABLE maximum #-} libraries/base/GHC/List.hs:{-# INLINEABLE minimum #-} libraries/base/GHC/Real.hs:{-# INLINEABLE even #-} libraries/base/GHC/Real.hs:{-# INLINEABLE odd #-} }}} Are all these pragmas broken? No: Both are accepted by the lexer: {{{ ("inlinable", strtoken (\s -> (ITinline_prag s Inlinable FunLike))), ("inlineable", strtoken (\s -> (ITinline_prag s Inlinable FunLike))), -- Spelling variant }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 00:21:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 00:21:22 -0000 Subject: [GHC] #12613: Fix spelling of INLIN(E)ABLE in comments In-Reply-To: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> References: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> Message-ID: <064.027373a6ea1d5aefbf952a175001aafc@haskell.org> #12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | 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 Joachim Breitner ): In [changeset:"68f72f101d67b276aff567be03619a3fd9618017/ghc" 68f72f10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68f72f101d67b276aff567be03619a3fd9618017" Replace INLINEABLE by INLINABLE (#12613) as the latter is the official, correct spelling, and the former just a misspelling accepted by GHC. Also document in the user’s guide that the alternative spelling is accepted This commit was brough to you by HIW 2016. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 00:21:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 00:21:43 -0000 Subject: [GHC] #12613: Fix spelling of INLIN(E)ABLE in comments In-Reply-To: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> References: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> Message-ID: <064.df2a2b7c3e65cf8deecbfee707b4508d@haskell.org> #12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 02:09:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 02:09:41 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy In-Reply-To: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> References: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> Message-ID: <059.bf406ef527b4c5d364723acfa6134101@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: SafeHaskell, | 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: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 02:10:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 02:10:43 -0000 Subject: [GHC] #11812: Template Haskell can induce non-unique Uniques In-Reply-To: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> References: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> Message-ID: <062.8f2ff05f5b4268292f525756cda82067@haskell.org> #11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 02:12:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 02:12:16 -0000 Subject: [GHC] #12073: Missing instance of MonadFix for Q In-Reply-To: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> References: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> Message-ID: <061.50a5f870c8576da5eeff4d354c6dca0a@haskell.org> #12073: Missing instance of MonadFix for Q -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 02:14:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 02:14:00 -0000 Subject: [GHC] #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class In-Reply-To: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> References: <050.eb69c313a059df9b62466d07df30fd0b@haskell.org> Message-ID: <065.1056dbd71b06de4b6841ce5692e8770a@haskell.org> #12387: Template Haskell ignores class instance definitions with methods that don't belong to the class -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 06:57:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 06:57:15 -0000 Subject: [GHC] #12126: Bad error messages for SPECIALIZE pragmas In-Reply-To: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> References: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> Message-ID: <061.0832cd77bd4f4c8bdad746ee96178ac4@haskell.org> #12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Specialize, | ErrorMessages, 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 tmcgilchrist): Might I put my hand up to attempt fixing this mpickering? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 08:03:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 08:03:48 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.be20b2d9609acce0a3c964689d635385@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 08:04:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 08:04:30 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.2f900c4ee7e8705368aa286f4160b257@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: erikd (removed) Comment: Matthew Pickering and I were recently pondering this. I wrote down some thoughts on the matter on #12463. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 08:06:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 08:06:30 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.5483b38bb624b64084b8d1979a7f860b@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 08:13:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 08:13:00 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.f8c54e8dadc787c71877f06c01815b40@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 bgamari): It is true that the `SPECIALISABLE` proposal is essentially `INLINEABLE`. However, I think the recursive variant is novel (although admittedly poorly specified). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 08:23:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 08:23:55 -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.2057fa06f5bf2b70b3ff9a5f934d30d1@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 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): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Motivated by the lightning talk, a note on the wording “bespoke”. To me, “bespoke” would be a instance that is tailored to my needs (e.g. “ignore field x in the Eq instance, because it is just a cached value that depends on the other”). The derived instance is not bespoke in that sense. It is more of a stock instance. How about `deriving stock Eq` instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 10:03:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 10:03:04 -0000 Subject: [GHC] #12613: Fix spelling of INLIN(E)ABLE in comments In-Reply-To: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> References: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> Message-ID: <064.5645004ed2de98931195b251f2fc0715@haskell.org> #12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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): Thanks Joachim. My next question, why is `INLINEABLE` even accepted at all. We don't accept misspellings of other pragmas, why is this different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 10:29:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 10:29:25 -0000 Subject: [GHC] #12126: Bad error messages for SPECIALIZE pragmas In-Reply-To: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> References: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> Message-ID: <061.1a4caf1cf9df58a51d36092ffe286001@haskell.org> #12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Specialize, | ErrorMessages, 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 mpickering): Yes, of course! I made the notes so that it would be easier for someone else to tackle this. If you need any help make sure to ask. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 11:41:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 11:41:15 -0000 Subject: [GHC] #12613: Fix spelling of INLIN(E)ABLE in comments In-Reply-To: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> References: <049.d4377d49dbd5f31ef1fe092fce490d0d@haskell.org> Message-ID: <064.4ab212331fc252ef51fcdec1e334bbd9@haskell.org> #12613: Fix spelling of INLIN(E)ABLE in comments -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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): FWIW, there are 996 spellings of INLINEABLE and 5773 spellings of INLINABLE on hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 13:35:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 13:35:58 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call Message-ID: <046.8ed09565bce5acc57db433cace631df1@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: integer | Operating System: Unknown/Multiple division | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you call a foreign function, GHC can generate incorrect code while passing the arguments to the function, overwriting the 3rd argument if a later argument contains an integer division. Main.hs: {{{ {-# LANGUAGE ForeignFunctionInterface #-} module Main where {-# NOINLINE foo #-} foo :: Int -> IO () foo x = c_foo 0 0 x $ x + x `quot` 10 foreign import ccall "foo" c_foo :: Int -> Int -> Int -> Int -> IO () main :: IO () main = do foo 202 foo 203 foo 204 }}} foo.c: {{{ #include void foo(int a, int b, int c, int d) { printf("%d, %d, %d, %d\n", a, b, c, d); } }}} Expected output: {{{ 0, 0, 202, 222 0, 0, 203, 223 0, 0, 204, 224 }}} Actual output: {{{ 0, 0, 2, 222 0, 0, 3, 223 0, 0, 4, 224 }}} The bug has to be somewhere in the code generator. The cmm reads: {{{ call "ccall" arg hints: [‘signed’, ‘signed’, ‘signed’, ‘signed’] result hints: [] foo(0, 0, _s3nE::I64, _s3nE::I64 + %MO_S_Quot_W64(_s3nE::I64, 10)); }}} This generates the following assembler code: {{{ xorl %edi,%edi xorl %esi,%esi movq %rbx,%rdx movl $10,%ecx movq %rax,%rdx <-- move 3rd argument into rdx movq %rbx,%rax movq %rdx,%r8 cqto idivq %rcx <-- rax := rax / rcx; rdx := rax % rcx movq %rbx,%rcx addq %rax,%rcx subq $8,%rsp xorl %eax,%eax movq %r8,%rbx call foo }}} Thus rdx is overwritten again before the call, leading to incorrect results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 13:52:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 13:52:20 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.72d94ba1704e87d10eeeee6ed21ae797@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): This looks very similar to #11792. Isn't the foreign call unsafe in your test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 14:05:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 14:05:59 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings Message-ID: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | 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 example given in the [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html #record-pattern-synonyms documentation] gives a warning when compiled with `-Wall`: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# OPTIONS_GHC -Wall #-} module Test where -- Test.hs:13:24: warning: [-Wname-shadowing] -- This binding for ‘x’ shadows the existing binding -- defined at Test.hs:13:15 -- -- Test.hs:13:27: warning: [-Wname-shadowing] -- This binding for ‘y’ shadows the existing binding -- defined at Test.hs:13:18 pattern Point :: Int -> Int -> (Int, Int) pattern Point{x, y} = (x, y) }}} I don't see anything being shadowed here, so I don't think GHC should produce these warnings. Also, the type signature for that example in the documentation is `pattern Point :: (Int, Int)`, which doesn't compile. Should I file a separate bug for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 14:23:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 14:23:26 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings In-Reply-To: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> References: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> Message-ID: <061.d22a634299f9009794aaaeaec1ccd861@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms * owner: => mpickering Comment: I will take care of both points mentioned in the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 14:35:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 14:35:54 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.f5521496cd17ef46e4d14c61e4b2c8d8@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Comment (by gelisam): I can reproduce the problem outside of ghci, but only if the pattern synonym is defined in a separate file: {{{#!hs {-# LANGUAGE NamedFieldPuns, PatternSynonyms, RecordWildCards #-} module Point where pattern Point :: Int -> Int -> (Int, Int) pattern Point{x, y} = (x, y) -- works sameFile :: (Int,Int) sameFile = let { x = 1; y = 2 } in Point { .. } }}} {{{#!hs {-# LANGUAGE NamedFieldPuns, PatternSynonyms, RecordWildCards #-} module Test where import Point -- works namedFieldPuns :: (Int,Int) namedFieldPuns = let { x = 1; y = 2 } in Point { x, y } -- error: Pattern synonym ‘Point’ used as a data constructor recordWildCards :: (Int,Int) recordWildCards = let { x = 1; y = 2 } in Point { .. } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 14:47:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 14:47:56 -0000 Subject: [GHC] #12616: type synonyms confuse generalized newtype deriving role checking Message-ID: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> #12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: generalized | Operating System: Unknown/Multiple newtype deriving roles rankntypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Below is a small Haskell file showing the problem. It defines a simple `MonadTrans` typeclass, but using a type operator `~>`. When using the type operator, GHC complains that generalized newtype deriving gets stuck on a nominal role, but when the type operator is not used then GND works just fine. Perhaps this is just expected behavior with mixing RankNTypes and GND (and roles), but it's rather unfortunate. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} module GND where type m ~> n = forall a. m a -> n a class MonadTrans t where -- > this line works: -- lift :: (Monad m) => m a -> t m a -- > this line doesn't: lift :: (Monad m) => m ~> t m data StateT s m a = StateT { runStateT :: s -> m (a, s) } instance MonadTrans (StateT s) where lift xM = StateT $ \ s -> do { x <- xM ; return (x,s) } newtype OtherStateT s m a = OtherStateT { runOtherStateT :: StateT s m a } deriving (MonadTrans) }}} The error message is: {{{ GND.hs:23:13: error: • Couldn't match representation of type ‘m1 ~> StateT s m1’ with that of ‘m1 a1 -> OtherStateT s m1 a1’ arising from a use of ‘GHC.Prim.coerce’ • In the expression: GHC.Prim.coerce (lift :: (~>) m (StateT s m)) :: forall (m :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). Monad m => (~>) m (OtherStateT s m) In an equation for ‘lift’: lift = GHC.Prim.coerce (lift :: (~>) m (StateT s m)) :: forall (m :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). Monad m => (~>) m (OtherStateT s m) When typechecking the code for ‘lift’ in a derived instance for ‘MonadTrans (OtherStateT s)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘MonadTrans (OtherStateT s)’ • Relevant bindings include lift :: m ~> OtherStateT s m (bound at GND.hs:23:13) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 15:05:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 15:05:19 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.8f8b9ded326ca5b47fcb39c8f288e796@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 mpickering): * owner: => mpickering Comment: Fix is easy. Sorry for not looking sooner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 15:21:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 15:21:26 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same Message-ID: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | 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: -------------------------------------+------------------------------------- It always seemed strange to me that the interfaces for `traceTc` and `traceRn` were different. {{{#!hs traceTc :: String -> SDoc -> TcM () traceRn :: SDoc -> RnM () }}} I personally prefer using the `traceTc` interface and have to look up each time which function uses which interface. It seems beneficial but annoying to make `traceRn` have the same interface to improve usability slightly. Are there any objections if someone was to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 15:32:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 15:32:23 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.3da797cfc3b4eda7231cd98d12b4dc84@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 mpickering): * status: new => patch Comment: Would be good to merge I think Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 16:15:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 16:15:09 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings In-Reply-To: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> References: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> Message-ID: <061.ce1bba44081cc673543bf3b886f473ef@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This isn't actually a problem with record pattern synonyms per se but something that is exposed by them. You can also trigger the problem with {{{#!hs {-# LANGUAGE NoImplicitPrelude, PatternSynonyms #-} {-# OPTIONS_GHC -Wall #-} module Test where x = () pattern Point2 :: () -> () -> ((), ()) pattern Point2 x y = (x, y) }}} This is because the way checking for shadowed names works assumes that all patterns are introducing binders. Clearly in the case of pattern synonyms this assumption fails so we need to refine this check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 16:22:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 16:22:40 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings In-Reply-To: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> References: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> Message-ID: <061.4bd7ed09f422bc2d725fb4862a24b4b7@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T12615 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * testcase: => patsyn/should_compile/T12615 * differential: => Phab:D2545 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 16:41:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 16:41:16 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.756a16e3612e756d1867899a8e76990a@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnislaih): * cc: mnislaih (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 17:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 17:52:06 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same In-Reply-To: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> References: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> Message-ID: <064.1d756ff40f33425bca489b57ef6b65e8@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | 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): I'm all for it. Historical accident. I much prefer the `traceTc` interface. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 18:54:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 18:54:20 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core Message-ID: <046.22cf3f9084aee871c2af64177631d815@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- A long-standing performance bug in GHC is its behaviour on nested tuples. * The poster-child case is #5642. * The problem is that when you have a nested tuple application, e.g. `((4,True),('c','d'))`, the size of the type arguments grows quadratically with the expression size. This bites badly in some approaches to generic programming, which use nested tuples heavily. * It's explained in detail in Section 2.3 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications]. The same paper describes a solution, a modification of System F called System IF. It's neat, and I did once implement in in GHC. But it was quite complicated; most of the time the win was not big; and I don't know how it'd interact with casts, coercions, and type dependency in the latest version of GHC's Core. So here's another idea, which came up in converstion at ICFP'16: '''add a staturated constructor application to Core'''. So Core looks like {{{ data Expr v = Var v | App (Expr v) (Expr v) ... | ConApp DataCon [Expr v] -- NEW }}} Now I hate the idea of adding a new constructor to Core; I often brag about how few constructors it has. But the idea is this: * A `ConApp` is always saturated; think of it as an uncurried application. * Every data constructor has a wrapper Id. For simple constructors like `(:)`, the wrapper is just a curried version: {{{ (:) = /\a. \(x:a). \(y:[a]). (:) [x,y] }}} where the "`(:) [x,y]`" is just my concrete syntax for a `ConApp` node. * We are used to having an intro and elim form for each type former. So for `(->)` the intro form is `\x.e` and the elim form is `(e1 e2)`. For a data type like `Maybe`, the elim form is `case`, but what's the intro form? `ConApp` of course. * A `ConApp` mentions the `DataCon` explicitly, rather than having it buried inside the `IdDetails` of an `Id`, which somehow seems more honest. The proximate reason for doing this in the first place is to allow us to omit type arguments. Consider `Just True`. Curently we represent this as {{{ Var "Just" `App` Type boolTy `App` Var "True" }}} But with `ConApp` we can say {{{ ConApp "Just" [ConApp "True" []] }}} because it's easy to figure out the `boolTy` type argument from the argument. (We don't really have strings there, but you get the idea.) Can we omit ''all'' the type arguments? No: we can omit only those that appear free in any of the argument types. That is usally all of them (including existentials) but not always. Consider: {{{ data (,) a b where (,):: forall a b. a -> b -> (a,b) data [] a where [] :: forall a. [a] (:) :: forall a. a -> [a] -> [a] data Either a b where Left :: forall a b. a -> Either a b Right :: forall a b. b -> Either a b data (:=:) a b where Refl :: forall a b. (a~b) -> :=: a b data Foo where MkFoo :: a -> (a -> Int) -> Foo }}} For all of these data constructors except `[]` (nil), `Left` and `Right` we can omit all the type arguments, because we can recover them by simple matching against the types of the arguments. A very concrete way to think about this is how to implement {{{ exprType :: Expr Id -> Type exprType (Var v) = varType v exprType (Lam b e) = mkFunTy (varType b) (exprType e) exprType (App f a) = funResultTy (exprType f) ... exprType (ConApp con args) = mkTyConApp (dataConTyCon con) ??? }}} We know that the result type of type of a `ConApp` will be `T t1 ..tn` where `T` is the parent type constructor of the `DataCon`. But what about the (universal) type args `???`? We can get them from the types of the arguments `map exprType args`: * For `ConApp "(:)" [e1, e2]`, the type arument is just `exprType e1`. * For `ConApp "(:=:)" [e]`", we expect `exprType e` to return a type looking like `TyConApp "~" [t1, t2]`. Then `t1` and `t2` are the types we want. So matching is required. * What about an application of `Left`?? We need to recover two type args, but `exprType e1` gives us only one. So we must retain the other one in the application: `ConApp "Left" [Type ty2, e1]`. Similarly for the empty list. A simple once-and-for-all analyis on the `DataCon` will establish how to do the matching, which type args to retain, etc. Tradeoffs: * Pro: We can eliminate almost all type args of almost all data constructors; and for nested tuples we can eliminate all of them. * Pro: it's elegant having the intro/elim duality. * Pro: in GHC we often ask "is this expression a saturated constructor application?" (see `exprIsConApp_maybe`) and `ConApp` makes it easier to answer that question. * Pro: we do exactly this in types: we have `AppTy` and `TyConApp`. (In types a `TyConApp` is not required to be satureted, but we could review that choice.) * Con: adding a constructor is a big deal. In lots of places we'd end up saying {{{ f (App e1 e2) = App (f e1) (f e2) f (ConApp c es) = ConApp c (map f es) }}} In the olden days GHC's `App` had multiple arguments and the continual need to work over the list was a bit tiresome. Still `ConApp` is very simple and uniform; quite often adding `map` won't be difficult; and it may well be that constructors need to be treated differently anyway. * Con: it's not a general solution to the type-argument problem. See #9198 for example. System IF is the only general solution I know, but it seems like too big a sledgehammer. We'll only know if we try it. I estimiate that it would take less than a week to work this change through all of GHC. 90% of it is routine. Other possibly-relevant tickets are #8523, #7428, #9630. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 18:56:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 18:56:19 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.bf314add079059f44229968f052d65d4@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Comment (by simonpj): You've put it in patch status, but I see no patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 19:17:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 19:17:04 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.76cdb3f9469c61aa77418211d6b13ede@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D2544 Comment: Patch is here: https://phabricator.haskell.org/D2544 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 19:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 19:33:12 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.fa790281e36ef959519c714ca7071609@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Ah, I was mistaken, there is two separate problems here. The patch fixes the second on reported today but the first one is a different issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 19:34:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 19:34:18 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.e623d048a2390deed20dfd3a800ddd04@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What is "first" and "second"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 19:39:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 19:39:33 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.1b939df13bde23560e8354d5a7db3d66@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 simonpj): > However, I think the recursive variant is novel (although admittedly poorly specified). What is "the recursive variant"? The Description says: > If we include an INLINEABLE pragma (as most performance-aware authors would do) then we can convince GHC to produce an unfolding, but only at the expense of lowering its inlining cost as wel. That is not true. INLINABLE does ''not'' reduce the inlining cost. It merely (and solely) arranges to capture the entire (Core of the) source- code defnition, including if the function is recursive. No more and no less. > We really just want GHC to behave like each use-site's module has a SPECIALISE pragma for each concrete type that the function is used at. And that is exactly what INLINABLE does. I feel I'm missing something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 19:51:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 19:51:28 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.743ad21c79464d9625c82f76d3ddae28@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 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): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The patch fixes comment:4 but doesn't fix the case where a user defines a record pattern synonym in the GHCi prompt. To be specific, here is the exact example which still fails. {{{ *Test Prelude> pattern P{x} = Just x *Test Prelude> let x=5 in P{..} :8:12: error: Illegal `..' notation for constructor ‘P’ The constructor has no labelled fields }}} It seems that `tcg_field_env` is not updated properly somewhere with the record pattern synonym selectors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 20:03:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 20:03:32 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.f7b12c9b8820161d5049108ac1a00309@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): JFollowing your plea today, I've just tried this with HEAD. I get great, specialised code. I don't have 8.0 available. Can you try and see what happens now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 20:09:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 20:09:40 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.c919c79568254a446a154437b1b9e617@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 20:25:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 20:25:47 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.285ffea390582382b2683713493862cd@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: | -------------------------------------+------------------------------------- @@ -27,7 +27,7 @@ - unfolding for `aLibraryFunction` due to its size. If we include an - `INLINEABLE` pragma (as most performance-aware authors would do) then we - can convince GHC to produce an unfolding, but only at the expense of - lowering its inlining cost as well. This is unfortunate since we never - wanted GHC to inline; merely to specialize. This is issue especially - prevalent in code using MTL-style effects, where we have ubiquitous - overloading of very frequently-used functions (e.g. bind). + unfolding for `aLibraryFunction` due to its size. We can only convince GHC + to produce an unfolding for `aLibraryFunction` if we annotate it with an + `INLINEABLE` pragma. While this is often effective, it doesn't really say + what we mean: We don't never want GHC to inline; merely to specialize. + This is issue especially prevalent in code using MTL-style effects, where + we have ubiquitous overloading of very frequently-used functions (e.g. + bind). @@ -47,1 +47,1 @@ - This would request that GHC would keep an inlining around and produce a + This pragma requests that GHC keep an inlining around and produce a @@ -50,1 +50,1 @@ - weak, allowing the linker to cull duplication code when possible. + weak, allowing the linker to cull duplicated code when possible. @@ -52,1 +52,34 @@ - Moreover, a variant of this might be, + # Transitive specialisation + + The above `SPECIALISE` pragma still doesn't address the fragility of + specialisation, however. Namely, consider, + {{{#!hs + module ALibrary where + class AClass + instance AClass Int + aLibraryFunction :: AClass a => a -> a + aLibraryFunction = {- some large expression involving methods of AClass -} + {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} + + module AnotherLibrary where + import ALibrary + aFunction :: AClass a => a -> a + aFunction x = {- ... -} aLibraryFunction x {- ... -} + + module AUser where + import AnotherLibrary + f = let x :: Int + x = 5 + in aFunction x + }}} + Here `aLibraryFunction` may depend crucially on specialisation; however, + the polymorphic user `aFunction` has no way of knowing this and may be too + large for GHC to produce an unfolding automatically. This ultimately means + that GHC will be unable to specialise the eventual instantiation at `Int` + in `AUser.f`. This will mean that the performance characteristics of + `ALibrary` will be rather fragile. + + One (admittedly rather heavy) approach to solving this fragility is to + inform GHC that `aLibraryFunction`'s polymorphic callsites should have + unfoldings, ensuring that we are able to specialise the eventual + monomorphic callsite, @@ -60,1 +93,1 @@ - need to know about a library's expectations of the simplifier. + need to know about `aLibrarFunction`'s expectations of the simplifier. New description: Currently it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. We can only convince GHC to produce an unfolding for `aLibraryFunction` if we annotate it with an `INLINEABLE` pragma. While this is often effective, it doesn't really say what we mean: We don't never want GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} }}} The list of type binders after `SPECIALISE` is the set of binders which GHC would attempt to specialize. This pragma requests that GHC keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, the produced symbols could be declared as weak, allowing the linker to cull duplicated code when possible. # Transitive specialisation The above `SPECIALISE` pragma still doesn't address the fragility of specialisation, however. Namely, consider, {{{#!hs module ALibrary where class AClass instance AClass Int aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} module AnotherLibrary where import ALibrary aFunction :: AClass a => a -> a aFunction x = {- ... -} aLibraryFunction x {- ... -} module AUser where import AnotherLibrary f = let x :: Int x = 5 in aFunction x }}} Here `aLibraryFunction` may depend crucially on specialisation; however, the polymorphic user `aFunction` has no way of knowing this and may be too large for GHC to produce an unfolding automatically. This ultimately means that GHC will be unable to specialise the eventual instantiation at `Int` in `AUser.f`. This will mean that the performance characteristics of `ALibrary` will be rather fragile. One (admittedly rather heavy) approach to solving this fragility is to inform GHC that `aLibraryFunction`'s polymorphic callsites should have unfoldings, ensuring that we are able to specialise the eventual monomorphic callsite, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE_RECURSIVE(a) forall a. aLibraryFunction :: a -> a #-} }}} Which would ensure that polymorphic use-sites of `aLibraryFunction` would themselves be marked as `SPECIALISE_RECURSIVE`, shielding users from the need to know about `aLibrarFunction`'s expectations of the simplifier. -- Comment (by bgamari): > What is "the recursive variant"? The variant of the `RECURSIVE_SPECIALISABLE` pragma that I describe in the ticket summary. A better name might be *transitive specialisable*. See #8774 for another description of the motivation for this idea. > That is not true. INLINABLE does not reduce the inlining cost. It merely (and solely) arranges to capture the entire (Core of the) source-code defnition, including if the function is recursive. No more and no less. Indeed, this was an inaccurate statement and I've removed it. > > We really just want GHC to behave like each use-site's module has a SPECIALISE pragma for each concrete type that the function is used at. > And that is exactly what INLINABLE does. Is that true? My understanding is that `INLINEABLE` will merely tell GHC to produce an unfolding; it won't ensure that GHC will use that unfolding to specialise use-sites. This is the goal here; we want to /ensure/ that GHC will specialise if at all possible. In the case of the `RECURSIVE_SPECIALISABLE` pragma this even means ensuring that polymorphic use-sites are also marked as `INLINEABLE`, to ensure that GHC can specialise the final concrete instantiation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:13:05 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.3f6720666e2d56fbf0d6e3bd4cf3b398@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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -52,1 +52,1 @@ - # Transitive specialisation + = Transitive specialisation = New description: Currently it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. We can only convince GHC to produce an unfolding for `aLibraryFunction` if we annotate it with an `INLINEABLE` pragma. While this is often effective, it doesn't really say what we mean: We don't never want GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} }}} The list of type binders after `SPECIALISE` is the set of binders which GHC would attempt to specialize. This pragma requests that GHC keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, the produced symbols could be declared as weak, allowing the linker to cull duplicated code when possible. = Transitive specialisation = The above `SPECIALISE` pragma still doesn't address the fragility of specialisation, however. Namely, consider, {{{#!hs module ALibrary where class AClass instance AClass Int aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} module AnotherLibrary where import ALibrary aFunction :: AClass a => a -> a aFunction x = {- ... -} aLibraryFunction x {- ... -} module AUser where import AnotherLibrary f = let x :: Int x = 5 in aFunction x }}} Here `aLibraryFunction` may depend crucially on specialisation; however, the polymorphic user `aFunction` has no way of knowing this and may be too large for GHC to produce an unfolding automatically. This ultimately means that GHC will be unable to specialise the eventual instantiation at `Int` in `AUser.f`. This will mean that the performance characteristics of `ALibrary` will be rather fragile. One (admittedly rather heavy) approach to solving this fragility is to inform GHC that `aLibraryFunction`'s polymorphic callsites should have unfoldings, ensuring that we are able to specialise the eventual monomorphic callsite, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE_RECURSIVE(a) forall a. aLibraryFunction :: a -> a #-} }}} Which would ensure that polymorphic use-sites of `aLibraryFunction` would themselves be marked as `SPECIALISE_RECURSIVE`, shielding users from the need to know about `aLibrarFunction`'s expectations of the simplifier. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:27:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:27:44 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.68f578888dfca56eb3a91440b2840925@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:28:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:28:26 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.d720701748ca386bdb9e9a48bb525361@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 simonpj): > My understanding is that INLINEABLE will merely tell GHC to produce an unfolding; it won't ensure that GHC will use that unfolding to specialise use-sites. Actually it ''does'' tell GHC to do exactly that. In other words, it already seeks to meet the goal. It may or not be working, of course. I did try #8774 with HEAD and it worked flawlessly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:32:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:32:44 -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.5d164da1c25ad28f161ca3744485c0c9@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:33:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:33:38 -0000 Subject: [GHC] #8523: blowup in space/time for type checking and object size for high arity tuples In-Reply-To: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> References: <045.5997c88b50a3268ad761aba3d7c6d625@haskell.org> Message-ID: <060.29f7cb1348ec76f1f6765f63b46a2120@haskell.org> #8523: blowup in space/time for type checking and object size for high arity tuples -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:35:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:35:43 -0000 Subject: [GHC] #7428: GHC compile times are seriously non-linear in program size In-Reply-To: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> References: <045.85e9797ebea1d66b1db34330e9f6ecce@haskell.org> Message-ID: <060.22ce49f8f4ead581279dbed981fa6f9e@haskell.org> #7428: GHC compile times are seriously non-linear in program size -------------------------------------+------------------------------------- Reporter: nudded | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:37:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:37:51 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.ce56c11e833466d3bc906effb115bc75@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 21:57:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 21:57:12 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.d8f3f872943261770279ee62b56032f6@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): @simonpj For the rest of us following along, how does one check this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:10:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:10:27 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.bfb273bbae66114d4b929d8634dcad2d@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): @erikd, plop the `Foo` and `Main` modules given in the ticket description in appropriately named files and compile `Main` with `ghc -ddump-simpl -dsuppress-idinfo -O`. You should see no `Foo a`s in the simplified core; instead you should see a nicely specialized definition of `plus` with all `Foo`s should be instantiated at `Int`. There should be no calls to the polymorphic `Foo.plus`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:14:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:14:38 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC Message-ID: <046.2df188325e9671498d5d7f855d704a92@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- At HIW 2016 it was suggested that this would greatly reduce the friction to contributing users guide fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:18:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:18:20 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.955f51f49b38cb7dfdb4960e33815a6c@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, right; I likely omitted the `pattern` keyword in my experiment. Thanks for catching this, Matthew. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:21:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:21:52 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.5a48efd3426c41be7e61f1a21db44202@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2528 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, I'll try to fix those cases up as well. Thanks, John! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:23:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:23:20 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.d77a60751ae8af2f16200a34f89c3fa8@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12550, #12447, #11786, #11549 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:23:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:23:49 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC In-Reply-To: <046.2df188325e9671498d5d7f855d704a92@haskell.org> References: <046.2df188325e9671498d5d7f855d704a92@haskell.org> Message-ID: <061.89a4b894a943e1151dc90be03fe67f3e@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:24:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:24:04 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.84a9932bf8e9c8d224d9b63ba29080a1@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Doing as suggested I see no `Foo a` but I do see the specialized `Foo (Qux Int)` with both ghc 8.0 or with 7.10. Don't have 7.8 installed on this machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 22:24:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 22:24:54 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.6651e598dc940796e836bd383fef047d@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Can you be more specific, Carter? In what way do things break? Let's handle this breakage on a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 23:28:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 23:28:27 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE Message-ID: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- This is a write-up of a rough idea that Andres Löw and me had at ICFP 2016 in order to address some Real World problems Andres noticed and that are currently hard to avoid. The goal is to give the user more control about expressions that the compiler would like to float out (or CSE), but the programmer knows better. Example (assume no list fusion exists): {{{ enum xs = zip [1..] xs }}} This leads to a horrible space leak, as GHC will float out `[1..]` to the top. Our idea is to have a magic function `nofloat :: a -> a` (magic in the same sense as `inline` and `lazy`) that the programmer would use here: {{{ enum xs = zip (nofloat [1..]) xs }}} With these effects: * Sub expressions are not floated out of a `nofloat`. * An expression of the form `nofloat e` would not be floated beyond the innermost enclosing lambda. * Two expressions of the form `nofloat e` would not be commoned up by CSE. This way, unwanted sharing is prevented. In contrast to a hypothetical `veryCheap` function, it does ''not'' mean that the compiler should float it into lambda (no unwanted duplication either). Two open questions (among many others, I am sure:) * Likely, rule matching should look through `nofloat`. At least in this example (and similar ones like `map (nofloat [1..])`, the rules in question will avoid the spaceleaks). * Possibly, nothing should be floated (inlined) ''into'' a `nofloat`. Rationale: Assume the library is changed so that {{{ [n..] = nofloat (realEnumFrom n) {-# INLINE [n..] #-} }}} Then `zip [fib 1000..]` would be rewritten by the inliner to `zip (let x = fib 1000 in (nofloat [x..]))`. Moving the `fib 1000` into the `nofloat` would change the behaviour in a possibly surprising way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 23:29:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 23:29:27 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.481d83da666594ef78a8c055d67ad76c@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Even with ghc 7.6, this seems to specialize correctly: {{{ cabal exec -- ghc -fforce-recomp -ddump-simpl -dsuppress-idinfo main.hs 2>&1 | grep 'Foo a' ... @ (Foo.Qux GHC.Types.Int) @ (Foo.Foo (Foo.Qux GHC.Types.Int)) (Foo.$WBar @ (Foo.Qux GHC.Types.Int)) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 24 23:42:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Sep 2016 23:42:39 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.b700629045e58baefcd2443b2e4a90e5@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 00:08:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 00:08:19 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.f3a1b1ea0b442d975a42c8bad4f2c10e@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): What is special about a data constructor that allows this, that a function (like, say, `flip`) does not have? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 00:38:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 00:38:46 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.e944408df991748182076f39a669325a@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by chak): * cc: chak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 01:32:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 01:32:48 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.c7add93bf1379013894ab5d2aeec271d@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 01:51:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 01:51:54 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.d3877ba9bd73926e86f30ac753494564@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 03:51:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 03:51:33 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.728a01780779e7c8900a65a9d4b5ca79@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 04:10:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 04:10:23 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy In-Reply-To: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> References: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> Message-ID: <059.d88e237744254e10321d012ae62581b5@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: SafeHaskell, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2546 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * owner: => erikd * differential: => phab:D2546 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 04:51:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 04:51:05 -0000 Subject: [GHC] #12126: Bad error messages for SPECIALIZE pragmas In-Reply-To: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> References: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> Message-ID: <061.3f68a93aeebbc9e2bb531a0b027fef2a@haskell.org> #12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: tmcgilchrist Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Specialize, | ErrorMessages, 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: | -------------------------------------+------------------------------------- Changes (by tmcgilchrist): * owner: => tmcgilchrist -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 05:57:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 05:57:47 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.e821d726e6417a60fe1823b50850011e@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): Replying to [comment:5 nomeata]: > What is special about a data constructor that allows this, that a function (like, say, `flip`) does not have? Let me try to answer that myself: Essentially, you are proposing a way of compressing the representation of Core, by omitting (type) arguments that can easily and in a syntax- directed manner be recovered. You are implying here the existence of a pair of functions {{{ compressArgs :: DataCon -> [Expr v] -> [Expr v] decompressArgs :: DataCon -> [Expr v] -> [Expr v] }}} that remove and recover implied arguments. For example `compressArgs "Left" [Bool,Int,True] = [Bool, True]`. We obviously want to following identity to hold: {{{ length args == dcArity dc ==> decompressArgs dc (compressArgs dc args) == args }}} What does `compressArgs` and `decompressArgs` need from `DataCon`? Two bits of information: * It’s type (`forall a b. a -> Either a b`) and * its arity (3, counting type arguments). Well, `compressArgs` does not need the arity, because it is just the length of the input list, if the application is saturated. But `decompressArgs` does (why? see example later). So really, we have a pair of functions {{{ compressArgs :: Type -> [Expr v] -> [Expr v] decompressArgs :: Type -> Arity -> [Expr v] -> [Expr v] }}} Here, we want {{{ decompressArgs ty (length args) (compressArgs ty args) == args }}} And with this I can see how the above proposal easily generalizes to functions: Have {{{ | Apps (Expr v) Arity [Expr v] -- NEW }}} Instead of {{{f `App` x `App` y `App` z}}} you can use `Apps f 3 (compressArgs (exprType f) [x,y,z])`. No information is lost (because of the above identity), but any redundant information can be removed by `compressArgs`. Why do we need to store the arity? Because `compressArgs` can produce the same compressed list for different input lists: {{{ compressArgs "forall a. a -> a" [Bool,True] == [True] compressArgs "forall a. a -> a" [Bool] == [Bool] compressArgs "forall a. a -> a" [Type, Bool] == [Bool] }}} I imagine getting rid of all (well, many more) of the redundant type applications throughout Core can be big win, so maybe this generalization should be considered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 06:11:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 06:11:26 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.be14f0197b9b30f39f357f85b69b0a87@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): Oh, and fun fact: It might be possible to remove `App` completely and replace it with a pattern synonym here: Due to `compressArgs ty [x] = [x]`, `Apps f 1 [e]` is equivalent to `App f e`. So this might not actually be a serious change to core, nor might it be increasing the number of constructors: Using a bidirectional smart constructor (which does optimizes the representation under the hood) this can hopefully be a completely transparent optimization of the representation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 09:22:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 09:22:57 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.612761f5193413c0def4c71eb8aa2839@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:22 erikd]: > @trommler Yes, that may well be worth while. OK, I am working on it and will report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 09:25:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 09:25:54 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.a9cbf1484e19737a0c337625cb37cc33@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => infoneeded Comment: In #12469 I wondered if qemu is doing something odd. @michelmno did you run your tests on bare hardware? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 12:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 12:35:41 -0000 Subject: [GHC] #12621: zeromq4-haskell fails on PowerPC 64-bit Message-ID: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> #12621: zeromq4-haskell fails on PowerPC 64-bit ---------------------------------+--------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------------- Building zeromq4-haskell from Hackage: {{{ [ 69s] [1 of 6] Compiling System.ZMQ4.Internal.Base ( dist/build/System/ZMQ4/Internal/Base.hs, dist/build/System/ZMQ4/Internal/Base.o ) [ 73s] /tmp/ghc1837_0/ghc_9.s: Assembler messages: [ 73s] [ 73s] /tmp/ghc1837_0/ghc_9.s:2619:0: [ 73s] Error: operand out of domain (2 is not a multiple of 4) [ 73s] [ 73s] : ghc: phase `Assembler' failed (exitcode = 1) }}} I think I know what's going on and I'll post a patch to Phabricator shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 12:48:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 12:48:16 -0000 Subject: [GHC] #12621: zeromq4-haskell fails on PowerPC 64-bit In-Reply-To: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> References: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> Message-ID: <062.ab2c49416695cd3b220d9c8b352bbcc6@haskell.org> #12621: zeromq4-haskell fails on PowerPC 64-bit ---------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2547 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * differential: => Phab:D2547 Comment: OK. Here is the patch. I am still building GHC to verify this really fixes the issue above but I am fairly confident it does :-) I'll set to patch once the build is done (takes a few hours). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 13:11:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 13:11:00 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.267679efc3860a06e19dd314c5cff68d@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 13:59:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 13:59:10 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.4796ba43752db99c9d8d4d02dd48b4ae@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 14:53:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 14:53:24 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.08618a534ef9532a2d6e8b58075937b8@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 carter): I'd like to chime in and agree that it would be a good design to reflect saturated function application and related info into a corresponding multi arg saturated app application form. I've some woke in progress type theory developments critically use having a built in motion of simultaneous arguments and results (a la types are calling conventions or sequent core), where the logical strength of what can be described needs a built in motion of simultaneous arguments. I presume / assume this multi arg app form is essentially a function application against an unboxed tuple? Right? One thing I'd like to point out is that a knock on effect of this change you may want to consider is having Unboxed tuples in arg and return positions act like pi and sigma telescopes respectively. If what I'm sketching out needs more clarity, I'm happy to do a clearer exposition on the wiki or the like If the meat of the ideas discussed / articulated are consistent with / facilitated by the details I'm hopefully articulating clearly, this would be a set of changes I would strongly support. In. Fact I could probably get support for putting work time into helping out on this change if need be. Partly because then certain ideas I would like to experimentally add to ghc would then be much much easier to add :) (The simultaneous arguments stuff makes embedding / supporting linear logical stuff in a clean way much nicer than previous efforts p) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 15:34:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 15:34:24 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries Message-ID: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: facundominguez 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 found what appears to be a regression following the merge of the new FloatOut based static pointers support. See github.com/mboes/bug-ptr-not- in-spt for a fully developed minimal example. It seems to be quite hard to trigger this bug: * I need to be using distributed-closure (not bare `StaticPtr`). * The static pointer needs to be defined in a separate module. * The static pointer must refer to a value with at least one polymorphic argument. * Compiler optimization level 1 needs to be turned on. At any rate, I wasn't able to trigger it without all conditions above being true. Initial investigations by facundominguez point to static pointer unpacking in distributed-closure as the culprit. Likely unpacked static pointers are no longer recognized as such by the FloatOut pass and therefore never floated to top-level, hence breaking a fundamental invariant about static pointers. This might explain why sometimes static pointers don't get added to the static pointer table (SPT), as in the above minimal example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 15:35:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 15:35:09 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.27f4e9b8fd9f4dfe3105fb2afd1bfb04@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundominguez 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: | -------------------------------------+------------------------------------- Description changed by mboes: @@ -2,2 +2,2 @@ - FloatOut based static pointers support. See github.com/mboes/bug-ptr-not- - in-spt for a fully developed minimal example. + FloatOut based static pointers support. See https://github.com/mboes/bug- + ptr-not-in-spt for a fully developed minimal example. New description: I found what appears to be a regression following the merge of the new FloatOut based static pointers support. See https://github.com/mboes/bug- ptr-not-in-spt for a fully developed minimal example. It seems to be quite hard to trigger this bug: * I need to be using distributed-closure (not bare `StaticPtr`). * The static pointer needs to be defined in a separate module. * The static pointer must refer to a value with at least one polymorphic argument. * Compiler optimization level 1 needs to be turned on. At any rate, I wasn't able to trigger it without all conditions above being true. Initial investigations by facundominguez point to static pointer unpacking in distributed-closure as the culprit. Likely unpacked static pointers are no longer recognized as such by the FloatOut pass and therefore never floated to top-level, hence breaking a fundamental invariant about static pointers. This might explain why sometimes static pointers don't get added to the static pointer table (SPT), as in the above minimal example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 16:48:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 16:48:07 -0000 Subject: [GHC] #12231: Eliminate redundant heap allocations/deallocations In-Reply-To: <047.2bb733afa458793dc239cf6b3bd50652@haskell.org> References: <047.2bb733afa458793dc239cf6b3bd50652@haskell.org> Message-ID: <062.4cb2098452d57731edf22e74735c4b84@haskell.org> #12231: Eliminate redundant heap allocations/deallocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 17:45:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 17:45:23 -0000 Subject: [GHC] #12621: zeromq4-haskell fails on PowerPC 64-bit In-Reply-To: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> References: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> Message-ID: <062.b528ca3c0a25c54d047cc8cdf57dc488@haskell.org> #12621: zeromq4-haskell fails on PowerPC 64-bit ---------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2547 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by trommler): * status: new => patch Comment: Build passes with this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 18:21:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 18:21:14 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.b3a50cad418d3a712a57cae19e03b4f2@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 heisenbug: @@ -19,1 +19,1 @@ - So here's another idea, which came up in converstion at ICFP'16: '''add a + So here's another idea, which came up in conversation at ICFP'16: '''add a @@ -97,1 +97,1 @@ - * For `ConApp "(:)" [e1, e2]`, the type arument is just `exprType e1`. + * For `ConApp "(:)" [e1, e2]`, the type argument is just `exprType e1`. @@ -108,1 +108,1 @@ - A simple once-and-for-all analyis on the `DataCon` will establish how to + A simple once-and-for-all analysis on the `DataCon` will establish how to @@ -124,1 +124,1 @@ - types a `TyConApp` is not required to be satureted, but we could review + types a `TyConApp` is not required to be saturated, but we could review @@ -142,1 +142,1 @@ - We'll only know if we try it. I estimiate that it would take less than a + We'll only know if we try it. I estimate that it would take less than a New description: A long-standing performance bug in GHC is its behaviour on nested tuples. * The poster-child case is #5642. * The problem is that when you have a nested tuple application, e.g. `((4,True),('c','d'))`, the size of the type arguments grows quadratically with the expression size. This bites badly in some approaches to generic programming, which use nested tuples heavily. * It's explained in detail in Section 2.3 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications]. The same paper describes a solution, a modification of System F called System IF. It's neat, and I did once implement in in GHC. But it was quite complicated; most of the time the win was not big; and I don't know how it'd interact with casts, coercions, and type dependency in the latest version of GHC's Core. So here's another idea, which came up in conversation at ICFP'16: '''add a staturated constructor application to Core'''. So Core looks like {{{ data Expr v = Var v | App (Expr v) (Expr v) ... | ConApp DataCon [Expr v] -- NEW }}} Now I hate the idea of adding a new constructor to Core; I often brag about how few constructors it has. But the idea is this: * A `ConApp` is always saturated; think of it as an uncurried application. * Every data constructor has a wrapper Id. For simple constructors like `(:)`, the wrapper is just a curried version: {{{ (:) = /\a. \(x:a). \(y:[a]). (:) [x,y] }}} where the "`(:) [x,y]`" is just my concrete syntax for a `ConApp` node. * We are used to having an intro and elim form for each type former. So for `(->)` the intro form is `\x.e` and the elim form is `(e1 e2)`. For a data type like `Maybe`, the elim form is `case`, but what's the intro form? `ConApp` of course. * A `ConApp` mentions the `DataCon` explicitly, rather than having it buried inside the `IdDetails` of an `Id`, which somehow seems more honest. The proximate reason for doing this in the first place is to allow us to omit type arguments. Consider `Just True`. Curently we represent this as {{{ Var "Just" `App` Type boolTy `App` Var "True" }}} But with `ConApp` we can say {{{ ConApp "Just" [ConApp "True" []] }}} because it's easy to figure out the `boolTy` type argument from the argument. (We don't really have strings there, but you get the idea.) Can we omit ''all'' the type arguments? No: we can omit only those that appear free in any of the argument types. That is usally all of them (including existentials) but not always. Consider: {{{ data (,) a b where (,):: forall a b. a -> b -> (a,b) data [] a where [] :: forall a. [a] (:) :: forall a. a -> [a] -> [a] data Either a b where Left :: forall a b. a -> Either a b Right :: forall a b. b -> Either a b data (:=:) a b where Refl :: forall a b. (a~b) -> :=: a b data Foo where MkFoo :: a -> (a -> Int) -> Foo }}} For all of these data constructors except `[]` (nil), `Left` and `Right` we can omit all the type arguments, because we can recover them by simple matching against the types of the arguments. A very concrete way to think about this is how to implement {{{ exprType :: Expr Id -> Type exprType (Var v) = varType v exprType (Lam b e) = mkFunTy (varType b) (exprType e) exprType (App f a) = funResultTy (exprType f) ... exprType (ConApp con args) = mkTyConApp (dataConTyCon con) ??? }}} We know that the result type of type of a `ConApp` will be `T t1 ..tn` where `T` is the parent type constructor of the `DataCon`. But what about the (universal) type args `???`? We can get them from the types of the arguments `map exprType args`: * For `ConApp "(:)" [e1, e2]`, the type argument is just `exprType e1`. * For `ConApp "(:=:)" [e]`", we expect `exprType e` to return a type looking like `TyConApp "~" [t1, t2]`. Then `t1` and `t2` are the types we want. So matching is required. * What about an application of `Left`?? We need to recover two type args, but `exprType e1` gives us only one. So we must retain the other one in the application: `ConApp "Left" [Type ty2, e1]`. Similarly for the empty list. A simple once-and-for-all analysis on the `DataCon` will establish how to do the matching, which type args to retain, etc. Tradeoffs: * Pro: We can eliminate almost all type args of almost all data constructors; and for nested tuples we can eliminate all of them. * Pro: it's elegant having the intro/elim duality. * Pro: in GHC we often ask "is this expression a saturated constructor application?" (see `exprIsConApp_maybe`) and `ConApp` makes it easier to answer that question. * Pro: we do exactly this in types: we have `AppTy` and `TyConApp`. (In types a `TyConApp` is not required to be saturated, but we could review that choice.) * Con: adding a constructor is a big deal. In lots of places we'd end up saying {{{ f (App e1 e2) = App (f e1) (f e2) f (ConApp c es) = ConApp c (map f es) }}} In the olden days GHC's `App` had multiple arguments and the continual need to work over the list was a bit tiresome. Still `ConApp` is very simple and uniform; quite often adding `map` won't be difficult; and it may well be that constructors need to be treated differently anyway. * Con: it's not a general solution to the type-argument problem. See #9198 for example. System IF is the only general solution I know, but it seems like too big a sledgehammer. We'll only know if we try it. I estimate that it would take less than a week to work this change through all of GHC. 90% of it is routine. Other possibly-relevant tickets are #8523, #7428, #9630. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 18:58:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 18:58:40 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.da5bfd51e63841a76a0fe1fac0d6296e@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): There are two different things that are orthogonal: * Enforcing saturated function calls (types are calling convention etc.), which this ticket is ''not'' about about. * Here, we want to avoid storing redundant types arguments. As this can be implemented with pattern synonyms, this should be a semantically transparent change. The former is also interesting (and there is some simplicity to be gained by having both, as the arity of a function application would be determined by the function’s type), but let’s keep them separate for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 19:09:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 19:09:13 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.75c3149fb077ca359b10cdb978c0d4de@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): Using a pattern synonynm works always; the problem is that the code should be generic in the binder, but then we have no way of knowing the binder’s type. But for what it’s worth: It seems to compile with this change: {{{ data Expr b = Var Id | Lit Literal -- | App (Expr b) (Arg b) | Apps (Expr b) Arity [Expr b] | Lam b (Expr b) | Let (Bind b) (Expr b) | Case (Expr b) b Type [Alt b] -- See #case_invariant# | Cast (Expr b) Coercion | Tick (Tickish Id) (Expr b) | Type Type | Coercion Coercion deriving Data unpackArgs :: Expr b -> Arity -> [Expr b] -> [Expr b] unpackArgs _ _ l = l -- do something smarter here packArgs :: Expr b -> [Expr b] -> [Expr b] packArgs _ l = l -- do something smarter here popArg :: Expr b -> Maybe (Expr b, Expr b) popArg (Apps e a xs) = case unpackArgs e a xs of [x] -> Just (e, x) xs -> Just (Apps e (a-1) (packArgs e (init xs)), last xs) popArg _ = Nothing pattern App e1 e2 <- (popArg -> Just (e1, e2)) where App e1 e2 | (f, args) <- collectArgs e1 = Apps f (length args +1) (packArgs f (args ++ [e2])) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 25 19:13:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 19:13:12 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.3ac345996c4e9eec723f57869f90babc@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @varosi I was able to test this myself, see https://phabricator.haskell.org/D2533#73976 If you'd still like to test it yourself as well I can provide a binary. But I'm confident it should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From matthew at wellquite.org Sun Sep 25 19:25:37 2016 From: matthew at wellquite.org (matthew) Date: RANDOM_Sun, 25 Sep 2016 22:25:37 +0300 Subject: you have to see that Message-ID: <00006c1eac89$965ca055$502b7084$@wellquite.org> Dear friend! I've just seen some amazing stuff, you'll definitely like it too, please take a look matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Sun Sep 25 20:55:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Sep 2016 20:55:30 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.ace69507d1e3a2148fee5d5ec07eb4fd@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundominguez 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 facundo.dominguez): Here's a smaller test case: {{{ -- A.hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE StaticPointers #-} module A where import Data.Typeable import GHC.StaticPtr g :: a -> Bool g _ = True data T a = T {-# UNPACK #-} !(StaticPtr a) sg :: Typeable a => T (a -> Bool) sg = T (static g) }}} {{{ -- Main.hs {-# LANGUAGE StaticPointers #-} {-# LANGUAGE LambdaCase #-} import GHC.StaticPtr import A g = True main :: IO () main = do let T s = sg :: T (Bool -> Bool) lookupKey s >>= \f -> print (f True) lookupKey :: StaticPtr a -> IO a lookupKey p = unsafeLookupStaticPtr (staticKey p) >>= \case Just p -> return $ deRefStaticPtr p Nothing -> error $ "couldn't find " ++ show (staticPtrInfo p) }}} Build with {{{ $ ghc -O Main.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main Main: couldn't find StaticPtrInfo {spInfoUnitId = "main", spInfoModuleName = "A", spInfoSrcLoc = (14,16)} CallStack (from HasCallStack): error, called at Main.hs:17:14 in main:Main }}} Using `-dverbose-core2core` one can see that the FloatOut pass does the right thing (i.e. moving the static form to the top-level in Main.hs), {{{ lvl_sG5 :: forall a_aEy. StaticPtr (a_aEy -> Bool) lvl_sG5 = \ (@ a_aEy) -> GHC.StaticPtr.StaticPtr @ (a_aEy -> Bool) 13520098690657238824## 6110703080284699228## lvl_sG4 (g @ a_aEy) }}} but the simplifier later rewrites the top-level binding to use the T constructor instead: {{{ lvl_sG7 :: forall a_aEy. T (a_aEy -> Bool) lvl_sG7 = \ (@ a_aEy) -> A.T @ (a_aEy -> Bool) 13520098690657238824## 6110703080284699228## lvl_sGn (g @ a_aEy) }}} Thus, when the SPT is built, the StaticPtr constructor is not found and the entry is never inserted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 01:15:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 01:15:09 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.33a58865e346e4c89090f73cbc63d781@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- 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: 5144 | 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 Mon Sep 26 01:15:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 01:15:55 -0000 Subject: [GHC] #11461: Allow pattern synonyms to be bundled with type classes? In-Reply-To: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> References: <049.1fada904b95006c78906f4dc6d83e704@haskell.org> Message-ID: <064.544f4a06efe24c6d4698c9d3699b45b0@haskell.org> #11461: Allow pattern synonyms to be bundled with type classes? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 01:16:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 01:16:54 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.c0d0accac5e9a263df136805019ed1b8@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 02:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 02:29:58 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates Message-ID: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamarii Type: task | Status: new Priority: highest | 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 submodule updates appear to break Harbormaster builds. This is bad. Fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 02:37:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 02:37:07 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.890e152af9d707197d1088d15e79d79b@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): I guess the solution to that is adding a type class, such as {{{ class CompressArgs b where unpackArgs :: Expr b -> Arity -> [Expr b] -> [Expr b] unpackArgs _ _ l = l packArgs :: Expr b -> [Expr b] -> [Expr b] packArgs _ l = l }}} or alternatively {{{ class HasType a where hasType :: Expr a -> Type }}} and adding instances for the two type of binders we have (`Var` and `TaggedBndr t`). With a few constraints added in various places (four modules only), this also compiles. It seems the remaining bit is to solve the staging issue: The instance should live in `CoreSyn`, but requires `expType` in `CoreUtils`. If that can be solved, the feature could be added quite painlessly. Then, in all places where the expression is traversed, one can any time make the decision to work on `Apps` directly, instead of `App`. I expect we’d get the memory performance boost we want (exciting!), but I also expect that this encoding/decoding in every traversal will cost runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 05:48:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 05:48:19 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.d565deb8adda2c83820ba0d5fab74285@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 07:16:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 07:16:16 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup Message-ID: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A few months ago we reverted a cleanup (cac3fb06f4b282eee21159c364c4d08e8fdedce9) to `PosixSource.h` due to apparent [[http://haskell.inf.elte.hu/builders/solaris- amd64-head/573/10.html|breakage]] on Solaris. We need to sort this out since the cleanup also apparently fixes things on AArch64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 07:16:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 07:16:40 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.46da843c340baa19d7f83808e20261ae@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: kgardas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 07:16:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 07:16:57 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.0431276fba9379a3b5f75e4d30ab7492@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: angermann (removed) * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 07:22:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 07:22:02 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.340ee4c94a9acd12f813dcd41e621f15@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Potential build log with error message: http://haskell.inf.elte.hu/builders/solaris-amd64-head/573/10.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 07:22:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 07:22:47 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.2b55a2734671b81766b2edb28200e0e9@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Potentil notes wrt solaris: https://docs.oracle.com/cd/E53394_01/html/E54776/standards-5.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 08:14:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 08:14:38 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.c948c696cf2e24866ae606601a8e2cb5@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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): Let's not go overboard here! This ticket is ''only'' about treating '''saturated''' applications of '''data constructors''' specially. There are two more ambitious possible * Try to suppress more type arguments, for situations other than saturated data constructors. If you are interested in that, please read [https://www.microsoft.com/en-us/research/publication/scrap-your-type- applications/ Scrap your type applications]. By all means come up with a better scheme, but that paper describes the best one I know. * Introduce uncurried application as a Core primitive (and eliminate `App`). For that we'd want uncurried lambda as well (the intro form). Please read [https://www.microsoft.com/en-us/research/publication/types- are-calling-conventions/ Types are calling conventions]. I talked with Stephanie and Joachim about this at ICFP, and I think Joachim is going to follow it up. It too involves complications (notably abstraction must be over a telescope), and we had an alternative idea with "computation types". More on that anon, doubtless. By all means start new tickets to discuss these generalisations. But ''this'' ticket is just about the intro-form that is dual to `case`, namely saturated constructor application. If we discuss the (much more ambitious) generalisations here, the payload of this ticket will get buried. (One reason for NOT adopting `ConApp` is that it might ultimately be subsumed by the more general cases. But I'm not holding my breath.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 08:33:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 08:33:36 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.fe655d2165b7b7626edc379b3868c563@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 cactus): * cc: cactus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 09:00:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 09:00:26 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.163d295b636108788bdafee5de489148@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): As @kgardas provided via email: the core of the issue is this: > Oracle's Solaris 11 supports max: > > #define _POSIX_C_SOURCE 200112L > #define _XOPEN_SOURCE 600 how the feature_tests.h likely looks can be found at https://raw.githubusercontent.com/illumos/illumos- gate/7c478bd95313f5f23a4c958a745db2134aa03244/usr/src/uts/common/sys/feature_tests.h I'm wondering if we can get away without platform ifdefs :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 09:49:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 09:49:51 -0000 Subject: [GHC] #12625: Bad error message for flags with required but missing arguments Message-ID: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> #12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | 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 -I ghc: unrecognised flag: -I did you mean one of: -I -F -v Usage: For basic information, try the `--help' option. }}} Which is confusing (Unrecognized `-I`. Did you mean `-I`?), and not informative (No mention of the missing argument) I expect something like "missing argument for `-I`", or a basic usage info on `-I` instead. It looks similar to #9776 to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 10:54:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 10:54:35 -0000 Subject: [GHC] #12597: -Wmissing-signatures uses forall even when invalid in source In-Reply-To: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> References: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> Message-ID: <061.0be5dc9bac0185eefabc10c2f5ec31b3@haskell.org> #12597: -Wmissing-signatures uses forall even when invalid in source -------------------------------------+------------------------------------- Reporter: nomeata | 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:"796f0f2ad7eefd1c9af5a7ef9bf56848067e85b1/ghc" 796f0f2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="796f0f2ad7eefd1c9af5a7ef9bf56848067e85b1" Print foralls in user format This fixes Trac #12597: in RnNames.warnMissingSignatures, use pprSigmaType not pprType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 10:56:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 10:56:36 -0000 Subject: [GHC] #12597: -Wmissing-signatures uses forall even when invalid in source In-Reply-To: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> References: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> Message-ID: <061.4298ef7838cd4d5d7bde39cdb1e8812c@haskell.org> #12597: -Wmissing-signatures uses forall even when invalid in source -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge 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: | rename/should_compile/T12597 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => rename/should_compile/T12597 Comment: Might be worth merging. Cosmetic but useful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 11:42:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 11:42:01 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.5e8ed9334dc207d40dceb7155508bfd4@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Great! But if you create a binary for me then I may test on 88 logical processors machine for double check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 11:52:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 11:52:48 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.56f1ec0ab19b2ae5e7a2b58218949d92@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 carter): I exactly want those unboxed tuple telescopes :) Fair enough I'll see if I can put together an exposition that cleans up tacc and articulates some changes which make it nicer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 12:00:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 12:00:57 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.dbe0d8e31ec1e49b263117bdae63b83c@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez 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 facundo.dominguez): * owner: facundominguez => facundo.dominguez * cc: facundominguez (removed) * cc: facundo.dominguez, simonpj (added) Comment: One simple solution could be to redefine `StaticPtr` to something like {{{ data StaticPtr a = StaticPtr {-# NOUNPACK #-} !(StaticPtr' a) data StaticPtr' a = StaticPtr' Word# Word# StaticPtrInfo a }}} This would yield the `StaticPtr` data constructor from being eliminated due to unboxing. Another solution would be to tell the compiler never to unbox a field of type `StaticPtr`. Not sure how easy this would be. simonpj? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 13:17:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 13:17:39 -0000 Subject: [GHC] #12626: Remove redundant type applications in Core Message-ID: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> #12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- This ticket is a fork for #12618, which proposes to add saturated data constructor applications to Core with the purpose of omitting redundant type applications (think `(,)`), and explores generalizing the idea to any application. Below are my comments to that ticket, which I delete there, to make it less noisy (I got excited on the travel back from ICFP and spammed it too much). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 13:19:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 13:19:52 -0000 Subject: [GHC] #12626: Remove redundant type applications in Core In-Reply-To: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> References: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> Message-ID: <061.831f071bd821a185af8bd7da4df6b7c8@haskell.org> #12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | 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 nomeata): Replying to [comment:5 nomeata]: > What is special about a data constructor that allows this, that a function (like, say, `flip`) does not have? Let me try to answer that myself: Essentially, you are proposing a way of compressing the representation of Core, by omitting (type) arguments that can easily and in a syntax- directed manner be recovered. You are implying here the existence of a pair of functions {{{ compressArgs :: DataCon -> [Expr v] -> [Expr v] decompressArgs :: DataCon -> [Expr v] -> [Expr v] }}} that remove and recover implied arguments. For example `compressArgs "Left" [Bool,Int,True] = [Bool, True]`. We obviously want to following identity to hold: {{{ length args == dcArity dc ==> decompressArgs dc (compressArgs dc args) == args }}} What does `compressArgs` and `decompressArgs` need from `DataCon`? Two bits of information: * It’s type (`forall a b. a -> Either a b`) and * its arity (3, counting type arguments). Well, `compressArgs` does not need the arity, because it is just the length of the input list, if the application is saturated. But `decompressArgs` does (why? see example later). So really, we have a pair of functions {{{ compressArgs :: Type -> [Expr v] -> [Expr v] decompressArgs :: Type -> Arity -> [Expr v] -> [Expr v] }}} Here, we want {{{ decompressArgs ty (length args) (compressArgs ty args) == args }}} And with this I can see how the above proposal easily generalizes to functions: Have {{{ | Apps (Expr v) Arity [Expr v] -- NEW }}} Instead of {{{f `App` x `App` y `App` z}}} you can use `Apps f 3 (compressArgs (exprType f) [x,y,z])`. No information is lost (because of the above identity), but any redundant information can be removed by `compressArgs`. Why do we need to store the arity? Because `compressArgs` can produce the same compressed list for different input lists: {{{ compressArgs "forall a. a -> a" [Bool,True] == [True] compressArgs "forall a. a -> a" [Bool] == [Bool] compressArgs "forall a. a -> a" [Type, Bool] == [Bool] }}} I imagine getting rid of all (well, many more) of the redundant type applications throughout Core can be big win, so maybe this generalization should be considered. Oh, and fun fact: It might be possible to remove `App` completely and replace it with a pattern synonym here: Due to `compressArgs ty [x] = [x]`, `Apps f 1 [e]` is equivalent to `App f e`. So this might not actually be a serious change to core, nor might it be increasing the number of constructors: Using a bidirectional smart constructor (which does optimizes the representation under the hood) this can hopefully be a completely transparent optimization of the representation. Using a pattern synonynm works almost; the problem is that the code should be generic in the binder, but then we have no way of knowing the binder’s type. But for what it’s worth: It seems to compile with this change: {{{ data Expr b = Var Id | Lit Literal -- | App (Expr b) (Arg b) | Apps (Expr b) Arity [Expr b] | Lam b (Expr b) | Let (Bind b) (Expr b) | Case (Expr b) b Type [Alt b] -- See #case_invariant# | Cast (Expr b) Coercion | Tick (Tickish Id) (Expr b) | Type Type | Coercion Coercion deriving Data unpackArgs :: Expr b -> Arity -> [Expr b] -> [Expr b] unpackArgs _ _ l = l -- do something smarter here packArgs :: Expr b -> [Expr b] -> [Expr b] packArgs _ l = l -- do something smarter here popArg :: Expr b -> Maybe (Expr b, Expr b) popArg (Apps e a xs) = case unpackArgs e a xs of [x] -> Just (e, x) xs -> Just (Apps e (a-1) (packArgs e (init xs)), last xs) popArg _ = Nothing pattern App e1 e2 <- (popArg -> Just (e1, e2)) where App e1 e2 | (f, args) <- collectArgs e1 = Apps f (length args +1) (packArgs f (args ++ [e2])) }}} I guess the solution to that is adding a type class, such as {{{ class CompressArgs b where unpackArgs :: Expr b -> Arity -> [Expr b] -> [Expr b] unpackArgs _ _ l = l packArgs :: Expr b -> [Expr b] -> [Expr b] packArgs _ l = l }}} or alternatively {{{ class HasType a where hasType :: Expr a -> Type }}} and adding instances for the two type of binders we have (`Var` and `TaggedBndr t`). With a few constraints added in various places (four modules only), this also compiles. It seems the remaining bit is to solve the staging issue: The instance should live in `CoreSyn`, but requires `expType` in `CoreUtils`. If that can be solved, the feature could be added quite painlessly. Then, in all places where the expression is traversed, one can any time make the decision to work on `Apps` directly, instead of `App`. I expect we’d get the memory performance boost we want (exciting!), but I also expect that this encoding/decoding in every traversal will cost runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 13:22:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 13:22:44 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.5b93a3d8711c97058db0555e3d0d98c9@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 nomeata): I guess I did get a bit overly excited, on the way back from ICFP. I moved all my comments about generalizing this to arbitrary applications in an transparent way to #12626. But I still wonder what’s so special about data constructors, and why whatever works for data constructors does not work in general. I skimmed the paper, and will read it more carefully again now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 13:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 13:35:41 -0000 Subject: [GHC] #12626: Remove redundant type applications in Core In-Reply-To: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> References: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> Message-ID: <061.10a5415daf6a5960be3f1e1e20b8d6e0@haskell.org> #12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | 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 nomeata): How is this idea different from the System IF? * Conceptually, I am not trying to change core, but rather change the in- memory representation of Core. All the theory and reasoning about Core is untouched! Using a pattern synonym makes that very explicit. (Some operations, e.g. simple traversals, will be happy to work on the raw representation, but that’s just an optimization of the code). * System IF tries to handle one non-type-argument at a time, while my code always compresses a whole chain of arguments: ||=Core=||`(,) @Bool @Int True 1`||`(,) @Bool @Int True`|| ||=SystemIF=||`((,) True) 1`||`((,) True) @Int`|| ||=This idea=||`(,) [True, 1]`||`(,) [@Int, True]`|| -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 14:35:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 14:35:33 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.1f5eb6f1cbc8d7ef14e6cd2a66017d10@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kgardas): I see only two solution -- *if* there is a really need to increase constants to XPG7. 1. platform related ifdefs, probably #ifdef solaris. or 2. abandon support for oracle solaris for HEAD and following releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 15:09:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 15:09:27 -0000 Subject: [GHC] #12597: -Wmissing-signatures uses forall even when invalid in source In-Reply-To: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> References: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> Message-ID: <061.af82446b805cfde3fcb5842f9199a23a@haskell.org> #12597: -Wmissing-signatures uses forall even when invalid in source -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge 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: | rename/should_compile/T12597 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the quick fix! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 16:10:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 16:10:40 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.48820ddb3d21542ed62fdc286a1c813f@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: Gershom thinks that shipping GHC 8.0.2 that does not work on OSX's latest release would be worse than delaying 8.0.2. So I'm making priority = highest. (Suggestion only of course.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 17:05:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 17:05:42 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.3548e94028842016daa7f86ba9da3ec4@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So I think there are three places in total where RPATHs are chosen. * In GHC, when building a temporary shared library to load the current package for ghci or TH. * In GHC, when doing the final link of a dynamic executable or library using `-dynload system` (the default) * In Cabal, when doing the final link of a dynamic executable or library (invoking GHC with `-dynload deploy` and explicit `-optl` options to set the RPATH) The first issue is essentially local, since the temporary shared library is needed just once. But the other two issues are not, and changing the way we set up the RPATHs and install names has side effects, for example in the case darchon mentioned above, or for someone who deploys their application with all the Haskell libraries in a single directory. So it's a bit of a sticky situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 17:39:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 17:39:48 -0000 Subject: [GHC] #12626: Remove redundant type applications in Core In-Reply-To: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> References: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> Message-ID: <061.b3077d037840400d71eb8552128e9263@haskell.org> #12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | 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 nomeata): Proof of concept in branch `wip/T12626`. It builds, and the resulting ghc2 runs. Test suite does not go through yet, so it might not be bug free, but I think the code explains the idea. Better to look at the commits individually, as one commit moves `exprType` to `coreSyn`, which is of course not essential to understanding the idea here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 18:36:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 18:36:03 -0000 Subject: [GHC] #12627: build sytem feature request: persist warnings Message-ID: <046.0275c0a9f1aefea01a04416cf6f40736@haskell.org> #12627: build sytem feature request: persist warnings -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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 often have this pattern: I hack on GHC in `devel2` mode, introducing a few changes that cause warnings all over the place (usually related to imports). I ignore them while I work on the feature. Now I want to clean the warnings up. I basically only have one option: Switch the settings to make warnings errors, make clean, re-build everything, see where it aborts, fix it, restart the build. This is annoying. I would prefer if the build system (in any more) would keep, for every file, the output of the compiler on disc, e.g. with a suffix of `.comp- out` or something. This way, after a complete build, even without `-Werror`, I can simply run `cat **/*.comp-out` (or whatever suffix is suitable), fix all these error in one go, and be done with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 18:58:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 18:58:37 -0000 Subject: [GHC] #12627: build sytem feature request: persist warnings In-Reply-To: <046.0275c0a9f1aefea01a04416cf6f40736@haskell.org> References: <046.0275c0a9f1aefea01a04416cf6f40736@haskell.org> Message-ID: <061.868746d70c8a18e9e4ca67726c487583@haskell.org> #12627: build sytem feature request: persist warnings -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Doesn't directly solve your problem, but https://github.com/ezyang/ghc- shake logs warnings to persistent files so that you can view them later. They get stored in `*.log` files, so you can print them all out with `find dist -name "*.log" -exec cat {} \;` or something like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 19:04:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 19:04:38 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.1bc4eff8fd27dc75eed2d6c6412cf493@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 lukemaurer): We went back and forth with something like this in Sequent Core, where having the dual of Case was nice. One downside hasn't been mentioned, though: We'll need to use smart constructors more consistently, or otherwise not be able to count on ''all'' saturated constructor applications to use `ConApp`. Currently there's `mkCoreApp` and `mkCoreApps`, but those are only necessary when the let/app invariant must be enforced; IIRC, lots of places where let/app is known to hold just use fold `App` over the arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 19:45:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 19:45:31 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.a43bd3da8d74adfd85ddad128001fdd1@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @varosi that's no problem, I created a dist for you https://1drv.ms/u/s !AuQz_u-9HaJPmZMCN3vs3xy1dfppmg file should be ghc-8.1.20160926-x86_64 -unknown-mingw32.tar.xz with an md5 of `4ecc54b2833eed212ec06550b604bb56` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 20:11:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 20:11:38 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.f492fc36a0ec88ade68b895bb46bdd5c@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I am okay with a platform-specific `#ifdef` assuming that it is precise (affecting only Oracle Solaris) and we have a build bot to ensure it doesn't break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 20:45:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 20:45:59 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.f334891edc3bac7aedc86889a6bc6f11@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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 goldfire): simonpj says: > A simple once-and-for-all analysis on the DataCon will establish how to do the matching, which type args to retain, etc. So a `DataCon` will have this info stored in it? It might be non-trivial! For example: {{{ data T a where MkT :: F a -> T a }}} If `F` is not injective, we would need to store the choice for `a`. Even if it is injective, it may be more convenient to store the choice for `a`. And then there are examples like {{{ data T2 a where MkT2 :: Maybe (Either Bool a -> a) -> T2 a }}} where the relationship between the constructor field's type and the choice for `a` is non-trivial. However, perhaps a use of `tcMatchTy` or one of its friends when constructing the `DataCon` is enough to sort this out. If we successfully do this for data constructors, it should not be hard to do the same for poly-kinded type constructors. I'm specifically thinking about the redundant `RuntimeRep` arguments to unboxed-tuple type constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 20:57:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 20:57:07 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.89ba02684cd677ecf10dfbfb67ba4190@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): I'm not sure how the triage system works these days. Should this be removed from infoneeded to show up in the standard lists at this point of tickets with status new? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:10:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:10:42 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.3cde1d7a5fd7a60f6ef7fab35862044e@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"c36904d66f30d4386a231ce365a056962a881767/ghc" c36904d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c36904d66f30d4386a231ce365a056962a881767" Fix layout of MultiWayIf expressions (#10807) With this patch we stop generating virtual semicolons in MultiWayIf guards. Fixes #10807. Test Plan: Reviewers: simonmar, austin, bgamari Reviewed By: simonmar Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2524 GHC Trac Issues: #10807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:12:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:12:34 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.aeccf175d9eccc138cb94652ab04ebe8@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:24:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:24:27 -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.d3233c3c1b20262b1a9f5d6c847d7c52@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm still unaware of a concrete example that my comment:13 and comment:15 do not handle. During the conversation with Simon and Stephanie at ICFP, we indeed agreed on the "separator" solution. Easy to implement, explain, and understand. Perhaps slightly annoying, though. However, this conversation took place without an ability to get on Trac due to local connectivity challenges, and I took Simon's word about the existence of such an example. But now I can't find one. Perhaps comment:13 and comment:15 are too baroque to implement (I claim: it's no worse than lots of other stuff!) and to explain to/understand by users (this bit may be an effective argument against my idea). But I'd like us to understand why we don't do this idea before we give up and just choose the simple (but perhaps annoying) solution. Note that comment:13/comment:15 handle the example in comment:19. Because `FieldType`'s type depends on `FieldCount`'s, then `FieldType`'s equations depend on `FieldCount`'s equations, too. Thus the dependency would be caught and the compiler can process the instances in the correct order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:26:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:26:54 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types In-Reply-To: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> References: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> Message-ID: <066.d3e5cea2f1df7147fe4f9b9173c3b458@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is ''much'' simpler than #12088. It's loosely related, but solving #12088 will not help nor hurt our ability to solve this. Yes, this should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:30:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:30:05 -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.389171e93e5129f8bf353b43b2df1c2f@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by richardfung): There has been some discussion on the code review: https://phabricator.haskell.org/D2485 To summarize, turning off all inlining with -O0 and always reading in interface pragmas causes a performance regression. Simon Marlow has suggested two other solutions: "Lazily load the pragma info, so that it doesn't cost anything if we don't use it. The simplifier should use -fignore-interface-pragmas to decide whether to use the pragma info from external Ids or not. Predict whether we'll need the pragma info by determining whether *any* module in the current set will be compiled with optimisation turned on. This info is available after we've done the downsweep in the compilation manager. This approach doesn't really work in general because a user of the GHC API might load more modules later with -O and we can't predict that, but it fixes the common case." I would rather do things the right way and thus try my hand at the first solution. Is this something that is still suitable for a newcomer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:43:23 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.8ecf548bcc1f91cb9372a01db7a5cfac@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => new Comment: Indeed it should be in `new`. Thanks for pointing this out, Gershom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 21:45:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 21:45:24 -0000 Subject: [GHC] #12616: type synonyms confuse generalized newtype deriving role checking In-Reply-To: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> References: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> Message-ID: <065.db1accc937e61476d038f33efc28a3ee@haskell.org> #12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: generalized | newtype deriving roles rankntypes 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 Comment: I think this issue is just an infelicity in the code generator for GND. Should be easy to fix. NB: There are no higher-rank types in the example. Just a fancy type synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 26 23:48:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Sep 2016 23:48:37 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int Message-ID: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Keywords: llvm cpp | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the user guide (http://ghc.readthedocs.io/en/8.0.1/phases.html#index-8) {{{ __GLASGOW_HASKELL_LLVM__ Only defined when -fllvm is specified. When GHC is using version x.y.z of LLVM, the value of __GLASGOW_HASKELL_LLVM__ is the integer ⟨xy⟩. }}} This is not the case, though, due to 29310b622801733e1b29a9a61988406872db13ca which changes {{{figureLlvmVersion :: DynFlags -> IO (Maybe Int)}}} into {{{figureLlvmVersion :: DynFlags -> IO (Maybe (Int, Int))}}}, and the driver just {{{show}}}ing the result (https://github.com/ghc/ghc/blob/29310b622801733e1b29a9a61988406872db13ca/compiler/main/DriverPipeline.hs#L2084) As a result, the macro value which used to be a numeric value is now something like {{{(3, 7)}}}. I'm now using a work-around (https://github.com/NicolasT/reedsolomon/commit/9d25ad6a26a29c90b82daacbf406367b8b274c0b), but ''or'' the 'tuple value' should become 'official API', ''or'' this is a regression to be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 01:39:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 01:39:26 -0000 Subject: [GHC] #12629: Worse performance with -O1 or -O2 due to GC cost Message-ID: <043.2295a1b82be01c82bad27d01787a0edd@haskell.org> #12629: Worse performance with -O1 or -O2 due to GC cost -------------------------------------+------------------------------------- Reporter: onex | 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 g a = replicate (n-a) (a+1) f [x] = [[x]] f list = [ a:b | a <- list, b <- f $ g a] main = do print $ length $ f [1..12] }}} The function ''g'' can be replaced by any ''a -> [a]'' function. Without optimization: {{{ 94,885,791,728 bytes allocated in the heap 280,050,384 bytes copied during GC 62,432 bytes maximum residency (18 sample(s)) 27,144 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 182071 colls, 0 par 0.437s 0.442s 0.0000s 0.0004s Gen 1 18 colls, 0 par 0.000s 0.002s 0.0001s 0.0004s INIT time 0.000s ( 0.002s elapsed) MUT time 14.992s ( 15.188s elapsed) GC time 0.437s ( 0.444s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 15.428s ( 15.634s elapsed) %GC time 2.8% (2.8% elapsed) Alloc rate 6,329,223,264 bytes per MUT second Productivity 97.2% of total user, 95.9% of total elapsed }}} With -O2: {{{ 86,218,852,592 bytes allocated in the heap 13,323,597,456 bytes copied during GC 62,712 bytes maximum residency (12895 sample(s)) 47,104 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 154129 colls, 0 par 6.724s 6.685s 0.0000s 0.0015s Gen 1 12895 colls, 0 par 0.484s 0.479s 0.0000s 0.0004s INIT time 0.000s ( 0.001s elapsed) MUT time 12.714s ( 13.002s elapsed) GC time 7.207s ( 7.164s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 19.921s ( 20.167s elapsed) %GC time 36.2% (35.5% elapsed) Alloc rate 6,781,366,989 bytes per MUT second Productivity 63.8% of total user, 63.0% of total elapsed }}} System:Windows/macOS Compiler:8.0.1/7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 01:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 01:42:44 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.bd0edbb8f9b1aa7595e6dff79a9af294@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp 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 nicolast): Working on a patch to restore old behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 02:35:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 02:35:44 -0000 Subject: [GHC] #12629: Worse performance with -O1 or -O2 due to GC cost In-Reply-To: <043.2295a1b82be01c82bad27d01787a0edd@haskell.org> References: <043.2295a1b82be01c82bad27d01787a0edd@haskell.org> Message-ID: <058.46fb0ff882d3ba21cdef1353e94b4a68@haskell.org> #12629: Worse performance with -O1 or -O2 due to GC cost -------------------------------------+------------------------------------- Reporter: onex | 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 onex: @@ -2,0 +2,2 @@ + n = 11 + @@ -8,1 +10,1 @@ - print $ length $ f [1..12] + print $ length $ f [1..n] New description: {{{#!hs n = 11 g a = replicate (n-a) (a+1) f [x] = [[x]] f list = [ a:b | a <- list, b <- f $ g a] main = do print $ length $ f [1..n] }}} The function ''g'' can be replaced by any ''a -> [a]'' function. Without optimization: {{{ 94,885,791,728 bytes allocated in the heap 280,050,384 bytes copied during GC 62,432 bytes maximum residency (18 sample(s)) 27,144 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 182071 colls, 0 par 0.437s 0.442s 0.0000s 0.0004s Gen 1 18 colls, 0 par 0.000s 0.002s 0.0001s 0.0004s INIT time 0.000s ( 0.002s elapsed) MUT time 14.992s ( 15.188s elapsed) GC time 0.437s ( 0.444s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 15.428s ( 15.634s elapsed) %GC time 2.8% (2.8% elapsed) Alloc rate 6,329,223,264 bytes per MUT second Productivity 97.2% of total user, 95.9% of total elapsed }}} With -O2: {{{ 86,218,852,592 bytes allocated in the heap 13,323,597,456 bytes copied during GC 62,712 bytes maximum residency (12895 sample(s)) 47,104 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 154129 colls, 0 par 6.724s 6.685s 0.0000s 0.0015s Gen 1 12895 colls, 0 par 0.484s 0.479s 0.0000s 0.0004s INIT time 0.000s ( 0.001s elapsed) MUT time 12.714s ( 13.002s elapsed) GC time 7.207s ( 7.164s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 19.921s ( 20.167s elapsed) %GC time 36.2% (35.5% elapsed) Alloc rate 6,781,366,989 bytes per MUT second Productivity 63.8% of total user, 63.0% of total elapsed }}} System:Windows/macOS Compiler:8.0.1/7.10.3 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 02:37:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 02:37:51 -0000 Subject: [GHC] #12629: Worse performance with -O1 or -O2 due to GC cost In-Reply-To: <043.2295a1b82be01c82bad27d01787a0edd@haskell.org> References: <043.2295a1b82be01c82bad27d01787a0edd@haskell.org> Message-ID: <058.9db70ee55589a9ea0a4315314bbe396f@haskell.org> #12629: Worse performance with -O1 or -O2 due to GC cost -------------------------------------+------------------------------------- Reporter: onex | 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 onex: @@ -2,1 +2,1 @@ - n = 11 + n = 12 New description: {{{#!hs n = 12 g a = replicate (n-a) (a+1) f [x] = [[x]] f list = [ a:b | a <- list, b <- f $ g a] main = do print $ length $ f [1..n] }}} The function ''g'' can be replaced by any ''a -> [a]'' function. Without optimization: {{{ 94,885,791,728 bytes allocated in the heap 280,050,384 bytes copied during GC 62,432 bytes maximum residency (18 sample(s)) 27,144 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 182071 colls, 0 par 0.437s 0.442s 0.0000s 0.0004s Gen 1 18 colls, 0 par 0.000s 0.002s 0.0001s 0.0004s INIT time 0.000s ( 0.002s elapsed) MUT time 14.992s ( 15.188s elapsed) GC time 0.437s ( 0.444s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 15.428s ( 15.634s elapsed) %GC time 2.8% (2.8% elapsed) Alloc rate 6,329,223,264 bytes per MUT second Productivity 97.2% of total user, 95.9% of total elapsed }}} With -O2: {{{ 86,218,852,592 bytes allocated in the heap 13,323,597,456 bytes copied during GC 62,712 bytes maximum residency (12895 sample(s)) 47,104 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 154129 colls, 0 par 6.724s 6.685s 0.0000s 0.0015s Gen 1 12895 colls, 0 par 0.484s 0.479s 0.0000s 0.0004s INIT time 0.000s ( 0.001s elapsed) MUT time 12.714s ( 13.002s elapsed) GC time 7.207s ( 7.164s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 19.921s ( 20.167s elapsed) %GC time 36.2% (35.5% elapsed) Alloc rate 6,781,366,989 bytes per MUT second Productivity 63.8% of total user, 63.0% of total elapsed }}} System:Windows/macOS Compiler:8.0.1/7.10.3 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 04:49:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 04:49:33 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 Message-ID: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | 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 Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to reproduce random ghc panic we have in our codebase with ghc8 so I decided to compile ghc with debug enabled. Source file: ghc-8.0.1-src.tar.xz build.mk changes: {{{ BuildFlavour = devel2 GhcStage1HcOpts = -DDEBUG GhcStage2HcOpts = -DDEBUG }}} source: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} module A where import GHC.Generics class B f where b :: [f a] toEnumDefault :: (B (Rep a)) => Int -> a toEnumDefault i = let l = b in to }}} result: {{{ [1 of 1] Compiling A ( a.hs, a.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1974:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2010:17 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:1952:3 in ghc:TyCoRep in_scope InScope [a1BD :-> a_a1BD[sk], a1BI :-> k_a1BI[tau:3], a1BJ :-> f_a1BJ[tau:3], a1BL :-> a_a1BL[sk]] tenv [a1BD :-> a_a1BL[sk]] tenvFVs [a1Bz :-> k_a1Bz[tau:5], a1BL :-> a_a1BL[sk]] cenv [] cenvFVs [] tys [[f_a1BJ[tau:3] a_a1BD[sk]]] cos [] 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 Tue Sep 27 07:16:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 07:16:13 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.11c332c34aef4f83ddc95cbc8431b2d2@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): You are right, it is most likely the same root cause. But no, the foreign call is not unsafe as far as I understand (the default is safe, right?). Also if I change it to an explicit safe or unsafe call the behavior is unchanged, so this does not seem to be a factor in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 09:36:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 09:36:19 -0000 Subject: [GHC] #12631: `hpc report` silently ignore non-existent modules Message-ID: <045.9cd99d6e95903d0d87ff54f72defdb0d@haskell.org> #12631: `hpc report` silently ignore non-existent modules --------------------------------------+--------------------------- Reporter: quabla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- {{{ hpc report my.tix NotExistingModule }}} reports a coverage of 100% (0/0) This was confusing to me since I didn't even wanted to supply a module but rather two arguments to --hpcdir without noting that the flag has to be given multiple times. Instead of a ***Module ''hpc/path'' not found*** message, I got 100% converage. {{{ $ hpc version hpc tools, version 0.67 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 11:31:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 11:31:49 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.53de3a047bdadaa2891e88fab8364794@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by awson): Btw, the patch was accepted into mainline binutils, hope the next stable version will contain it. If anybody is interested in it to be landed in MSYS2 builds ASAP, should appeal to MSYS2 maintainers -- they usually cherry-pick important patches from mainline into their stable builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 12:53:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 12:53:42 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.49c68d9f8e2fe9efa17dda54bc337d9e@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | 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: Phyx (added) Comment: Phyx, do you know anyone in the msys2 project? This sounds important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 14:56:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 14:56:04 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.9b5f6af65a5af38bfb3c2e797830db66@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | 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 osa1): If anyone's interested, I started writing a proposal for this: https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or- patterns.rst any help on fleshing out the design would be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 14:58:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 14:58:48 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.d6c6c9c1cf72b75b996b4cd8c5e199bc@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I finally got 7.6 installed, and can reproduce the issue. The problem isn't that a `Foo a` appears, it's that without the SPECIALIZE pragma, there is a function called `Main.$splus` in core that takes/uses dictionaries, even though the type is monomorphic: {{{ Main.$splus :: Foo.Foo (Foo.Qux GHC.Types.Int) -> Foo.Foo (Foo.Qux GHC.Types.Int) -> Foo.Foo (Foo.Qux GHC.Types.Int) [GblId, Arity=2, Str=DmdType SS, Unf=Unf{Src=, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30 30] 110 20}] Main.$splus = \ (ds_dJ0 :: Foo.Foo (Foo.Qux GHC.Types.Int)) (ds1_dJ1 :: Foo.Foo (Foo.Qux GHC.Types.Int)) -> case ds_dJ0 of _ { Foo.Bar v1_aH6 -> case ds1_dJ1 of _ { Foo.Bar v2_aH7 -> case (Foo.$fNumQux_$c+ @ GHC.Types.Int GHC.Num.$fNumInt Data.Vector.Unboxed.Base.$fUnboxInt v1_aH6 v2_aH7) }}} Replying to [comment:10 erikd]: > Even with ghc 7.6, this seems to specialize correctly: > > {{{ > cabal exec -- ghc -fforce-recomp -ddump-simpl -dsuppress-idinfo main.hs 2>&1 | grep Foo > ... > @ (Foo.Qux GHC.Types.Int) > @ (Foo.Foo (Foo.Qux GHC.Types.Int)) > (Foo.$WBar @ (Foo.Qux GHC.Types.Int)) > ... > }}} > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 15:20:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 15:20:04 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.c2c5d1b6b53001597f9c9ed171b0ed23@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have fixed both this issue and #11792 in Phab:D2263. I have added your failing example (extended to test pushed args) as a test too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 15:34:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 15:34:41 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.a639c490a4d526391bdc6c086f9ef010@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): However, as SPJ pointed out, this seems to be resolved in GHC 8.0.1. Indeed, I don't need either the SPECIALIZE ''or'' the INLINABLE with GHC 8.0.1. Kudos to it. I'll consider this resolved as soon as someone confirms (or denies) that auto-specialization is intended to be transitive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 15:44:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 15:44:54 -0000 Subject: [GHC] #12632: Inline and Noinline pragmas ignored for instance functions Message-ID: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> #12632: Inline and Noinline pragmas ignored for instance functions -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An example source file which triggers the incorrect behaviour follows. I am currently unclear whether the effected inline and noinline pragmas are actually ignored by the simplifier or whether the inline rule shadowing warning is fired incorrectly. {{{#!hs class A a where (>>#) :: a -> a -> a instance A (Maybe a) where {-# NOINLINE (>>#) #-} a >># b = undefined {-# RULES "example" forall (a :: Maybe Int) (b :: Maybe Int) . a >># b = Just 4 #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 16:02:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 16:02:57 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.00920f44ce17f79bb3278e22558cbfe4@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer, ORF 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 adamgundry): * owner: => adamgundry * failure: None/Unknown => Incorrect warning at compile-time * milestone: => 8.2.1 Comment: @jml thanks for the report. I'll fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 16:16:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 16:16:51 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.facaab514ab52e5b7b206beddcca17fe@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11792 | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * cc: hsyl20 (added) * differential: => Phab:D2263 * related: => #11792 * priority: normal => high * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 17:39:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 17:39:28 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.ee7d503026d350564c795fdbd84a54c4@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): It gives me that error: {{{ D:\ghc-8.1.20160926\bin>ghc -rtsopts some.hs [1 of 1] Compiling Main ( some.hs, some.o ) : error: Warning: Couldn't figure out C compiler information! Make sure you're using GNU gcc, or clang ghc: could not execute: E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/bin/gcc.exe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 18:08:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 18:08:02 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.4dcf2adbfb8497e16ece0fc74edcbee0@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | overloadedrecflds/should_compile/T12609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * testcase: => overloadedrecflds/should_compile/T12609 * status: new => patch * differential: => Phab:D2549 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 18:36:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 18:36:16 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.c4ef04f3241ec92cd25b4c2f36f91d23@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: xnyhps => gridaphobe Comment: @simonpj I'm working on this and have a patch nearly ready, but I'm a bit confused by your suggestion (in comment:1) to update `CmmLint`. It's not clear to me how to check this at the `Cmm` level, how do we determine what is top level? Perhaps you meant to check the invariant in `CoreLint`? I'm having to tweak a few of the checks there anyway that expect all top-level binders to have lifted types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 19:10:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 19:10:16 -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.de9c1eb9083650cdf595339e9cd75bbd@haskell.org> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: proposal | Status: patch Priority: normal | Milestone: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by bgamari): There was recently a [[https://mail.haskell.org/pipermail/libraries/2016-September/027319.html|discussion]] on the libraries list but it's not clear to me what the conclusion was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 20:29:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 20:29:43 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.82417753bb025319d56928e8bc0c44b3@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by Phyx-): * cc: Phyx (removed) * cc: Phyx- (added) Comment: No sorry, don't know anyone in mingw-w64 yet. However, @Elieux who is usually in #GHC might be able to help. In the mean time I have opened an issue on their tracker https://github.com/Alexpux/MINGW-packages/issues/1765 and asked for the patch to be applied. Since we host the binaries ourselves anyway we can also just choose to apply them ourselves if they don't want to do it. We have to update binutils anyway for `-ffunction-sections` no @awson? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 20:33:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 20:33:33 -0000 Subject: [GHC] #12633: Support standard syntax for language pragmas in GHCi Message-ID: <045.359fef3f7a4eec168f3e1ad19a6b584f@haskell.org> #12633: Support standard syntax for language pragmas in GHCi -------------------------------------+------------------------------------- Reporter: Hjulle | 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: -------------------------------------+------------------------------------- It would be convenient to be able to use the standard (module level) syntax for language pragmas in GHCi {{{#!hs {-# LANGUAGE Extension #-} }}} instead of just the GHCi specific syntax {{{#!hs :set -XExtension }}} For example, this would simplify copy-pasting examples and code into GHCi, especially now that most other module level syntax is supported. It might also reduce confusion for new users, since the syntax is the same in both cases. If it is not too difficult, I might take on this myself as a good first bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 21:39:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 21:39:07 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.9d7bf99e7ea5b1053d61b6c55be556a9@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp 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): Thanks nicolast! However, I wonder whether we should take this opportunity to apply a bit of foresight. In particular what happens when we reach LLVM 3.10? Or for that matter 10.0? Perhaps we should either, * split this macro up into `__GLASGOW_HASKELL_LLVM_MAJOR_VERSION__` and `__GLASGOW_HASKELL_LLVM_MINOR_VERSION__`, or * pad `__GLASGOW_HASKELL_LLVM__` with zeros to ensure that we have room to grow (although this would sadly not be backwards compatible). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 21:49:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 21:49:25 -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.bdb60d91e7db73f26085a596cb94de4b@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung 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: | -------------------------------------+------------------------------------- Comment (by bgamari): > I would rather do things the right way and thus try my hand at the first solution. Is this something that is still suitable for a newcomer? I'm happy to hear that you are willing to give it another go. Regarding Simon's suggestion, I suspect you could pull it off, although it will naturally require some learning. You'll likely want to start reading `compiler/iface/LoadIface.hs`. In particular pay attention to the `ignore_prags` argument to `loadDecl`. This is how we currently tell the typechecker not to bother typechecking unfoldings. You will likely want to remove this; instead you want to fork off typechecking as an interleaved computation with `TcRnMonad.forkM`. Then just make sure that there are no unconditional strictness demands on the pragma field and add a condition on `-fignore-interface-pragmas` to ignore the presence of the pragmas when necessary. As always, let me know if I can be of help, especially if any of the above seems incorrect; it is largely the result of a cursory glance over the relevant code and I could have easily missed something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 22:00:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 22:00:02 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.2a22237ef8b51b70cd025c3bb19010b6@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 bgamari): Bah, yes, I suppose you are right. The name `INLINEABLE` is still rather unsatisfying but that is a very minor issue. However, putting `SPECIALIZABLE` aside for a moment, I do wonder there might still be value in the `RECURSIVE_SPECIALIZEABLE` variant. Admittedly it is an extremely large hammer, but there are sometimes cases where you really want to avoid dictionary passing and dynamic dispatch if at all possible. This is especially true of CPS'd code (the `binary` library, for instance), where the entire point is that we want GHC to collapse code from various points in the program into a single straight run. Currently composing `binary` decoders from across modules requires quite some care as a single missing `INLINEABLE` can have significant performance implications which can currently only be spotted by looking carefully at the simplified Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 22:06:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 22:06:51 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.8060d09498a0ca141eca12ade5ba38e7@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Use case: with [https://hackage.haskell.org/package/array-0.5.1.1/docs /Data-Array-MArray.html#v:newListArray newListArray] {{{#!hs newListArray :: (MArray a e m, Ix i) => (i, i) -> [e] -> m (a i e) }}} we want to pick an instance of `MArray` many of whom have this form {{{#!hs instance MArray (STUArray s) Word (ST s) instance MArray (STUArray s) Int (ST s) instance MArray (STUArray s) Float (ST s) instance MArray (STUArray s) Bool (ST s) }}} so you try {{{#!hs newListArray @(STArray _s1) @Bool @(ST _s2) @Int :: MArray (STArray t) Bool (ST t1) => (Int, Int) -> [Bool] -> ST t1 (STArray t Int Bool) }}} but we need to unify `_s1` and `_s2` if we want to discharge the constraint, using syntax from ticket:11385#comment:2 {{{#!hs \ @s -> newListArray @(STArray s) @Bool @(ST s) @Int }}} the alternative being `newListArray @(STArray s) @Bool @(ST s) @Int :: forall s. _` (which isn't that bad because there are no additional constraints: if we had left `@Int` off it would not work and we would have to write {{{#!hs newListArray @(STArray s) @Bool @(ST s) :: forall s i. Ix i => (i, i) -> _ }}} instead) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 22:06:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 22:06:53 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.7e43a0477928a00528bcfc36f7d415c7@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by basvandijk): * version: 7.10.1 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 22:21:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 22:21:27 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.9a25cc60974e5e329b54dd3596e5e590@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 bgamari): Here is a only-slightly-silly example demonstrating a typical case where an unsuspecting application author is bitten by the poor performance due to missing unfoldings, {{{#!hs -- File: Lib.hs module Lib where import Data.Binary import Data.Binary.Get import Control.Applicative import Control.Monad -- | Here we have a combinator carefully crafted with an -- INLINEABLE pragma by a library author to ensure that the -- @Binary a@ dictionary is statically resolved. aDecoder :: Binary a => Get ([Int], a) aDecoder = (,) <$> replicateM 4 get <*> get {-# INLINEABLE aDecoder #-} -- File: User.hs module User where import Data.Binary import Control.Monad import Lib -- | Here an unsuspecting application author tries to use aDecoder user1 :: Binary a => Get [([Int], a)] user1 = replicateM 5 aDecoder --{-# INLINEABLE user1 #-} -- If the user forgets this INLINEABLE pragma then the library -- author's care is all for naught; the user's program will be -- a lumbering, allocating beast for reasons he has no understanding of -- File: Main.hs {-# LANGUAGE TypeApplications #-} import qualified Data.ByteString.Lazy as BS import Data.Binary.Get import User1 -- Here is the final callsite where the user instantiates -- @a@ main :: IO () main = do bs <- BS.getContents print $ runGetOrFail (user1 @Int) bs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 22:31:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 22:31:33 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.2c08427bc32e7ec40060324dd3736519@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): @crockeea Two quick questions: 1) The presence of the dictionary is inferred from case expression matching on `Foo.$fNumQux_$c+` right? 2) What command line are you using to compile this. I'm still having a bit of trouble reproducing this even with ghc 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 22:35:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 22:35:47 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.1f19ffc06230b0557a363f77a6c4eb47@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp 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 nicolast): I considered this as well, and the pre-8.0.1 behaviour is indeed prone to the examples you provided, so simply reverting to the old method may not be the way to go. Proposal: - Consider the 8.0.1 'tuple' value to be a mistake/oversight and use a plain integer anyway - Format {{{__GLASGOW_HASKELL_LLVM__}} similar to {{__GLASGOW_HASKELL__}}}: {{{ __GLASGOW_HASKELL__ For version x.y.z of GHC, the value of __GLASGOW_HASKELL__ is the integer ⟨xyy⟩ (if ⟨y⟩ is a single digit, then a leading zero is added, so for example in version 6.2 of GHC, __GLASGOW_HASKELL__==602). More information in GHC version numbering policy. }}} I believe this encoding should be fine and, in a way, backwards compatible: - *Or* one was using GHC < 8, which has {{{__GLASGOW_HASKELL_LLVM__}}} defined as {{{34}}}, {{{35}}} or whichever other version was ever supported - *Or* one is using GHC 8.0.1, and a specific work-around to handle the tuple case - *Or* one is using GHC > 8.0.1, and (for now) {{{__GLASGOW_HASKELL_LLVM__}}} will be {{{307}}}. *If* one was using the macro value in a conditional, then - Or one was doing an equality check, which will still work out nicely: or it's some old LLVM version, or it's LLVM 3.7 for GHC 8.0.1 (tuple), or it's 307 - Or one was doing a comparison. Again, we can exclude the GHC 8.0.1 case. If one checks whether the LLVM version is, say, 3.5 or lower, then {{{__GLASGOW_HASKELL_LLVM__ <= 35}}} will do 'the right thing' for {{{307}}} or whatever later version. - Similarly, {{{__GLASGOW_HASKELL_LLVM__ > 35}}} will work out nicely for {{{307}}}. As such, I believe that if we make the change (add padding) now, things should be 'morally' backwards compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 23:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 23:14:33 -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.17fe30e1c5f37c574867f64d92dd7b58@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 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): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:50 nomeata]: > How about `deriving stock Eq` instead? I spent so long looking for `builtin` synonyms that I had never considered `stock` as an option. I have to say, I really like that suggestion. I've posted a [https://mail.haskell.org/pipermail/ghc- devs/2016-September/012880.html follow-up] to the ghc-devs mailing list thread in which I argue in favor of `stock`. If nobody raises a serious objection, I think I'll make the switch to use that keyword instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 27 23:26:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Sep 2016 23:26:21 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.a586f5af7aa47c356247d4ab2f2b6d32@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ah, hmm. I have set the release flag so not sure why it's hardcoding my paths inside the config. I've asked the release manager for help, but will probably get an answer sometime tomorrow. I'll package the build again then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 00:01:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 00:01:35 -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.5bc53af778894a9cc49133f377ff3e69@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: | -------------------------------------+------------------------------------- Comment (by nh2): I'm not sure if this is of any help as you already mentioned `sched_yield`, but I noticed that when running even `ghc --make -j2` on my project with 30 modules, `sudo csysdig` (a program to easily report syscall activity) reports betwen 1-2 *million* calls per second. Is this to be expected? That seems like an aweful lot of syscalls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 00:07:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 00:07:04 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.dadadba898c8b36b42715ed5742abac2@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Ack, I have also been working on this, but it seems like @gridaphobe's patches are closer to be ready (I haven't updated the core lint to check the new invariant). Here is a link to my patch in case it contains anything useful: https://github.com/takano- akio/ghc/commit/abd74a0d1fdde0e75d46bf1ff255ed4966a020ad -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 01:02:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 01:02:19 -0000 Subject: [GHC] #12379: WARN pragma gives warning `warning: [-Wdeprecations]' In-Reply-To: <045.155a5978502e79d25fe769eea3d3ec0b@haskell.org> References: <045.155a5978502e79d25fe769eea3d3ec0b@haskell.org> Message-ID: <060.2bea7328a34bd462756dd14780d836bb@haskell.org> #12379: WARN pragma gives warning `warning: [-Wdeprecations]' -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmcgilchrist): Just checking my understanding of what needs to be done here. Do I simply change the occurrences of `ghc-flag:: -Wwarnings-deprecations` with `ghc-flag:: -Wwarn-warnings-deprecations`? Are there docs on how to build the things under `doc/users_guide`? When I do a make from the top level it seems to be just building the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 01:11:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 01:11:14 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.48fef85dd8afbeb6ae423a29cbbf3fc0@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:13 erikd]: > @crockeea Two quick questions: > > 1) The presence of the dictionary is inferred from case expression matching on `Foo.$fNumQux_$c+` right? Not quite sure what you're asking, but the dictionaries I see are the arguments to `Foo.$fNumQux_$c+`, namely `GHC.Num.$fNumInt` and `Data.Vector.Unboxed.Base.$fUnboxInt`. > > 2) What command line are you using to compile this. I'm still having a bit of trouble reproducing this even with ghc 7.6.3. > I'm compiling with `ghc-7.6.3 -ddump-simpl -O2 Main.hs`. With just the `INLINABLE` pragma on `Foo.plus`, this takes over a minute on my computer. With the `SPECIALIZE` pragma (with or without the `INLINABLE`), it completes in 3 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 02:30:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 02:30:59 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.48c0ce2d5e78de71a4dd111191941c27@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by dterei): * cc: dterei (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 02:37:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 02:37:50 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.06b42a6b532a683420a685d738d4779b@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: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: kopernikus (added) Comment: I’m sure that Andres has interest in a `RECURSIVE_SPECIALIZEABLE` pragma, or some variant thereof (e.g. attached to the type class itself). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 03:02:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 03:02:29 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.ccb854449704af743ed417a56f06618f@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: kopernikus (removed) * cc: kosmikus (added) @@ -1,1 +1,1 @@ - This is a write-up of a rough idea that Andres Löw and me had at ICFP 2016 + This is a write-up of a rough idea that Andres Löh and me had at ICFP 2016 New description: This is a write-up of a rough idea that Andres Löh and me had at ICFP 2016 in order to address some Real World problems Andres noticed and that are currently hard to avoid. The goal is to give the user more control about expressions that the compiler would like to float out (or CSE), but the programmer knows better. Example (assume no list fusion exists): {{{ enum xs = zip [1..] xs }}} This leads to a horrible space leak, as GHC will float out `[1..]` to the top. Our idea is to have a magic function `nofloat :: a -> a` (magic in the same sense as `inline` and `lazy`) that the programmer would use here: {{{ enum xs = zip (nofloat [1..]) xs }}} With these effects: * Sub expressions are not floated out of a `nofloat`. * An expression of the form `nofloat e` would not be floated beyond the innermost enclosing lambda. * Two expressions of the form `nofloat e` would not be commoned up by CSE. This way, unwanted sharing is prevented. In contrast to a hypothetical `veryCheap` function, it does ''not'' mean that the compiler should float it into lambda (no unwanted duplication either). Two open questions (among many others, I am sure:) * Likely, rule matching should look through `nofloat`. At least in this example (and similar ones like `map (nofloat [1..])`, the rules in question will avoid the spaceleaks). * Possibly, nothing should be floated (inlined) ''into'' a `nofloat`. Rationale: Assume the library is changed so that {{{ [n..] = nofloat (realEnumFrom n) {-# INLINE [n..] #-} }}} Then `zip [fib 1000..]` would be rewritten by the inliner to `zip (let x = fib 1000 in (nofloat [x..]))`. Moving the `fib 1000` into the `nofloat` would change the behaviour in a possibly surprising way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 03:02:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 03:02:38 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.c6fd92f04a3976745a6c3fb88be8b9f5@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: kopernikus (removed) * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 03:58:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 03:58:52 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.d9623d87efad52590ace8212d85490ad@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): @akio sorry about the duplicate work! It looks like our patches are very similar, though I introduce a new StgRhs constructor rather than your StgTopBinding type. I think your approach is a bit better, as I end up having to deal with the (im)possibility of let-binding a literal anywhere (it looks like Stg uses `case of { __DEFAULT -> ... }` to bind literals, which makes sense given that they can't be lazy). Does your patch validate? I just noticed this afternoon that although my patch works for the example and parts of nofib, it causes a linker error when building ghc-stage2, due to undefined symbols. I'm setting the label for the string literal a bit differently from you, so your patch might be fine. My CoreLint patch is at https://github.com/ghc/ghc/compare/master...gridaphobe:T8472#diff- 9ad7456ebf7fad38de8b24ddceb9bb3c. Do you want to submit your patch + my CoreLint pass, that ought to make for a complete patch :) (I also notice that both of our patches could use a nice Note explaining why we want to bind string literals at the top level, especially since the logic is spread across multiple phases of the compiler) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 03:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 03:59:08 -0000 Subject: [GHC] #12634: Panic with piResultTys1 Message-ID: <047.a9138ac95150387a081a885f4f2d20ce@haskell.org> #12634: Panic with piResultTys1 -------------------------------------+------------------------------------- Reporter: crockeea | 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 Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} twacePowDec :: t m' r -> t m r twacePowDec = undefined data Bench a bench :: (a -> b) -> a -> Bench params bench f = undefined bench_twacePow :: forall t m m' r . _ => t m' r -> Bench '(t,m,m',r) bench_twacePow = bench (twacePowDec :: t m' r -> t m r) }}} produces (in GHCi): {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:13:58: error: • Expected a type, but ‘'(t, m, m', r)’ has kind ‘(k1 -> k2 -> *, k0, k1, k2)’ • In the first argument of ‘Bench’, namely ‘'(t, m, m', r)’ In the type ‘t m' r -> Bench '(t, m, m', r)’ Bug.hs:14:52: error: • Expected kind ‘k1’, but ‘m’ has kind ‘k0’ • In the first argument of ‘t’, namely ‘m’ In an expression type signature: t m' r -> t m r In the first argument of ‘bench’, namely ‘(twacePowDec :: t m' r -> t m r)’ • Relevant bindings includeghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): piResultTys1 k_a18K[tau:3] [m'_a17U[sk], r_a17V[sk]] }}} The intent was to use this code with `-XPartialTypeSignatures`, but the bug occurs with or without that extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 06:14:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 06:14:02 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.ed0e80cd4c13edf367492e3f706c9a7a@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Without `SPECIALIZE` it takes about a second on my laptop (month old high end Dell with SSD). I simply can't image an x86_64 machine could be over 60 times slower. Ok, so the suspicious code is: {{{ case (Foo.$fNumQux_$c+ @ GHC.Types.Int GHC.Num.$fNumInt Data.Vector.Unboxed.Base.$fUnboxInt v1_aHk v2_aHl) }}} which is what I get with ghc-7.6.3. I get something very similar with ghc-7.8.4. For ghc 7.10.3 and 8.0.1 there is no instance of the string `GHC.Num` in the output from `Main` (but there is for `Foo` which is expected). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 07:56:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 07:56:09 -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.f6e0a287bf74494902bbfafcadd314be@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: | -------------------------------------+------------------------------------- Comment (by slyfox): I think it's expected if you have GC work imbalance. Some GC work-stealing threads sit in yield loop at: http://git.haskell.org/ghc.git/blob/HEAD:/rts/sm/GC.c#l981 Imbalance can be seen seen as: '''+RTS -sstderr''' shows it as '''Parallel GC work balance: 80.03% (serial 0%, perfect 100%)'''. and can be tuned by heap size or allocation area ('''-A'''). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 08:37:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 08:37:45 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.fd380a15248ce5175440d6b4e28d374d@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so is the conclusion is that this is a perf bug in 7.6 (and maybe 7.8) but fine now? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 08:40:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 08:40:05 -0000 Subject: [GHC] #12632: Inline and Noinline pragmas ignored for instance functions In-Reply-To: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> References: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> Message-ID: <065.65ae287d0b689838bb8066f677cccdf8@haskell.org> #12632: Inline and Noinline pragmas ignored for instance functions -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you elaborate on what exactly is the "incorrect behaviour" that you are concerned about? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 09:19:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 09:19:01 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.f9284c3768c78d4412f3287bf7d15c7a@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Excellent work! > Perhaps you meant to check the invariant in `CoreLint`? Yes I did. Sorry for the confusion here. > I introduce a new `StgRhs` constructor rather than your `StgTopBinding` type. I think your approach is a bit better, I have not looked at the details, but since we are only talking about introducing a new ''top-level'' form, it makes sense for the data type to reflect that if it's convenient to do so. > (I also notice that both of our patches could use a nice Note explaining why we want to bind string literals at the top level, especially since the logic is spread across multiple phases of the compiler) YES PLEASE! Also document invariants in `CoreSyn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 11:34:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 11:34:30 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.f1c9f9a66cc73b424a5a58baf242442e@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): No, the issue is at a lower level than environments. With existing GHC options, it is not possible to express what is required here. We want GHC to choose packages in a way so as to stack the dbs on top of each other (upper dbs in the stack overriding the lower ones) rather than union them which is the default behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 11:45:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 11:45:15 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.053183641e634c22a37db3466551e9a1@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:10 gridaphobe]: > Does your patch validate? I just noticed this afternoon that although my patch works for the example and parts of nofib, it causes a linker error when building ghc-stage2, due to undefined symbols. I'm setting the label for the string literal a bit differently from you, so your patch might be fine. I don't get link errors, but I do get several failures when I run `make slow` in `testsuite/`. Some of the failures look harmless (the expected output has to be adjusted) but I'll need to look more carefully at other failures. > > My CoreLint patch is at https://github.com/ghc/ghc/compare/master...gridaphobe:T8472#diff- 9ad7456ebf7fad38de8b24ddceb9bb3c. Do you want to submit your patch + my CoreLint pass, that ought to make for a complete patch :) Thanks, I've taken your patch to CoreLint. I'm happy to sort out the remaining issues and submit a Differential revision, but I won't have much time to work on this until this weekend. Feel free to go ahead and do it yourself if you like. In any case, my work-in-progress branch can be found at https://github.com/takano-akio/ghc/commits/top-level-string. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 12:06:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 12:06:25 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.d1cee5892862a18e8250e4869fa9434e@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 simonpj): Replying to [comment:11 nomeata]: > I’m sure that Andres has interest in a `RECURSIVE_SPECIALIZEABLE` pragma, or some variant thereof (e.g. attached to the type class itself). But what ''is'' `RECURSIVE_SPECIALIZEABLE`? It's described only in rather elliptical fashion above, and I have no clear idea of what its specification is. Would someone care to write a spec, so we can all be sure we are discussing the same thing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 12:09:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 12:09:02 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.63f2fdaae7f5072a7b33a93c0180d50b@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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): That all looks possible. Since `nofloat` does several things, it may not be long before people start asking for variants that do some combination of its properties. But I guess we can jump that bridge if we come to it. It would be useful to give some compelling use-cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 12:17:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 12:17:59 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.e4b998e42cfd9d5e6b351bd9cac8e405@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 mpickering): Here is my understanding of what Ben means. --- We introduce a new top-level pragma which is introduced the the syntax `{-# RECURSIVE_SPECIALISABLE varid #-}`. Only top-level functions can be marked with this pragma. For a function `f` which is marked with `RECURSIVE_SPECIALISABLE`: 1. When `f` is exported, `f`'s unfolding is included in the interface file. (As if `f` was marked `INLINABLE`). 2. When `f` is used in the definition of another function `g`, `g`'s unfolding is included in the interface file when `g` is exported. (As if `g` was marked `INLINABLE`). --- Is that what you mean Ben? My questions are 1. Why would you mark your function as `INLINABLE` rather than `RECURSIVE_SPECIALISABLE`? 2. What advantages does this pragma have over including the unfoldings of all polymorphic functions ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 12:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 12:52:06 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.2b5c237a1c8381efcd8ba59ef89e770a@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Comment (by bgamari): I am able to reproduce this with GHC 8.0.1 and the instructions given in comment:45. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 12:59:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 12:59:42 -0000 Subject: [GHC] #12632: Inline and Noinline pragmas ignored for instance functions In-Reply-To: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> References: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> Message-ID: <065.6b02b2850734ffb00755d198c11a60e7@haskell.org> #12632: Inline and Noinline pragmas ignored for instance functions -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeremy-list): Compiling this code with "-O2 -ddump-rule-firings": {{{ class Inv a where inv :: a -> a instance Inv Bool where {-# NOINLINE inv #-} inv = not {-# RULES "force-inline" forall (a :: Bool) . inv a = not a #-} main = print (inv True) }}} The output from GHC is: {{{ [1 of 1] Compiling Main ( sample1.hs, sample1.o ) sample1.hs:8:11: warning: [-Winline-rule-shadowing] Rule "force-inline" may never fire because ‘inv’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘inv’ Rule fired: force-inline Rule fired: Class op show Linking sample1 ... }}} Here the warning is incorrect because it ignores the NOINLINE pragma, but the rule is fired because the function isn't actually inlined. If the NOINLINE pragma is changed to INLINE the output from GHC is identical: the warning is emitted and the rule is fired. This is incorrect because the rule shouldn't fire if the function is inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 13:05:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 13:05:51 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.6603d8c48738b940395e9ac65770e735@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 bgamari): > Is that what you mean Ben? My questions are > 1. Why would you mark your function as `INLINABLE` rather than `RECURSIVE_SPECIALISABLE`? `RECURSIVE_SPECIALISABLE` carries a potentially significant cost above `INLINEABLE` as it may produce many more inlinings which we have to later read and decide whether to use at every callsite. > 2. What advantages does this pragma have over including the unfoldings of all polymorphic functions? This is a good question. It depends upon whether we feel that the costs above are large enough to warrant yet another pragma. Frankly, users complain a great deal about compiler performance and one of the reasons for this is that GHC applies all of its might to all of the code it compiles with `-O`. In light of this it seems like giving GHC more information about where it should be focusing its attention may be worthwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 13:13:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 13:13:57 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.e96bb455856eeb869ffcf998a9174f70@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): @erikd: The performance disparity is odd. Not sure what to tell you there. @simonpj: Correct: performance bug in 7.6 and 7.8, fixed after that apparently. There's still the question of intended behavior: yes or no to transitivity of auto-specialization? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 13:33:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 13:33:41 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.c08f714530dbb45e6d66e88316786536@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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -93,1 +93,12 @@ - need to know about `aLibrarFunction`'s expectations of the simplifier. + need to know about `aLibraryFunction`'s expectations of the simplifier. + + === A definition of `SPECIALISE_RECURSIVE` == + + The `SPECIALISE_RECURSIVE` pragma can be attached to top-level + identifiers. Like `INLINEABLE`, `SPECIALISE_RECURSIVE` would force GHC to + produce an unfolding for the identifier to which it is attached. Unlike + `INLINEABLE`, it also forces GHC to produce an unfolding for all top-level + identifiers which contain a polymorphic call-site of an identifier marked + as `SPECIALISE_RECURSIVE`. This ensures that GHC is able to produce + specialisations for all concrete instantiations of functions marked as + `SPECIALISE_RECURSIVE`. New description: Currently it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. We can only convince GHC to produce an unfolding for `aLibraryFunction` if we annotate it with an `INLINEABLE` pragma. While this is often effective, it doesn't really say what we mean: We don't never want GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} }}} The list of type binders after `SPECIALISE` is the set of binders which GHC would attempt to specialize. This pragma requests that GHC keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, the produced symbols could be declared as weak, allowing the linker to cull duplicated code when possible. = Transitive specialisation = The above `SPECIALISE` pragma still doesn't address the fragility of specialisation, however. Namely, consider, {{{#!hs module ALibrary where class AClass instance AClass Int aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} module AnotherLibrary where import ALibrary aFunction :: AClass a => a -> a aFunction x = {- ... -} aLibraryFunction x {- ... -} module AUser where import AnotherLibrary f = let x :: Int x = 5 in aFunction x }}} Here `aLibraryFunction` may depend crucially on specialisation; however, the polymorphic user `aFunction` has no way of knowing this and may be too large for GHC to produce an unfolding automatically. This ultimately means that GHC will be unable to specialise the eventual instantiation at `Int` in `AUser.f`. This will mean that the performance characteristics of `ALibrary` will be rather fragile. One (admittedly rather heavy) approach to solving this fragility is to inform GHC that `aLibraryFunction`'s polymorphic callsites should have unfoldings, ensuring that we are able to specialise the eventual monomorphic callsite, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE_RECURSIVE(a) forall a. aLibraryFunction :: a -> a #-} }}} Which would ensure that polymorphic use-sites of `aLibraryFunction` would themselves be marked as `SPECIALISE_RECURSIVE`, shielding users from the need to know about `aLibraryFunction`'s expectations of the simplifier. === A definition of `SPECIALISE_RECURSIVE` == The `SPECIALISE_RECURSIVE` pragma can be attached to top-level identifiers. Like `INLINEABLE`, `SPECIALISE_RECURSIVE` would force GHC to produce an unfolding for the identifier to which it is attached. Unlike `INLINEABLE`, it also forces GHC to produce an unfolding for all top-level identifiers which contain a polymorphic call-site of an identifier marked as `SPECIALISE_RECURSIVE`. This ensures that GHC is able to produce specialisations for all concrete instantiations of functions marked as `SPECIALISE_RECURSIVE`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 14:01:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 14:01:00 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.1629e0517947842cc748b09bf7530203@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Could you give a specific example? From the description it looks like environments are exactly what you want: > Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. Environments are designed for exactly this situation: you're using `runghc` or `ghci`, and you want `GHC` to make a specific set of packages visible. In particular, you're saying you want to deliberately use older versions of some package: you could just omit the newer versions from the environment, and GHC will ignore them. Alternatively you can specifically request the older version using a `-package` flag. One reason I'm pushing on this because I think we should deprecate the idea of DB stacks (see #12485). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 15:34:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 15:34:23 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.94202494c9cc57a6cf0f3ddb4af00a2c@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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 duncan): Can I suggest a closely related idea, and also related to #9520 {{{ data Pipe i o r = Yield o {-# NOUPDATE #-} (Pipe i o r) }}} This says we'll never do thunk updates on that field in that constructor. So similar idea (I believe) to `oneShot` lambdas. Indeed we might need both no update on fields and oneShot, I'm not sure, e.g.: {{{ data Pipe i o r = Yield o {-# NOUPDATE #-} (Pipe i o r) | Await {-# NOUPDATE #-} (Either r i -> Pipe i o r) -- smart constructor: await f = Await (GHC.Magic.oneShot f) }}} What's all this for? For avoiding treating these control structures as data structures (which is what #9520 is all about). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 15:54:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 15:54:02 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.71f4f43c9e2d449ea6bda3f02fec2599@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Just to be clear, the ghc work flows that are impacted are those which need the system linker. Namely any dynamic linked executables , ghci , or TH. I agree with Gershom's assessment that 8.0.2 should wait till this is validated as being fixed for 10.12 and at least doesn't trigger any regressions on 10.11 and 10.10. @ilovezfs will you be able to help us consistently test that version range for correctness and absence of regressions? I could probably help with some guidance. I guess this is the first time Mac OS X support range has come up since the cpp / clang challenges in recent years. Or the more recent issue of some object code tool from llvm, nm, not defaulting to posix format for certain outputs. I would propose that we treat at least the 2-3 most recent OS X releases as "core tier 1" of our tier 1 Apple support. At least as an informal guide post? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 16:22:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 16:22:17 -0000 Subject: [GHC] #12626: Remove redundant type applications in Core In-Reply-To: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> References: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> Message-ID: <061.a9c3cae69db9dc2ca8deb57be9ba483d@haskell.org> #12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | 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 nomeata): TODO: Look at what Johan Georg Granström did, and if that’s related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 16:29:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 16:29:15 -0000 Subject: [GHC] #12635: Compress core in interface files Message-ID: <046.71dac9135039d67b454be90a90ca470c@haskell.org> #12635: Compress core in interface files -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Inspired by #12626 and #12618, the idea came up of storing less stuff about Core expressions in interface files if we can infer it while reading it. For example, in the unfolding of an function `Int -> Int`, which might look like `\x::Int → ...`, the type annotation of the variable is obviously redundant. This avenue should be explored more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 17:34:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 17:34:48 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.15f2e807bf94428279de825462a7fa85@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Right, let's try this again, I updated the config file. https://1drv.ms/u/s!AuQz_u-9HaJPmZMLKqUvPSdtUPTgug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 18:10:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 18:10:57 -0000 Subject: [GHC] #12636: ProfHeap's printf modifiers are incorrect Message-ID: <044.403f3f75ee70a8b1fc6666278b9b5226@haskell.org> #12636: ProfHeap's printf modifiers are incorrect ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: newcomer | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- during compile I noticed {{{ rts\ProfHeap.c: In function 'dumpCensus': rts\ProfHeap.c:768:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "VOID\t%lu\n", ^ rts\ProfHeap.c:770:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "LAG\t%lu\n", ^ rts\ProfHeap.c:772:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "USE\t%lu\n", ^ rts\ProfHeap.c:774:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "INHERENT_USE\t%lu\n", ^ rts\ProfHeap.c:776:26: error: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'long long unsigned int' [-Wformat=] fprintf(hp_file, "DRAG\t%lu\n", ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 19:13:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 19:13:41 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.a3f49c658aa5c3e9d2fa21d2e884a02a@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 19:14:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 19:14:41 -0000 Subject: [GHC] #12626: Remove redundant type applications in Core In-Reply-To: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> References: <046.9513a0ef4a01fc91099a0c8a40a1e42c@haskell.org> Message-ID: <061.1e765a4fd0fd5dc39f473b0f7f2a754f@haskell.org> #12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | 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: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 19:38:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 19:38:27 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.1939f0e9c7dc5aa68b359a094289b632@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by trommler): * status: new => closed * resolution: => duplicate Comment: I think this is a duplicate of #11499. The missing symbol seems to be coming from a Haskell package and not a C library. The obvious solution would be to also link all command line Haskell packages into the temporary shared library. This is what fixed the original ticket. In #11238 I am working on a redesigned dynamic linker and it is done for ELF. I need to come back to that patch and finish it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 19:45:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 19:45:37 -0000 Subject: [GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call Message-ID: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> #12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | 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: -------------------------------------+------------------------------------- This can save lots of time when the cost to invoke a single GHC command is high, for example through docker. An example user of this would be `stack build`, which will unregister all relevant packages if e.g. `--extra-lib-dirs` has changed. Currently it has to do that through multiple `ghc-pkg unregister` operations, which can take about 2 seconds per call when done through a docker image. If we could unregister multiple packages at once, such use cases would have to pay the 2 seconds penalty only once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 19:57:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 19:57:29 -0000 Subject: [GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call In-Reply-To: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> References: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> Message-ID: <057.462d7fd13cc0951766c912258c32a4bd@haskell.org> #12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | 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): D2550 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * status: new => patch * differential: => D2550 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 19:58:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 19:58:54 -0000 Subject: [GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call In-Reply-To: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> References: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> Message-ID: <057.593b6055f8e6d5c303294737d5931ce6@haskell.org> #12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | 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): D2550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): This turns out quite easy, I've attached a patch. In a future iteration of this, it would be a nice-to-have if it could automatically figure out in which order to unregister, but that's for later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 20:37:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 20:37:58 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.6a079dfaaacbba58dae48458bfa83f75@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------------+------------------------------------- Reporter: alfa07 | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic | linking Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 21:12:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 21:12:40 -0000 Subject: [GHC] #12638: GHC panic when resolving Show instance Message-ID: <047.3be4497423b54c100e8295207752bf33@haskell.org> #12638: GHC panic when resolving Show instance -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: PolyKinds, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm playing around with rolling my own type defaulting and found a panic. Note: adding a stub `Show (W a)` instance resolves this (i.e. `show _ = "test"`). {{{ {- Test.hs -} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Test where import Data.Proxy data W (a :: k) = Wk | W (MkStar a) type family MkStar (a :: k) :: * main = print (W Proxy :: W (Proxy (~))) }}} {{{ $ ghc Test.hs -o test [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:13:8: 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 }}} If `x = W Proxy :: W (Proxy (~))` is only defined, there is no issue. It seems to occur exactly when resolving a `Show` instance for `W (Proxy (~))` and one does not exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 21:52:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 21:52:36 -0000 Subject: [GHC] #12638: GHC panic when resolving Show instance In-Reply-To: <047.3be4497423b54c100e8295207752bf33@haskell.org> References: <047.3be4497423b54c100e8295207752bf33@haskell.org> Message-ID: <062.6286109bc926595d4d2706b34186fece@haskell.org> #12638: GHC panic when resolving Show instance -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: PolyKinds, Resolution: duplicate | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12041 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #12041 Comment: This is fixed on the master branch and 8.0 branch. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 22:33:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 22:33:31 -0000 Subject: [GHC] #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving Message-ID: <045.f9bffd180044243f5d493b11cf11851d@haskell.org> #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Given `{-# LANGUAGE GeneralizedNewtypeDeriving #-}`, I can write {{{#!hs import Control.Monad.State.Strict newtype Foo s m a = Foo (StateT s m a) deriving (Functor, Applicative, Monad, MonadState s) }}} However, if I want to use `StandaloneDeriving` to make the `MonadState` instance more explicit, {{{#!hs deriving instance Monad m => MonadState s (Foo s m) }}} I suddenly need to add `FlexibleInstances` and `MultiParamTypeClasses`. In my personal opinion, the most sensible way to handle this is to change two things in two different directions: 1. Allow MPTC instance declarations (but not class declarations) without `MultiParamTypeClasses`. 2. Require `FlexibleInstances` for standard deriving clauses when they would be required for standalone deriving declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 22:51:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 22:51:27 -0000 Subject: [GHC] #12632: Inline and Noinline pragmas ignored for instance functions In-Reply-To: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> References: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> Message-ID: <065.94333e5f21c732b10e584ee9160d9c32@haskell.org> #12632: Inline and Noinline pragmas ignored for instance functions -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah now I see what you mean, thanks. The thing is, in the RULE when you mention `inv` you are mentioning the `inv` from the class declaration; and you probably do not want to put NOINLINE on the class method (and I doubt that works anyway). I think you want the rule to work for "the `inf` at type `Bool`". The easiest way to do that is to name it: {{{ instance Inv Bool where inv = invBool invBool :: Bool -> Bool {-# NOINLINE invBool #-} invBool = not {-# RULES "force-inline" forall (a :: Bool) . invBool a = not a #-} }}} Now I think you'll find it works fine. It's a little less direct, but much more explicit and robust. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 28 23:48:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Sep 2016 23:48:18 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.c5ed80b51fd9b14b3cc84dae4a12c97a@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp 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 erikd): +1 for `307`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 00:12:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 00:12:16 -0000 Subject: [GHC] #12632: Inline and Noinline pragmas ignored for instance functions In-Reply-To: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> References: <050.107a18800bba4f5e328b7458e40d77f5@haskell.org> Message-ID: <065.09a802663c2bbcff0df2526e537bc70b@haskell.org> #12632: Inline and Noinline pragmas ignored for instance functions -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeremy-list): Thank you. Unfortunately this technique doesn't work for mulit-parameter type classes. Will file a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 00:19:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 00:19:50 -0000 Subject: [GHC] #12640: Class member functions not substituted for MultiParamTypeClasses Message-ID: <050.0bbfcd2a468246cf50f9e815f1bcbfad@haskell.org> #12640: Class member functions not substituted for MultiParamTypeClasses -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 the following code is compiled with "-O2 -ddump-rule-firings" the rule is not fired: presumably because the simplifier does not recognize that (+++) = ex_or. {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} class Ex2 a b c | a b -> c where (+++) :: a -> b -> c instance Ex2 Bool Bool Bool where (+++) = ex_or {-# INLINE [2] ex_or #-} ex_or = (||) {-# RULES "force-inline" forall a b . ex_or a b = a || b #-} main = print (True +++ True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 03:17:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 03:17:45 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.47d80444f189909175248038cb7ba4bb@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Have only referenced this in passing: Allow type application for methods {{{#!hs class Semigroup a where (<>) @a :: a -> a -> a class Semigroup a => Monoid a where mempty @a :: a }}} and their instances with some #12363 {{{#!hs instance (Semigroup a, Semigroup b) => Semigroup (a, b) where (<>) @(a, b) :: (a, b) -> (a, b) -> (a, b) (a1, b1) <> @(a, b) (a2, b2) = (a1 <> @a a2, b1 <> @b b2) instance (Monoid a, Monoid b) => Monoid (a, b) where mempty @(a, b) :: (a, b) mempty @(a, b) = (mempty @a, mempty @b) instance Semigroup b => Semigroup (a -> b) where (<>) @(a -> b) :: (a -> b) -> (a -> b) -> (a -> b) (f <> @(a -> b) g) x = f x <> @b g x -- ^ not recommended style class Monoid b => Monoid (a -> b) where mempty @(a -> b) :: a -> b mempty @(a -> b) _ = mempty @b }}} The type variables should probably match the order of application a regular expression context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 05:08:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 05:08:09 -0000 Subject: [GHC] #9349: excessive inlining due to state hack In-Reply-To: <047.59a8e661fb91965de593a33a83b24298@haskell.org> References: <047.59a8e661fb91965de593a33a83b24298@haskell.org> Message-ID: <062.43c5f82e38410364b10214c463596992@haskell.org> #9349: excessive inlining due to state hack -------------------------------------+------------------------------------- Reporter: rwbarton | 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 edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 06:12:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 06:12:13 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.9d5e7fba2405ea9f85206cbf1c2a2b82@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 06:31:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 06:31:44 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.507fa7f75b9800d5ffeac6227e4caa94@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Sure. Article is now published at http://www.well-typed.com/blog/2016/09 /sharing-conduit/ . It discusses all the issues mentioned in this ticket (including, as a bonus why prof-auto has the effect it has :). As requested will also add a link in the ticket description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 06:33:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 06:33:57 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.38d41d69b80f11561fa671a566ca9502@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8457, #12620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * related: #8457 => #8457, #12620 @@ -0,0 +1,6 @@ + '''EDIT''': A detailed analysis of the problems discussed in this ticket + can be found at http://www.well-typed.com/blog/2016/09/sharing-conduit/ . + There is no ghc bug here, as such, except perhaps #8457 "-ffull-laziness + does more harm than good". See also #12620 "Allow the user to prevent + floating and CSE". + New description: '''EDIT''': A detailed analysis of the problems discussed in this ticket can be found at http://www.well-typed.com/blog/2016/09/sharing-conduit/ . There is no ghc bug here, as such, except perhaps #8457 "-ffull-laziness does more harm than good". See also #12620 "Allow the user to prevent floating and CSE". This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 06:35:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 06:35:59 -0000 Subject: [GHC] #8457: -ffull-laziness does more harm than good In-Reply-To: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> References: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> Message-ID: <059.2b89099ec5616828da8b4e88742ad869@haskell.org> #8457: -ffull-laziness does more harm than good -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #12620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * related: => #9520, #12620 Comment: Just published a blog post on the perils of full laziness when using conduit (see also #9520); it might be relevant to this ticket: http://www .well-typed.com/blog/2016/09/sharing-conduit/ . See also #12620 for a recent alternative proposal to limit the scope of full laziness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 06:44:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 06:44:24 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.d4ac4f17958210e1f7485c7219e7bfea@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * related: => #9520, #8457 Comment: Right, so a lot of the thinking that led to this ticket came from trying to understand memory leaks in conduit code. See my recent blog post http://www.well-typed.com/blog/2016/09/sharing-conduit/ where these issues are described in great detail; this should also serve, I hope, as one "compelling use case". That said, I like the idea of a "noupdate" much better than a "nofloat". It would seem to me that its semantics would be easier to specify; and if it means I don't have to think so hard about what exactly the optimizer is doing to my code in order to understand why I do or do not have a memory leak, that would very welcome. I really like @duncan 's suggestion of having a type annotation on a type; though we might also want some adhoc way of saying "make ''this'' thunk not-updateable". An easyish experiment perhaps might be to declare a magic datatype {{{#!hs data DontUpdate a = DontUpdate a }}} with the property that any code that looks at the thunk in the payload of `DontUpdate` doesn't cause that thunk to be updated. Then in @duncan 's example we could define {{{#!hs data Pipe i o r = Yield o (DontUpdate (Pipe i o r)) }}} That said, I'm not sure exactly what DontUpdate should do for the lambda; but this is a question about @duncan's proposal too. I ''think'' what we want to happen is that the thunks in the function closure never get updated (this, in a nutshell, is what is causing memory leaks in conduit code; see the blog post); but that's already more magical than just saying "don't update this thunk". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 07:42:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 07:42:27 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.f4004664b2addc628d2e1d87b8a28e9b@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8457, #12620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. I've added it to the [https://wiki.haskell.org/Performance Haskell Performance Resource] Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 07:46:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 07:46:35 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.d62768f7c78bb1449b362cd125d353d2@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that "noupdate" would require some careful thought. What if I say {{{ f x = if ... then Yield blah x else ... }}} Then the "noupdate" second field of `Yield` is just the parameter to `f`. Does the caller have to know not to build an updatable thunk. And why is updating so bad? (Confession: I have not yet read Edsko's post. But I it should be possible to give a crisp explanation of what any language feature does in a standalone way.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 08:01:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 08:01:52 -0000 Subject: [GHC] #12640: Class member functions not substituted for MultiParamTypeClasses In-Reply-To: <050.0bbfcd2a468246cf50f9e815f1bcbfad@haskell.org> References: <050.0bbfcd2a468246cf50f9e815f1bcbfad@haskell.org> Message-ID: <065.7604a6844020876a80f32dcd051c2ab5@haskell.org> #12640: Class member functions not substituted for MultiParamTypeClasses -------------------------------------+------------------------------------- Reporter: jeremy-list | 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 akio): Changing the `INLINE [2]` to `INLINE [1]` allows the rule to fire. I believe the issue is that an `INLINE [2]` is essentially the same as an `INLINE` with no phase specifier, because by default `2` is the first simplifier phase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 08:05:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 08:05:59 -0000 Subject: [GHC] #12640: Class member functions not substituted for MultiParamTypeClasses In-Reply-To: <050.0bbfcd2a468246cf50f9e815f1bcbfad@haskell.org> References: <050.0bbfcd2a468246cf50f9e815f1bcbfad@haskell.org> Message-ID: <065.f4dab1b176601177d2aff8c07f0dbf9a@haskell.org> #12640: Class member functions not substituted for MultiParamTypeClasses -------------------------------------+------------------------------------- Reporter: jeremy-list | 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): Akio is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 08:13:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 08:13:58 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.8602a90ee3ce4660e6b2ff68b95eb63e@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Phyx-): Pull request has been accepted and merged https://github.com/Alexpux /MINGW-packages/pull/1767 now we just have to wait for a build to be released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 08:23:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 08:23:50 -0000 Subject: [GHC] #12634: Panic with piResultTys1 In-Reply-To: <047.a9138ac95150387a081a885f4f2d20ce@haskell.org> References: <047.a9138ac95150387a081a885f4f2d20ce@haskell.org> Message-ID: <062.098f7a025b2677fa63354c14df7fbe2b@haskell.org> #12634: Panic with piResultTys1 -------------------------------------+------------------------------------- Reporter: crockeea | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"13d3b531aa565b0fc602feb312f3054e4f1f380a/ghc" 13d3b53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13d3b531aa565b0fc602feb312f3054e4f1f380a" Test Trac #12634 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 08:24:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 08:24:19 -0000 Subject: [GHC] #12634: Panic with piResultTys1 In-Reply-To: <047.a9138ac95150387a081a885f4f2d20ce@haskell.org> References: <047.a9138ac95150387a081a885f4f2d20ce@haskell.org> Message-ID: <062.e20e8375d61d752d50996fd8fd68d35a@haskell.org> #12634: Panic with piResultTys1 -------------------------------------+------------------------------------- Reporter: crockeea | 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: partial- crash | sigs/should_fail/T12634 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => partial-sigs/should_fail/T12634 * resolution: => fixed Comment: Hmm. In HEAD and the 8.0 branch I get just the first error and no crash. I'm inclined to declare it fixed. But I'll add your code as a test, to make sure it stays fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 09:41:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 09:41:58 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.234cbab3421d9970b854ca273f9f3d62@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): Right, this is an initial idea and hasn't been fleshed out. Thanks for the probing example :-) So the intention is that it's a purely local thing. So in that example, the answer is no, we do not expect a caller far away to have to know anything. The idea is that evaluating "via" the noupdate field should not perform thunk updates, but I appreciate that may not match how thunk construction and update works. So how about something like this... Suppose the primitive is not on fields, but on let. This is by analogy with strict `let !_ =` versus strict constructor fields. The primitive with strictness is at use sites and a convenience for systematic use we can push it to constructor fields, which is defined in terms of constructor wrappers. So suppose the primitive is `let {-# NOUPDATE #-} x = ...`, and so then the `Yield` constructor above could perhaps be defined with a wrapper like {{{#!hs data Pipe i o r = Yield o {-# NOUPDATE #-} (Pipe i o r) yield o x = let {-# NOUPDATE #-} x' = x in Yield o x' }}} So in your `f x` example above then this would do very little (and indeed we'd want it to do precisely nothing different to the usual, by shorting out the extra let indirection). But if things are defined with `Yield (expr)` or locally ghc decides to float/push things in, then the expression would end up in the `let {-# NOUPDATE #-} x' = ...` and so there would be an effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 10:48:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 10:48:27 -0000 Subject: [GHC] #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns Message-ID: <049.82402fb5138ab24c534e4411909c7bac@haskell.org> #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns -------------------------------------+------------------------------------- Reporter: ahmadsalim | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to parse the following piece of code: {{{#!hs {-# LANGUAGE MultiWayIf #-} module Test where data AB = A | B aAndB :: AB -> AB -> Bool aAndB ab1 ab2 = if | A <- ab1 , B <- ab2 -> True | otherwise -> False }}} I get the following error {{{ test.hs:9:6: error: parse error (possibly incorrect indentation or mismatched brackets) }}} This is as currently is inconsistent with how guards are parsed, e.g.: {{{#!hs aAndB2 :: AB -> AB -> Bool aAndB2 ab1 ab2 | A <- ab1 , B <- ab2 = True | otherwise = False }}} works perfectly fine. Note, that if I indent the comma a bit in aAndB, the following will parse correctly: {{{#!hs aAndB :: AB -> AB -> Bool aAndB ab1 ab2 = if | A <- ab1 , B <- ab2 -> True | otherwise -> False }}} Of course, this is far from a major issue, but I thought it would probably be beneficial to report the issue nonetheless. It also looks likely less neat with the comma indented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 12:17:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 12:17:13 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.7f2ba957a5ca28e0b15a1ae6fa55e446@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): I'm very glad to see full laziness getting some attention. I've been aware of its deleterious effects for some time and have tried to spread awareness of it: * https://mail.haskell.org/pipermail/haskell- cafe/2013-February/106603.html * https://mail.haskell.org/pipermail/haskell- cafe/2015-December/122526.html * https://www.mail-archive.com/haskell-cafe at haskell.org/msg107101.html I have even asked whether it is an optimization worth performing at all, though I conclude that it is: * https://stackoverflow.com/questions/35115172/why-is-full-laziness-a -default-optimization/35115664 The full laziness transformation causes a lot of headaches and something ''really'' needs to be done about it. However I do not think this suggestion is the right approach. Why not tweak the transformation so that it only fires in cases that are guaranteed not to lead to memory leaks? That could be as simple as only hoisting bindings of monomorphic non-recursive datatypes. The proposed `nofloat` keyword is just adding additional complexity over a transformation which itself is introducing too much complexity. I'm very concerned about the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 12:32:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 12:32:29 -0000 Subject: [GHC] #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns In-Reply-To: <049.82402fb5138ab24c534e4411909c7bac@haskell.org> References: <049.82402fb5138ab24c534e4411909c7bac@haskell.org> Message-ID: <064.0733f1f986f1ad59133eab0ae08121af@haskell.org> #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns -------------------------------------+------------------------------------- Reporter: ahmadsalim | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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 goldfire): * status: new => closed * resolution: => invalid Comment: This is by design. Note that the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #multi-way-if-expressions manual] says that a multi-way `if` introduces a layout context. This is unlike normal pattern guards, which do not need layout for disambiguation of nesting. Personally, I've never liked this design choice, but I don't have a better one to suggest (then or now). There is some recent discussion [https://github.com/haskell/rfcs/pull/4 here]. In any case, there's no misbehavior here, so I am closing. Thanks very much for reporting, however! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 13:22:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 13:22:51 -0000 Subject: [GHC] #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns In-Reply-To: <049.82402fb5138ab24c534e4411909c7bac@haskell.org> References: <049.82402fb5138ab24c534e4411909c7bac@haskell.org> Message-ID: <064.d57ec2d4310aca914b05c28889730e41@haskell.org> #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns -------------------------------------+------------------------------------- Reporter: ahmadsalim | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | 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 ahmadsalim): Thanks for taking a look at it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 14:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 14:11:47 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.b8fabc81c6d04b94180797321129bac5@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:7 simonpj]: > I think that "noupdate" would require some careful thought. What if I say > {{{ > f x = if ... then Yield blah x > else ... > }}} > Then the "noupdate" second field of `Yield` is just the parameter to `f`. Does the caller have to know not to build an updatable thunk. I guess we would instruct the demand analysis to believe that `Yield` has strictness signature `` and thus this once-used information will be propagated, at least to the extent possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 17:29:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 17:29:14 -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.cbbe1339bbc4816645e968651f239e1e@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): This works for me on HEAD (f21eedbc223c33b71ba323a44c25fcd512f61b52) All of the below were tried with -O0, -O1, and -O2 ghc 8.0.1 (doesn't support LLVM 3.8) and llvm 3.7 gives NaN HEAD with 3.7 also gives NaN HEAD with 3.8 gives NaN So at least it's OK going forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 17:30:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 17:30:28 -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.1d9e18877039dbe8eb782e86b6521f42@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: | -------------------------------------+------------------------------------- Changes (by tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 18:26:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 18:26:14 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.f3c5dfbfbce0bdc08ba9bd8afb6d1323@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): It gives me: {{{ C:\test>some.exe +RTS -N --numa some.exe: --numa: OS reports NUMA is not available ... }}} Without --numa flag it runs only on half of the available cores. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 18:27:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 18:27:26 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.395dc1a974ec05285738404d47c02a16@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Side question is: isn't it possible to autodetect NUMA and to run on multiple groups by default, so programs perform at maximum. And if someone need to constrain it - to apply an option for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 18:31:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 18:31:31 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.6413d0c601ed595833963cdc1b9c61a1@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I accidentally build the one without NUMA support, however you shouldn't need it to be able to use all the cores. The NUMA support in GHC is limited to 16 NUMA nodes atm. Did you also specify -qa? without the scheduler doesn't do much unless you're doing setting the affinity manually in code? so `+RTS -N -qa`. If that still doesn't work then could you compile your program with `-debug` and run with `-Ds` and pipe this output to a file. just a few seconds is enough. This will help me see what the scheduler is doing. You can also use this to see how many cores it detected and in what configuration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 18:32:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 18:32:57 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.a7b653064fa30e6c394c08b9ab700f56@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): And also, I assume you already compiled your program with `-threaded` ? About the autodetect, yes it should be, but I don't think it's always wanted. Which is probably why they made it an opt-in feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 20:58:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 20:58:56 -0000 Subject: [GHC] #12232: Opportunity to do better in register allocations In-Reply-To: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> References: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> Message-ID: <062.eed1c9c5c76b73ff61d3cd870a8b9c9c@haskell.org> #12232: Opportunity to do better in register allocations -------------------------------------+------------------------------------- Reporter: harendra | 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: #12231 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 23:20:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 23:20:48 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.e224ad9bf708f39058d8923d76a7a7d8@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Replying to [comment:9 tomjaguarpaw]: > I'm very glad to see full laziness getting some attention (...) I have even asked whether it is an optimization worth performing at all, though I conclude that it is: > > * https://stackoverflow.com/questions/35115172/why-is-full-laziness-a -default-optimization/35115664 Yup, I cite this in the blog post :) > However I do not think this suggestion is the right approach. (...) The proposed `nofloat` keyword is just adding additional complexity over a transformation which itself is introducing too much complexity. I'm very concerned about the idea. I agree that it would be preferable not to "program the optimizer" when writing Haskell code. That's another reason in fact why I prefer `noupdate` over `nofloat`, beacuse actually `noupdate` goes beyond full laziness. Consider this example from the blog post: {{{#!hs retry :: IO a -> IO a retry io = catch io (\(_ :: SomeException) -> retry io) main :: IO () main = retry $ ni_mapM_ print [1..1000000] }}} This program has a memory leak, but it's nothing to do with full laziness here. Now admittedly we could turn this into a full laziness issue by giving the argument to `retry` a dummy unit argument or something like that, so that we write {{{#!hs retry :: (() -> IO a) -> IO a retry io = catch (io ()) (\(_ :: SomeException) -> retry io) main :: IO () main = retry $ \() -> ni_mapM_ print [1..1000000] }}} or something like that, but then you would have to do that in every single function that duplicates IO actions (think `forever`, `replicateM_`, etc.) Instead, we could mark that list as `noupdate` and the memory leak would be gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 29 23:49:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Sep 2016 23:49:01 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.59bc0af6e9ce785dad7066ffbbd5eb44@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): Edsko, it seems to me that the problem that you mention here is quite easy to avoid. {{{#!hs main :: IO () main = retry $ return () >>= \_ -> ni_mapM_ print [1..1000000] }}} is sufficient, unless I am very much mistaken. With such a construction the list is allocated afresh for each invocation of the `IO` action. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 00:59:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 00:59:50 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.c1c2515fbe587e3cf3211abd44e73dcd@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by chak): * cc: chak (removed) * cc: chak@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 02:10:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 02:10:52 -0000 Subject: [GHC] #12642: reports incorrect target arch on mips64el Message-ID: <044.0b40254e93dd332c26d7c9550507a767@haskell.org> #12642: reports incorrect target arch on mips64el -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: mips | Type of failure: Debugging | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Please handle "mips64el" in GHC_CONVERT_CPU and FPTOOLS_SET_HASKELL_PLATFORM_VARS. Having "ArchMipseb" show up in ghc --info output is confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 02:26:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 02:26:41 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.0dde3636677800672b1b3124a3ee34c9@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Fair enough, that's an easier workaround. But the idea is to have something a little more compositional. For example, in the case of conduits, we probably ''never'' want to share a conduit value. So it would be great if we could annotate the conduit constructors with a noupdate annotation, and then users of the conduit library don't have to worry about this problem anymore. After all, in the list example, it's not obvious that {{{#!hs main :: IO () main = retry $ runConduit someConduit }}} has a space leak; even less so when that retry and the runConduit are in different places: {{{#!hs go :: IO () go = runConduit someConduit main :: IO () main = retry go }}} We'd need to have the foresight to write {{{#!hs main :: IO () main = retry $ return () >>= \_ -> go }}} The situation really is very close to strictness; do we want to make sure every single function using a datatype has the right seqs in the right place, or we just put some strictness annotations on the datatype? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 04:21:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 04:21:49 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.1515ad6da1bb4d96ec5af4038f0cc87a@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by WrenThornton): It looks like that fix only works for the default optimization level. Passing -O2 reintroduces the problem with `retry` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 04:31:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 04:31:17 -0000 Subject: [GHC] #12643: class declaration works in ghci, but not in a file Message-ID: <044.c716074b77b054579b7d856a68677406@haskell.org> #12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | 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 ghci session prints no errors: {{{ > :set -XStandaloneDeriving -XDeriveGeneric > import GHC.Generics > import Control.Monad.Except > deriving instance Generic (ExceptT e m a) > class F a where f :: Rep (Except String a) x }}} However, when I transfer this to a file: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Control.Monad.Except deriving instance Generic (ExceptT e m a) class F a where f :: Rep (Except String a) x }}} I get a mysterious error: {{{ test.hs:6:17: error: • Couldn't match type ‘Rep (Except String a0)’ with ‘Rep (Except String a)’ Expected type: Rep (Except String a) x Actual type: Rep (Except String a0) x NB: ‘Rep’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall a. F a => forall x. Rep (Except String a) x In the class declaration for ‘F’ }}} If I turn on -fdefer-type-errors, I can verify that the type family indeed reduces far enough for a and x to be arguments to injective types, so I believe GHC should not consider this an error: {{{ > :set -XRankNTypes > :kind! forall a x. Rep (Except String a) x forall a x. Rep (Except String a) x :: * = D1 ('MetaData "ExceptT" "Control.Monad.Trans.Except" "transformers-0.5.2.0" 'True) (C1 ('MetaCons "ExceptT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Data.Functor.Identity.Identity (Either [Char] a))))) x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 05:24:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 05:24:15 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.8f7eb376251cf3d96f5ab2c57974c170@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): > The member function `lift` embeds a computation in monad ''m'' into a monad ''t m''. Furthermore, we expect a monad transformer to ''add'' features, without changing the nature of an existing omputation. We introduce ''Monad Transformer Laws'' to capture the properties of `lift`: > > > {{{ > lift · unit_m > = unit_tm > > lift (m `bind_m` k) > = lift m `bind_tm` (lift · k) > }}} > > The above laws say that lifting a null computation results in a null computation, and that lifting a sequence of computations is equivalent to first lifting them individually, and then combining them in the lifted monad. > > — [http://haskell.cs.yale.edu/wp-content/uploads/2011/02/POPL96-Modular- interpreters.pdf Monad Transformers and Modular Interpreters] This effectively uses a different formulation of `MonadTrans` with a `Monad` constraint on ''t m'' (see [https://www.reddit.com/r/haskell/comments/50rxci/edward_kmett_monad_homomorphisms_google_tech_talk/ this]) {{{#!hs class (Monad m, Monad (t m)) => MonadT t m where lift :: m a -> (t m) a }}} It preserves `pure` if these functions are equal {{{#!hs pure1, pure2 :: forall t m a. MonadT t m => a -> (t m) a pure1 = lift . pure @m pure2 = pure @(t m) }}} and with infix type application we can express the preservation of ''bind'' with the following two equations: {{{#!hs bind1, bind2 :: forall t m a b. MonadT t m => (a -> m b) -> (m a -> (t m) b) bind1 k m = lift (m >>= @m k) bind2 k m = lift m >>= @(t m) (lift . k) }}} without awkwardly infixiaticate it {{{#!hs bind1 k m = lift ((>>=) @m m k) bind2 k m = (>>=) @(t m) (lift m) (lift . k) }}} ---- We can of course be even more explicit {{{#!hs bind1, bind2 :: forall t m a b. MonadT t m => (a -> m b) -> (m a -> (t m) b) bind1 k m = lift @t @m @b (m >>= @m @a @b k) bind2 k m = lift @t @m @a m >>= @(t m) @a @b (lift @t @m @b . k) }}} whatevs {{{#!hs lift_ :: forall tm a t m. ((t m ~ tm), MonadT t m) => m a -> t m a lift_ = lift bind1, bind2 :: forall t m a b. Monad_ t m => (a -> m b) -> (m a -> (t m) b) bind1 k m = lift_ @(t m) @b (m >>= @m @a @b k) bind2 k m = lift_ @(t m) @a m >>= @(t m) @a @b (lift_ @(t m) @b . k) }}} ---- Similarly we can write down the laws for other monad morphisms: {{{#!hs foo1, foo2 :: forall m a. MonadIO m => a -> m a foo1 = pure @m foo2 = liftIO . pure @IO bind1, bind2 :: forall m a b. MonadIO m => (a -> IO b) -> (IO a -> m b) bind1 k m = liftIO ((>>=) @IO m k) bind2 k m = (>>=) @m (liftIO m) (liftIO . k) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 06:54:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 06:54:19 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.d02a8ff30c50292039bfa7082af2bb81@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | 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 Iceland_jack): What about where `|` starts a guard? This parses just fine {{{#!hs f = \case True | False -> ... }}} One option is to mandate parentheses in that case (`(True | False) -> ...`) or to use some messier syntax `:|`, `:|:` ... I don't think or- patterns are common enough that will matter greatly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 07:16:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 07:16:09 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.0afaa016b997f02cfa6c1478e5e3d58a@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): Edsko, I'm a bit puzzled. For the case of conduits, isn't it enough to hide things behind lambdas in the definition of the Pipe type? Wren, sure, but Edsko's original claim is that this isn't a full laziness issue. My example brings it back to being a full laziness issue indeed. My contention is that even given Edsko's example it still makes more sense to fix the full laziness transformation than add a magic word. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 07:16:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 07:16:51 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.553e4eb9cb54dd0bd9ecf9a0d741cc16@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): > Edsko, I'm a bit puzzled. For the case of conduits, isn't it enough to hide things behind lambdas in the definition of the Pipe type? That is, "enough module full laziness". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 07:46:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 07:46:00 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.1e9581f4dd553e4de5bc6753392fe6f3@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Replying to [comment:15 tomjaguarpaw]: > Edsko, I'm a bit puzzled. For the case of conduits, isn't it enough to hide things behind lambdas in the definition of the Pipe type? > Hmmm, yes. I think it's true that if full laziness is disabled everywhere and for everyone (to be precise, in every module defining conduits), then it probably suffices. But I'm not sure quite how realistic that is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 07:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 07:50:46 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.6b1c12756d9b9b83e6799a548ccc68c2@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): It looks like this has been fixed in HEAD, but not on the ghc-8.0 branch. I'm going to do a bisect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 07:52:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 07:52:26 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.19490d0fe878b6223a54c1784c9ecf7d@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): This is why my suggestion is ''exactly'' to tweak the conditions when full laziness fires! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 08:44:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 08:44:48 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.f2a0736f4357d3fc8973c1b00199065b@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm beginning to get glimmers of understanding about this no-update thing. Consider {{{ t1 = [1..n] vs t2 = \_ -> [1..n] vs t3 = let x = [1..n] in \_ -> x }}} Note that * If we use `t1` in a shared context like `sum t1 / length t1`, we'll end up materialising the whole list. * For `t2`, we'd get `sum (t2 ()) / length (t2 ())`, and now the list is computed twice rather than duplicated. Note that `t1` and `t2` have different types of course. * Then `t3` is the result of applying the full laziness transformation to `t2`, and its space behaviour is back to that of `t1`. Reflections: * I think that this "noupdate" pragma is intended to achieve an effect like `t2`, but more conveniently, without changing types. Correct? * I think (but am not sure) that you intend to use this only for one-shot thunks, where (unlike the sum/count example) the thunk is evaluated only once. In which case it would often be discarded after being evaluated, in which case where does the leak come from. A small, concrete example would be jolly useful. * Notice how important it is that in `t2` the lambda ''syntactically encloses'' the leaky computation. Otherwise you get `t3`. My conclusion from this is that if you want a pragma on a data constructor, that the pragma only guarantees to affect the syntactic argument. Thus {{{ let x = in Yield o x vs Yield o }}} The latter would "work" (i.e. `` would be wrapped in a non- updatable thunk); but the former might not. I say "might not" rather "would not" because cardinality analysis might propagate the one-shot info to `x`. But that would be a "best-efforts" thing on which one might not like to rely. Would syntactic enclosure be enough in your application? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 09:04:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 09:04:22 -0000 Subject: [GHC] #12644: Lack of instantiation in GHC 8.0.1 Message-ID: <046.41bafaad0668e9735fc5b13397fd0e20@haskell.org> #12644: Lack of instantiation in GHC 8.0.1 -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider {{{ data T a = T1 Int instance Show (T a) where show (T1 x) = show x t1 :: T a t1 = T1 1 f :: String f = show t1 }}} This should typecheck fine. The `a` in data type `T` is phantom, but we often use phantom types. But it isn't with GHC 8.0.1: {{{ • No instance for (Show (forall a. T a)) arising from a use of ‘show’ • In the expression: show t1 In an equation for ‘f’: f = show t1 }}} The problem is in the lack of instantation of `t1` in the argument of `show`. I'm fixing this, but I wanted to make a ticket to exhibit it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 09:07:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 09:07:29 -0000 Subject: [GHC] #12644: Lack of instantiation in GHC 8.0.1 In-Reply-To: <046.41bafaad0668e9735fc5b13397fd0e20@haskell.org> References: <046.41bafaad0668e9735fc5b13397fd0e20@haskell.org> Message-ID: <061.8c5349efd4876e6ca19a162053ebe78a@haskell.org> #12644: Lack of instantiation in GHC 8.0.1 -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -3,0 +3,2 @@ + {-# LANGUAGE ImpredicativeTypes #-} + @@ -24,1 +26,1 @@ - The problem is in the lack of instantation of `t1` in the argument of + The problem is in the lack of instantiation of `t1` in the argument of @@ -27,0 +29,3 @@ + Admittedly it only happens with `-XImpredicativeTypes`, but that flag + should never make a legal program fail! + New description: Consider {{{ {-# LANGUAGE ImpredicativeTypes #-} data T a = T1 Int instance Show (T a) where show (T1 x) = show x t1 :: T a t1 = T1 1 f :: String f = show t1 }}} This should typecheck fine. The `a` in data type `T` is phantom, but we often use phantom types. But it isn't with GHC 8.0.1: {{{ • No instance for (Show (forall a. T a)) arising from a use of ‘show’ • In the expression: show t1 In an equation for ‘f’: f = show t1 }}} The problem is in the lack of instantiation of `t1` in the argument of `show`. Admittedly it only happens with `-XImpredicativeTypes`, but that flag should never make a legal program fail! I'm fixing this, but I wanted to make a ticket to exhibit it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 10:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 10:26:59 -0000 Subject: [GHC] #12643: class declaration works in ghci, but not in a file In-Reply-To: <044.c716074b77b054579b7d856a68677406@haskell.org> References: <044.c716074b77b054579b7d856a68677406@haskell.org> Message-ID: <059.c918b1f7cf43d7e47a857a21309bd2ee@haskell.org> #12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | 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): Crumbs. This is another variation of #11348, and its as-yet-unsolved cousin #12088. In this case, we must type check in this order: 1. `deriving instance Generic (ExceptT e m a)`. This generates a `type instance Rep (Except e m a) = ...` declaration, for `Generic`'s associated type `Rep`. 2. `class F a where ...`. We must do this second because `f`'s type can be seen to be unambiguous only after expanding the call to `Rep`. However the fix to #11348 arranges to interleave `type instance` declarations with type/class decls; but `deriving instance` declarations are still left to the end. The fix is, I think, to include `deriving instance` decls in the interleaving. Workaround for now: make the staging explicit with a degenerate Template Haskell splice, thus: {{{ deriving instance Generic (ExceptT e m a) $( return [] ) -- Degenerate splice class F a where f :: Rep (Except String a) x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 10:57:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 10:57:50 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.588657d4350e8c97ade31df2248d2828@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jpbernardy): As it turns out, we currently have a proposal on the table which is capable of expressing where sharing should not occur, in a principled way, by using types. This page sums up how it may play out in Edsko's example. https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Examples#Controllingsharingfulllaziness -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:06:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:06:24 -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.bcfcff6d544a2981b131f38881be2e30@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Changes (by harendra): * cc: harendra (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:14:13 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.7b711eaced0b1007fffd1d3546f6d145@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): {{{ C:\test>some +RTS -N -qa some: SetThreadGroupAffinity: The parameter is incorrect. some: SetThreadGroupAffinity: The parameter is incorrect. }}} hm, much better - it went to 90%, i.e. almost all the cores were taken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:15:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:15:53 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.6f15606428d514f6c73e9a4e62b25889@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point Jean-Phillipe. I had not quite made the connection before, thank you. The linear-types discussion is at a fairly early stage, but it does suggest that we should not go far with this "noupdate" stuff just yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:19:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:19:14 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.422091800793e0c673db3e1ab31538fd@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Yes, it is compiled like that: {{{ stack ghc -- -threaded -debug -rtsopts some.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:22:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:22:00 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.e7bc76deea94d221e9f5d3fe56fe3510@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): About autodetection I think that in most cases will be wanted (to use all processors available) and not useing all is much more exceptional. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:54:17 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.b66f06514d5ff9ac6437951f77fdac43@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- 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 Simon Peyton Jones ): In [changeset:"66a8c194520aadcaa0482736f3fdd4d2f31a5586/ghc" 66a8c19/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="66a8c194520aadcaa0482736f3fdd4d2f31a5586" Fix a bug in occurs checking 1. Trac #12593 exposed a long-standing bug in the occurs checking machinery. When unifying two type variables a ~ b where a /= b, we were assuming that there could be no occurs-check error. But there can: 'a' can occur in b's kind! When the RHS was a non-tyvar we used occurCheckExpand, which /did/ look in kinds, but not when the RHS was a tyvar. This bug has been lurking ever since TypeInType, maybe longer. And it was present both in TcUnify (the on-the-fly unifier), and in TcInteract. I ended up refactoring both so that the tyvar/tyvar path naturally goes through the same occurs-check as non-tyvar rhss. It's simpler and more robust now. One good thing is that both unifiers now share TcType.swapOverVars TcType.canSolveByUnification previously they had different logic for the same goals 2. Fixing this bug exposed another! In T11635 we end up unifying (alpha :: forall k. k->*) ~ (beta :: forall k. k->*) Now that the occurs check is done for tyvars too, we look inside beta's kind. And then reject the program becuase of the forall inside there. But in fact that forall is fine -- it does not count as impredicative polymoprhism. See Note [Checking for foralls] in TcType. 3. All this fuss around occurrence checking forced me to look at TcUnify.checkTauTvUpdate and TcType.occurCheckExpand There's a lot of duplication there, and I managed to elminate quite a bit of it. For example, checkTauTvUpdate called a local 'defer_me'; and then called occurCheckExpand, which then used a very similar 'fast_check'. Things are better, but there is more to do. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:54:17 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.1e5bbe8092743338c97a6b2c015e1617@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2fbfbca2d12a8e9a09627529cf4f8284b19023ff/ghc" 2fbfbca2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fbfbca2d12a8e9a09627529cf4f8284b19023ff" Fix desugaring of pattern bindings (again) This patch fixes Trac #12595. The problem was with a pattern binding like !x = e For a start it's silly to match that pattern and build a unit tuple (the General Case of mkSelectorBinds); but that's what was happening because the bang fell through to the general case. But for a variable pattern building any auxiliary bindings is stupid. So the patch introduces a new case in mkSelectorBinds for variable patterns. Then it turned out that if 'e' was a plain variable, and moreover was imported GlobalId, then matchSinglePat made it a /bound/ variable, which should never happen. That ultimately caused a linker error, but the original bug was much earlier. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:54:17 -0000 Subject: [GHC] #12616: type synonyms confuse generalized newtype deriving role checking In-Reply-To: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> References: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> Message-ID: <065.237748009c13dd15d1be38db71a068ad@haskell.org> #12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: generalized | newtype deriving roles rankntypes 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:"b612da667fe8fa5277fc78e972a86d4b35f98364/ghc" b612da6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b612da667fe8fa5277fc78e972a86d4b35f98364" Fix impredicativity (again) This patch fixes Trac #12616. Dignosis. In TcUnify.tc_sub_type_ds we were going to some trouble to support co- and contra-variance even for impredicative types. With -XImpredicativeTYpes, this allowed a unification variable to be unified with a polytype (probably wrongly) and that caused later trouble in the constraint solver, where -XImpredicativeTypes was /not/ on. In effect, -XImpredicativeTypes can't be switched on locally. Why did we want ImpredicativeTypes locally? Because the program generated by GND for a higher-rank method involved impredicative instantation of 'coerce': op = coerce op -- where op has a higher rank type See Note [Newtype-deriving instances] in TcGenDeriv. Cure. 1. It is ghastly to rely on ImpredicativeTypes (a 100% flaky feature) to instantiate coerce polymorphically. Happily we now have Visible Type Application, so I've used that instead which should be solid and reliable. 2. I deleted the code in tc_sub_type_ds that allows the constraint solver to "look through" a unification variable to find a polytype. That used to be essential in the days of ReturnTv, but it's utterly unreliable and should be consigned to the dustbin of history. (We have ExpType now for the essential uses.) Tests involving ImpredicativeTypes are affected, but I'm not worried about them... it's advertised as a feature you can't rely on, and I want to reform it outright. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:38:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:38:44 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.e5e648b2412479e0cba3c1754b7d03fd@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | deSugar/should_run/T12595 Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => deSugar/should_run/T12595 Comment: Thanks for such a nice small test case! Ben: worth merging this if it's trouble-free -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:41:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:41:52 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.4a6a6c5c6ecb280556efcec23cd82868@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge 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: | polykinds/T12593 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T12593 * status: new => merge Comment: Thanks for a great example. Ben: this is a relatively big patch. I'm 90% confident it's ok, and it certainly validates, but it's uncomfortably large to merge into a patch release. I'm inclined to merge it none the less, but be prepared to back away if smoke-testing the release candidate shows any problems. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:44:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:44:45 -0000 Subject: [GHC] #12645: 7.10.3 porting feedback Message-ID: <043.a9546bfd846564c9c150c558f418e4b8@haskell.org> #12645: 7.10.3 porting feedback -------------------------------------+------------------------------------- Reporter: jhpb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Installing GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have to run GHC on older LINUX versions and this requires patches. I thought I would feed these back so they can be rolled into an official release. The particular release I build on is RHEL 3 and the changes have persisted over several years and are due to lack of "configure" tests for such an old LINUX I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:45:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:45:22 -0000 Subject: [GHC] #12616: type synonyms confuse generalized newtype deriving role checking In-Reply-To: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> References: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> Message-ID: <065.86ac50f3cc1d381eddfffca9bbf1ece0@haskell.org> #12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: goldfire Type: bug | Status: merge Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: generalized | newtype deriving roles rankntypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T12616 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => deriving/should_compile/T12616 Comment: Great bug report thank you. Although the patch looks large it isn't really. But it ''does'' change the behaviour of GHC with `-XImpredicativeTypes`. Since we don't advertise any particular behaviour, that might seem OK. Or someone might complain. Still, I'm inclined to merge the change to the 8.0 branch because it makes the compiler more stable and predictable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:48:56 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.decb4a9ae4c3d8ae3d6cffddea80aed5@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): The intent of this issue was to provide an alternative `stacked` db composing policy in addition to the default `union` composing policy. Though, as you suggested, it can be implemented in terms of existing primitives by first specifying a list of dbs and then explicitly specifying the overriding packages using `-package pkg-x.y.z` flags in an environment file. That might mean specifying a lot of `-package` flags in the environment file though. We will have to explicitly identify and specify all the packages which override other packages in any of the lower dbs in the db stack. I guess it should do the job if we do not want to have a built-in stacked db policy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:50:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:50:38 -0000 Subject: [GHC] #12644: Lack of instantiation in GHC 8.0.1 In-Reply-To: <046.41bafaad0668e9735fc5b13397fd0e20@haskell.org> References: <046.41bafaad0668e9735fc5b13397fd0e20@haskell.org> Message-ID: <061.92e2d08a1c9dd3c6ad64da8ee229e89f@haskell.org> #12644: Lack of instantiation in GHC 8.0.1 -------------------------------------+------------------------------------- Reporter: simonpj | 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: | typecheck/should_compile/T12644 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T12644 * resolution: => fixed Comment: Fixed as part of {{{ commit b612da667fe8fa5277fc78e972a86d4b35f98364 Author: Simon Peyton Jones Date: Sun Sep 25 15:50:18 2016 +0100 Fix impredicativity (again) This patch fixes Trac #12616. Dignosis. In TcUnify.tc_sub_type_ds we were going to some trouble to support co- and contra-variance even for impredicative types. With -XImpredicativeTYpes, this allowed a unification variable to be unified with a polytype (probably wrongly) and that caused later trouble in the constraint solver, where -XImpredicativeTypes was /not/ on. In effect, -XImpredicativeTypes can't be switched on locally. Why did we want ImpredicativeTypes locally? Because the program generated by GND for a higher-rank method involved impredicative instantation of 'coerce': op = coerce op -- where op has a higher rank type See Note [Newtype-deriving instances] in TcGenDeriv. Cure. 1. It is ghastly to rely on ImpredicativeTypes (a 100% flaky feature) to instantiate coerce polymorphically. Happily we now have Visible Type Application, so I've used that instead which should be solid and reliable. 2. I deleted the code in tc_sub_type_ds that allows the constraint solver to "look through" a unification variable to find a polytype. That used to be essential in the days of ReturnTv, but it's utterly unreliable and should be consigned to the dustbin of history. (We have ExpType now for the essential uses.) Tests involving ImpredicativeTypes are affected, but I'm not worried about them... it's advertised as a feature you can't rely on, and I want to reform it outright. compiler/hsSyn/HsUtils.hs | 8 ++++---- compiler/typecheck/TcDeriv.hs | 2 ++ compiler/typecheck/TcGenDeriv.hs | 61 +++++++++++++++++++++++++++++++------------------------------ compiler/typecheck/TcUnify.hs | 30 ++++++++---------------------- testsuite/tests/boxy/Base1.hs | 35 +++++++++++++++++++---------------- testsuite/tests/boxy/T2193.hs | 2 ++ testsuite/tests/boxy/all.T | 4 ++-- testsuite/tests/deriving/should_compile/T12616.hs | 21 +++++++++++++++++++++ testsuite/tests/deriving/should_compile/all.T | 1 + testsuite/tests/deriving/should_fail/T4846.stderr | 4 ++-- testsuite/tests/typecheck/should_compile/T11319.hs | 3 +++ testsuite/tests/typecheck/should_compile/T12644.hs | 14 ++++++++++++++ testsuite/tests/typecheck/should_compile/all.T | 3 ++- testsuite/tests/typecheck/should_compile/tc211.hs | 3 +++ testsuite/tests/typecheck/should_compile/tc211.stderr | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- testsuite/tests/typecheck/should_fail/T10619.stderr | 18 ++++-------------- testsuite/tests/typecheck/should_fail/T2846b.stderr | 3 ++- testsuite/tests/typecheck/should_fail/T8428.stderr | 5 ++++- testsuite/tests/typecheck/should_fail/all.T | 2 +- testsuite/tests/typecheck/should_fail/tcfail016.stderr | 2 +- testsuite/tests/typecheck/should_fail/tcfail165.hs | 4 +++- testsuite/tests/typecheck/should_fail/tcfail165.stderr | 12 ++++++++++++ testsuite/tests/typecheck/should_fail/tcfail174.hs | 2 ++ testsuite/tests/typecheck/should_fail/tcfail174.stderr | 19 +++++++++++++------ 24 files changed, 230 insertions(+), 106 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 12:55:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 12:55:55 -0000 Subject: [GHC] #10740: Ensure that ticky, profiler, and GC allocation numbers agree In-Reply-To: <046.facae83a9f3a186a7ce58910a20dae6f@haskell.org> References: <046.facae83a9f3a186a7ce58910a20dae6f@haskell.org> Message-ID: <061.072dfe0e7a0abb542dde35362972be09@haskell.org> #10740: Ensure that ticky, profiler, and GC allocation numbers agree -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Testing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 13:00:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 13:00:04 -0000 Subject: [GHC] #12645: 7.10.3 porting feedback In-Reply-To: <043.a9546bfd846564c9c150c558f418e4b8@haskell.org> References: <043.a9546bfd846564c9c150c558f418e4b8@haskell.org> Message-ID: <058.744357b0145467f38c008f971e68ad51@haskell.org> #12645: 7.10.3 porting feedback ------------------------------------------+------------------------------ Reporter: jhpb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Changes (by jhpb): * Attachment "ghc-feedback.txt" added. patches for building 7.10.3 under RHEL3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 13:23:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 13:23:28 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.44b6c9e61e386d1aa21f4c7f40001f9c@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | 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 osa1): Good point. I think we may require parens around or patterns. So the parsing rule would be like: {{{ pat ::= '(' or-pattern-or-pat ')' | ... (where none of the productions accept '|') or-pattern-or-pat ::= pat '|' or-pattern-or-pat | pat }}} I personally dislike messier syntax like `:|` and `:|:`, because I'm hoping to use this syntax instead of `_` patterns, and I may need to chain a lot of constructors. {{{ f (T1 ...) = ... f (T2{} | T3{} | T4{}) = ... }}} vs {{{ f (T1 ...) = ... f (T2{} :|: T3{} :|: T4{}) = ... }}} Second one looks really bad IMHO. In addition, `:|:` is a valid operator syntax, but `|` is a reserved operator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 15:10:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 15:10:51 -0000 Subject: [GHC] #12646: Type family reification misses a kind signature Message-ID: <047.cba91014c4d60775bdcbc80a5671d922@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 | 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: -------------------------------------+------------------------------------- If I have {{{ type family F (a :: k) :: * where F (a :: * -> *) = Int F (a :: k) = Char }}} and then print out the reification of `F`, I get (when pretty-printed) {{{ type family Ghci1.F (a_0 :: k_1) :: * where Ghci1.F a_2 = GHC.Types.Int Ghci1.F a_3 = GHC.Types.Char }}} Note that the kind signature on the first variable is dropped. This is '''not''' the fault of the pretty-printer, as the kind signature is dropped in the AST as well. The reifier should include the kind signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 15:15:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 15:15:48 -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.68a6e0a4d0a79f0ccabdbd95c07e05cc@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 16:45:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 16:45:42 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.1efe8002952b5d7a37c8989862cdc03a@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To be clear, while I agree that this is an important issue, 8.0.2 needs to leave the dock at some point soon as 8.2.1 is on the horizon. I'm okay with pushing the 8.0.2 release off by up to two weeks for this, but at that point I will really need to release it regardless of whether this issue is fixed. I am working with Oleg to get our OS X test box running Sierra, but I can't make any promises about being able to fix this myself. It would be quite helpful if someone could summarize the proposed solution. Even better, it would be amazing if someone with an affected machine and knowledge of dynamic linking on OS X (a small set, I know!) could take ownership of this issue and carry it to solution. This may be darchon, but I'm a bit worried what might happen if he doesn't have time to finish, October 10th arrives, and we have no solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 16:51:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 16:51:43 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.7a02fe127da0e6253c15c746fddabb42@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I would propose that we treat at least the 2-3 most recent OS X releases as "core tier 1" of our tier 1 Apple support. At least as an informal guide post? I'd say we really can't do that unless we have the ability to readily test these releases. In principle [[https://ghc.haskell.org/trac/ghc/wiki/Platforms#Tier1platforms|Tier 1 platforms]] are supposed to have a sponsor and some sort of regular testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 17:23:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 17:23:55 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.8b7eebee5366a172411b60caa6ba8e0b@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks for testing, I'm not really sure yet what's going on there. It does seem to correctly detect the configuration {{{ [*] Number of processor groups detected: 2 [*] Number of active processors in group 0 detected: 44 [*] Number of active processors in group 1 detected: 44 [*] Processor group map created [*] Cumulative active processors for group 0: 0 [*] Cumulative active processors for group 1: 44 }}} Two capabilities failed to be set: {{{ SetThreadGroupAffinity: The parameter is incorrect. }}} I'll see if I can figure out why. Though that's only 2 of 88. The final dump of threads is what has be confused, as it seems to indicate there are only 2 active threads. While the rest are all idle/blocked. Could you try again using my test program?: {{{ import Control.Concurrent import Control.Monad main = do ids <- replicateM 88 (forkIO $ print $ length $ primesToG 100000000000) spin spin = do threadDelay 1000 yield spin primesToG m = 2 : sieve [3,5..m] where sieve (p:xs) | p*p > m = p : xs | otherwise = p : sieve (xs `minus` [p*p, p*p+2*p..]) minus (x:xs) (y:ys) = case (compare x y) of LT -> x : minus xs (y:ys) EQ -> minus xs ys GT -> minus (x:xs) ys minus xs _ = xs }}} If it still doesn't get passed 50 I'll make a build with more verbose output so I can better trace the behavior. The program is a bit greedy so to kill it you'll have to kill the process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 19:30:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 19:30:13 -0000 Subject: [GHC] #12647: Can't capture improvement of functional dependencies Message-ID: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> #12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [http://www.diku.dk/~paba/pubs/files/serrano15haskell-paper.pdf Type Families with Class, Type Classes with Family] discusses [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70#pdf- instance-improvement instance improvement] with the example {{{#!hs class Collection c e | c -> e where empty :: c add :: e -> c -> c instance Collection [a] a where empty :: [a] empty = [] add :: a -> [a] -> [a] add = (:) }}} I wondered how to express that `x ~ Int` can be deduced from `Collection [Int] x` using improvement, I first attempted using the [https://hackage.haskell.org/package/constraints constraints] machinery: {{{#!hs data Dict c where Dict :: c => Dict c newtype a :- b = Sub (a => Dict b) }}} but I'm not able to construct a term of type `Collection [Int] x :- (Int ~ x)` proving that `Collection [Int] x` entails `Int ~ x`: {{{ ghci> Sub Dict :: Collection [Int] x :- (Int ~ x) :52:5: error: • Couldn't match type ‘x1’ with ‘Int’ arising from a use of ‘Dict’ ‘x1’ is a rigid type variable bound by an expression type signature: forall x1. Collection [Int] x1 :- Int ~ x1 at :52:13 • In the first argument of ‘Sub’, namely ‘Dict’ In the expression: Sub Dict :: Collection [Int] x :- (Int ~ x) In an equation for ‘it’: it = Sub Dict :: Collection [Int] x :- (Int ~ x) }}} Is this due to overlapping instances or something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 19:46:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 19:46:05 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b0253424335b190af46e0226120bfab3@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: TypeFamilies, | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018ghci, T6018ghcifail, | T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259, #10832, | Differential Rev(s): Phab:D202 #10833 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Use case of more complicated injectivity annotations from [http://www.diku.dk/~paba/pubs/files/serrano15haskell-paper.pdf Type Families with Class, Type Classes with Family], simulating the type class: {{{#!hs class Collection c e | c -> e where empty :: c add :: e -> c -> c }}} with a type family {{{#!hs data Defined = Yes | No type family IsCollection t e = (result :: Defined) | result t -> e }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 20:09:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 20:09:17 -0000 Subject: [GHC] #12648: Stack overflow when using monad-unlift Message-ID: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> #12648: Stack overflow when using monad-unlift -------------------------------------+------------------------------------- Reporter: nh2 | 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 Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found that with the following simple program I could make runghc/ghci crash with `*** Exception: stack overflow`: {{{ #!/usr/bin/env stack -- stack --resolver lts-7.1 --install-ghc runghc --package monad- unlift-0.2.0 {-# LANGUAGE FlexibleContexts #-} import Control.Monad.Trans.Unlift f :: (MonadBaseUnlift m IO) => m a f = do _ <- askUnliftBase return () }}} I'm not super sure if that's OK. Probably not; even if it does trigger an undecideable case, shouldn't ghc tell me about it instead of just crashing? The `monad-unlift` code used is here: https://github.com/fpco/monad- unlift/blob/adb7869adccc66247cbb1a6175277802e9c098e1/monad- unlift/Control/Monad/Trans/Unlift.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 20:13:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 20:13:55 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.5ec38ef9ac583f77085198630eede43f@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2554 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => D2554 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 20:28:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 20:28:47 -0000 Subject: [GHC] #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas Message-ID: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Currently the `SPECIALISE` pragma requires that the user repeat the entire type of a binding to instantiate its types. This is often needlessly verbose and quite tiresome. Instead, why not allow the user to write the desired type as an application with `TypeApplications`? For instance, currently we might write, {{{#!hs foldWithOptionsAndParser :: forall m params. ( MonadIO m, MonadMask m, ToRow params ) => FoldOptions -> RowParser row -> Connection -> Query -> params -> a -> (a -> row -> m a) -> m a foldWithOptionsAndParser opts parser conn template qs a f = ... {-# SPECIALISE foldWithOptionsAndParser :: FoldOptions -> RowParser row -> Connection -> Query -> params -> a -> (a -> row -> IO a) -> IO a #-} }}} Instead we might want to write, {{{#!hs {-# SPECIALISE foldWithOptionsAndParser @IO #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 20:31:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 20:31:38 -0000 Subject: [GHC] #12648: Stack overflow when using monad-unlift In-Reply-To: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> References: <042.64fc702f7ceb8c3f9f9373656fec25e1@haskell.org> Message-ID: <057.f35a948d72814bc7f1e5fe169f5fcb50@haskell.org> #12648: Stack overflow when using monad-unlift -------------------------------------+------------------------------------- Reporter: nh2 | 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 | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Aha, I made a simple mistake: I wrote `MonadBaseUnlift m IO` instead of `MonadBaseUnlift IO m`. I assume that's a result of `UndecidableSuperClasses` used at https://github.com/fpco/monad- unlift/blob/adb7869adccc66247cbb1a6175277802e9c098e1/monad- unlift/Control/Monad/Trans/Unlift.hs#L13. So, the remainder of this ticket is probably: Can we make GHC tell us what the problem here is (e.g. with a message like `Gave up trying to resolve ... something something` instead of the crash)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 30 11:06:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Sep 2016 11:06:12 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.2d817c435a65b3d9a2ca7cd3c7127c63@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): {{{ C:\test>some +RTS -N -qa -Ds 2780: created capset 0 of type 2 2780: created capset 1 of type 3 2780: cap 0: initialised 2780: assigned cap 0 to capset 0 2780: assigned cap 0 to capset 1 2780: cap 1: initialised 2780: assigned cap 1 to capset 0 2780: assigned cap 1 to capset 1 2780: cap 2: initialised 2780: assigned cap 2 to capset 0 2780: assigned cap 2 to capset 1 2780: cap 3: initialised 2780: assigned cap 3 to capset 0 2780: assigned cap 3 to capset 1 2780: cap 4: initialised 2780: assigned cap 4 to capset 0 2780: assigned cap 4 to capset 1 2780: cap 5: initialised 2780: assigned cap 5 to capset 0 2780: assigned cap 5 to capset 1 2780: cap 6: initialised 2780: assigned cap 6 to capset 0 2780: assigned cap 6 to capset 1 2780: cap 7: initialised 2780: assigned cap 7 to capset 0 2780: assigned cap 7 to capset 1 2780: cap 8: initialised 2780: assigned cap 8 to capset 0 2780: assigned cap 8 to capset 1 2780: cap 9: initialised 2780: assigned cap 9 to capset 0 2780: assigned cap 9 to capset 1 2780: cap 10: initialised 2780: assigned cap 10 to capset 0 2780: assigned cap 10 to capset 1 2780: cap 11: initialised 2780: assigned cap 11 to capset 0 2780: assigned cap 11 to capset 1 2780: cap 12: initialised 2780: assigned cap 12 to capset 0 2780: assigned cap 12 to capset 1 2780: cap 13: initialised 2780: assigned cap 13 to capset 0 2780: assigned cap 13 to capset 1 2780: cap 14: initialised 2780: assigned cap 14 to capset 0 2780: assigned cap 14 to capset 1 2780: cap 15: initialised 2780: assigned cap 15 to capset 0 2780: assigned cap 15 to capset 1 2780: cap 16: initialised 2780: assigned cap 16 to capset 0 2780: assigned cap 16 to capset 1 2780: cap 17: initialised 2780: assigned cap 17 to capset 0 2780: assigned cap 17 to capset 1 2780: cap 18: initialised 2780: assigned cap 18 to capset 0 2780: assigned cap 18 to capset 1 2780: cap 19: initialised 2780: assigned cap 19 to capset 0 2780: assigned cap 19 to capset 1 2780: cap 20: initialised 2780: assigned cap 20 to capset 0 2780: assigned cap 20 to capset 1 2780: cap 21: initialised 2780: assigned cap 21 to capset 0 2780: assigned cap 21 to capset 1 2780: cap 22: initialised 2780: assigned cap 22 to capset 0 2780: assigned cap 22 to capset 1 2780: cap 23: initialised 2780: assigned cap 23 to capset 0 2780: assigned cap 23 to capset 1 2780: cap 24: initialised 2780: assigned cap 24 to capset 0 2780: assigned cap 24 to capset 1 2780: cap 25: initialised 2780: assigned cap 25 to capset 0 2780: assigned cap 25 to capset 1 2780: cap 26: initialised 2780: assigned cap 26 to capset 0 2780: assigned cap 26 to capset 1 2780: cap 27: initialised 2780: assigned cap 27 to capset 0 2780: assigned cap 27 to capset 1 2780: cap 28: initialised 2780: assigned cap 28 to capset 0 2780: assigned cap 28 to capset 1 2780: cap 29: initialised 2780: assigned cap 29 to capset 0 2780: assigned cap 29 to capset 1 2780: cap 30: initialised 2780: assigned cap 30 to capset 0 2780: assigned cap 30 to capset 1 2780: cap 31: initialised 2780: assigned cap 31 to capset 0 2780: assigned cap 31 to capset 1 2780: cap 32: initialised 2780: assigned cap 32 to capset 0 2780: assigned cap 32 to capset 1 2780: cap 33: initialised 2780: assigned cap 33 to capset 0 2780: assigned cap 33 to capset 1 2780: cap 34: initialised 2780: assigned cap 34 to capset 0 2780: assigned cap 34 to capset 1 2780: cap 35: initialised 2780: assigned cap 35 to capset 0 2780: assigned cap 35 to capset 1 2780: cap 36: initialised 2780: assigned cap 36 to capset 0 2780: assigned cap 36 to capset 1 2780: cap 37: initialised 2780: assigned cap 37 to capset 0 2780: assigned cap 37 to capset 1 2780: cap 38: initialised 2780: assigned cap 38 to capset 0 2780: assigned cap 38 to capset 1 2780: cap 39: initialised 2780: assigned cap 39 to capset 0 2780: assigned cap 39 to capset 1 2780: cap 40: initialised 2780: assigned cap 40 to capset 0 2780: assigned cap 40 to capset 1 2780: cap 41: initialised 2780: assigned cap 41 to capset 0 2780: assigned cap 41 to capset 1 2780: cap 42: initialised 2780: assigned cap 42 to capset 0 2780: assigned cap 42 to capset 1 2780: cap 43: initialised 2780: assigned cap 43 to capset 0 2780: assigned cap 43 to capset 1 2780: cap 44: initialised 2780: assigned cap 44 to capset 0 2780: assigned cap 44 to capset 1 2780: cap 45: initialised 2780: assigned cap 45 to capset 0 2780: assigned cap 45 to capset 1 2780: cap 46: initialised 2780: assigned cap 46 to capset 0 2780: assigned cap 46 to capset 1 2780: cap 47: initialised 2780: assigned cap 47 to capset 0 2780: assigned cap 47 to capset 1 2780: cap 48: initialised 2780: assigned cap 48 to capset 0 2780: assigned cap 48 to capset 1 2780: cap 49: initialised 2780: assigned cap 49 to capset 0 2780: assigned cap 49 to capset 1 2780: cap 50: initialised 2780: assigned cap 50 to capset 0 2780: assigned cap 50 to capset 1 2780: cap 51: initialised 2780: assigned cap 51 to capset 0 2780: assigned cap 51 to capset 1 2780: cap 52: initialised 2780: assigned cap 52 to capset 0 2780: assigned cap 52 to capset 1 2780: cap 53: initialised 2780: assigned cap 53 to capset 0 2780: assigned cap 53 to capset 1 2780: cap 54: initialised 2780: assigned cap 54 to capset 0 2780: assigned cap 54 to capset 1 2780: cap 55: initialised 2780: assigned cap 55 to capset 0 2780: assigned cap 55 to capset 1 2780: cap 56: initialised 2780: assigned cap 56 to capset 0 2780: assigned cap 56 to capset 1 2780: cap 57: initialised 2780: assigned cap 57 to capset 0 2780: assigned cap 57 to capset 1 2780: cap 58: initialised 2780: assigned cap 58 to capset 0 2780: assigned cap 58 to capset 1 2780: cap 59: initialised 2780: assigned cap 59 to capset 0 2780: assigned cap 59 to capset 1 2780: cap 60: initialised 2780: assigned cap 60 to capset 0 2780: assigned cap 60 to capset 1 2780: cap 61: initialised 2780: assigned cap 61 to capset 0 2780: assigned cap 61 to capset 1 2780: cap 62: initialised 2780: assigned cap 62 to capset 0 2780: assigned cap 62 to capset 1 2780: cap 63: initialised 2780: assigned cap 63 to capset 0 2780: assigned cap 63 to capset 1 2780: cap 64: initialised 2780: assigned cap 64 to capset 0 2780: assigned cap 64 to capset 1 2780: cap 65: initialised 2780: assigned cap 65 to capset 0 2780: assigned cap 65 to capset 1 2780: cap 66: initialised 2780: assigned cap 66 to capset 0 2780: assigned cap 66 to capset 1 2780: cap 67: initialised 2780: assigned cap 67 to capset 0 2780: assigned cap 67 to capset 1 2780: cap 68: initialised 2780: assigned cap 68 to capset 0 2780: assigned cap 68 to capset 1 2780: cap 69: initialised 2780: assigned cap 69 to capset 0 2780: assigned cap 69 to capset 1 2780: cap 70: initialised 2780: assigned cap 70 to capset 0 2780: assigned cap 70 to capset 1 2780: cap 71: initialised 2780: assigned cap 71 to capset 0 2780: assigned cap 71 to capset 1 2780: cap 72: initialised 2780: assigned cap 72 to capset 0 2780: assigned cap 72 to capset 1 2780: cap 73: initialised 2780: assigned cap 73 to capset 0 2780: assigned cap 73 to capset 1 2780: cap 74: initialised 2780: assigned cap 74 to capset 0 2780: assigned cap 74 to capset 1 2780: cap 75: initialised 2780: assigned cap 75 to capset 0 2780: assigned cap 75 to capset 1 2780: cap 76: initialised 2780: assigned cap 76 to capset 0 2780: assigned cap 76 to capset 1 2780: cap 77: initialised 2780: assigned cap 77 to capset 0 2780: assigned cap 77 to capset 1 2780: cap 78: initialised 2780: assigned cap 78 to capset 0 2780: assigned cap 78 to capset 1 2780: cap 79: initialised 2780: assigned cap 79 to capset 0 2780: assigned cap 79 to capset 1 2780: cap 80: initialised 2780: assigned cap 80 to capset 0 2780: assigned cap 80 to capset 1 2780: cap 81: initialised 2780: assigned cap 81 to capset 0 2780: assigned cap 81 to capset 1 2780: cap 82: initialised 2780: assigned cap 82 to capset 0 2780: assigned cap 82 to capset 1 2780: cap 83: initialised 2780: assigned cap 83 to capset 0 2780: assigned cap 83 to capset 1 2780: cap 84: initialised 2780: assigned cap 84 to capset 0 2780: assigned cap 84 to capset 1 2780: cap 85: initialised 2780: assigned cap 85 to capset 0 2780: assigned cap 85 to capset 1 2780: cap 86: initialised 2780: assigned cap 86 to capset 0 2780: assigned cap 86 to capset 1 2780: cap 87: initialised 2780: assigned cap 87 to capset 0 2780: assigned cap 87 to capset 1 2780: allocated 88 more capabilities 2780: new worker task (taskCount: 1) [*] Number of processor groups detected: 2 [*] Number of active processors in group 0 detected: 44 [*] Number of active processors in group 1 detected: 44 [*] Processor group map created [*] Cumulative active processors for group 0: 0 [*] Cumulative active processors for group 1: 44 2780: new worker task (taskCount: 2) 2e28: cap 1: schedule() 2e28: giving up capability 1 2e28: freeing capability 1 2780: new worker task (taskCount: 3) 335c: cap 2: schedule() 335c: giving up capability 2 335c: freeing capability 2 2780: new worker task (taskCount: 4) 33bc: cap 3: schedule() 33bc: giving up capability 3 33bc: freeing capability 3 2780: new worker task (taskCount: 5) 2e3c: cap 4: schedule() 2e3c: giving up capability 4 2e3c: freeing capability 4 2780: new worker task (taskCount: 6) 2b2c: cap 5: schedule() 2780: new worker task (taskCount: 7) 34dc: cap 6: schedule() 34dc: giving up capability 6 34dc: freeing capability 6 754: cap 7: schedule() 754: giving up capability 7 754: freeing capability 7 2b2c: giving up capability 5 2b2c: freeing capability 5 2780: new worker task (taskCount: 8) 2780: new worker task (taskCount: 9) 2780: new worker task (taskCount: 10) 2780: new worker task (taskCount: 11) 26a8: cap 9: schedule() 26a8: giving up capability 9 26a8: freeing capability 9 2780: new worker task (taskCount: 12) 2780: new worker task (taskCount: 13) 2f44: cap 10: schedule() 2f44: giving up capability 10 2f44: freeing capability 10 17d8: cap 12: schedule() 17d8: giving up capability 12 17d8: freeing capability 12 242c: cap 8: schedule() 242c: giving up capability 8 242c: freeing capability 8 3ba8: cap 13: schedule() 3ba8: giving up capability 13 3ba8: freeing capability 13 2bc4: cap 11: schedule() 2bc4: giving up capability 11 2bc4: freeing capability 11 2780: new worker task (taskCount: 14) 2664: cap 14: schedule() 2780: new worker task (taskCount: 15) 2664: giving up capability 14 2664: freeing capability 14 2780: new worker task (taskCount: 16) 1694: cap 15: schedule() 1694: giving up capability 15 1694: freeing capability 15 2780: new worker task (taskCount: 17) 1cc8: cap 16: schedule() 2248: cap 17: schedule() 2248: giving up capability 17 2248: freeing capability 17 2780: new worker task (taskCount: 18) 1cc8: giving up capability 16 1cc8: freeing capability 16 2e88: cap 18: schedule() 2e88: giving up capability 18 2e88: freeing capability 18 2780: new worker task (taskCount: 19) 2780: new worker task (taskCount: 20) 185c: cap 19: schedule() 185c: giving up capability 19 185c: freeing capability 19 2780: new worker task (taskCount: 21) 2780: new worker task (taskCount: 22) 2780: new worker task (taskCount: 23) 2d6c: cap 21: schedule() 263c: cap 20: schedule() 263c: giving up capability 20 263c: freeing capability 20 b20: cap 23: schedule() b20: giving up capability 23 b20: freeing capability 23 2780: new worker task (taskCount: 24) 2d6c: giving up capability 21 2d6c: freeing capability 21 2780: new worker task (taskCount: 25) 2054: cap 24: schedule() 2054: giving up capability 24 2054: freeing capability 24 13ac: cap 25: schedule() 13ac: giving up capability 25 13ac: freeing capability 25 3b90: cap 22: schedule() 3b90: giving up capability 22 3b90: freeing capability 22 2780: new worker task (taskCount: 26) 25c4: cap 26: schedule() 25c4: giving up capability 26 25c4: freeing capability 26 2780: new worker task (taskCount: 27) 2288: cap 27: schedule() 2288: giving up capability 27 2288: freeing capability 27 2780: new worker task (taskCount: 28) 2780: new worker task (taskCount: 29) 2404: cap 28: schedule() 2780: new worker task (taskCount: 30) 275c: cap 29: schedule() 275c: giving up capability 29 275c: freeing capability 29 2cac: cap 30: schedule() 2cac: giving up capability 30 2cac: freeing capability 30 2404: giving up capability 28 2404: freeing capability 28 2780: new worker task (taskCount: 31) 2780: some: SetThreadGroupAffinity: The parameter is incorrect. new worker task (taskCount: 32) 2d4c: cap 31: schedule() 2d4c: giving up capability 31 2d4c: freeing capability 31 2780: new worker task (taskCount: 33) 131c: cap 32: schedule() 131c: giving up capability 32 131c: freeing capability 32 2780: new worker task (taskCount: 34) 1604: cap 33: schedule() 1604: giving up capability 33 1604: freeing capability 33 2780: new worker task (taskCount: 35) 1e94: cap 34: schedule() 1e94: giving up capability 34 1e94: freeing capability 34 2780: new worker task (taskCount: 36) 31a0: cap 35: schedule() 2780: new worker task (taskCount: 37) 3758: cap 36: schedule() 3758: giving up capability 36 3758: freeing capability 36 2758: cap 37: schedule() 2758: giving up capability 37 2758: freeing capability 37 31a0: giving up capability 35 31a0: freeing capability 35 2780: new worker task (taskCount: 38) 2780: new worker task (taskCount: 39) 3458: cap 38: schedule() 3458: giving up capability 38 3458: freeing capability 38 2780: new worker task (taskCount: 40) 2754: cap 39: schedule() 2754: giving up capability 39 2754: freeing capability 39 2780: new worker task (taskCount: 41) 2780: new worker task (taskCount: 42) 1b20: cap 40: schedule() 2c28: cap 41: schedule() 2c28: giving up capability 41 2c28: freeing capability 41 1b20: giving up capability 40 1b20: freeing capability 40 30e8: cap 42: schedule() 30e8: giving up capability 42 30e8: freeing capability 42 2780: new worker task (taskCount: 43) 2780: new worker task (taskCount: 44) 23e0: cap 43: schedule() 23e0: giving up capability 43 23e0: freeing capability 43 2780: new worker task (taskCount: 45) 2b94: cap 44: schedule() 2b94: giving up capability 44 2b94: freeing capability 44 2780: new worker task (taskCount: 46) 24ec: cap 45: schedule() 24ec: giving up capability 45 24ec: freeing capability 45 2780: new worker task (taskCount: 47) 239c: cap 46: schedule() 239c: giving up capability 46 239c: freeing capability 46 2780: new worker task (taskCount: 48) 284c: cap 47: schedule() 284c: giving up capability 47 284c: freeing capability 47 2780: new worker task (taskCount: 49) 2138: cap 48: schedule() 2138: giving up capability 48 2138: freeing capability 48 2780: new worker task (taskCount: 50) 2b68: cap 49: schedule() 2b68: giving up capability 49 2b68: freeing capability 49 2780: new worker task (taskCount: 51) 3228: cap 50: schedule() 3228: giving up capability 50 3228: freeing capability 50 2780: new worker task (taskCount: 52) 35e8: cap 51: schedule() 35e8: giving up capability 51 35e8: freeing capability 51 2780: new worker task (taskCount: 53) 2780: new worker task (taskCount: 54) 3694: cap 53: schedule() 11fc: cap 52: schedule() 11fc: giving up capability 52 11fc: freeing capability 52 3694: giving up capability 53 3694: freeing capability 53 1888: cap 54: schedule() 1888: giving up capability 54 1888: freeing capability 54 2780: new worker task (taskCount: 55) 2780: new worker task (taskCount: 56) 1348: cap 55: schedule() 1348: giving up capability 55 1348: freeing capability 55 2780: new worker task (taskCount: 57) 3038: cap 56: schedule() 3038: giving up capability 56 3038: freeing capability 56 2780: new worker task (taskCount: 58) 3b70: cap 57: schedule() 3b70: giving up capability 57 3b70: freeing capability 57 2780: new worker task (taskCount: 59) 30ec: cap 58: schedule() 2780: new worker task (taskCount: 60) 12dc: cap 59: schedule() 30ec: giving up capability 58 30ec: freeing capability 58 1b00: cap 60: schedule() 1b00: giving up capability 60 1b00: freeing capability 60 12dc: giving up capability 59 12dc: freeing capability 59 2780: new worker task (taskCount: 61) 2780: new worker task (taskCount: 62) 1cf4: cap 61: schedule() 1cf4: giving up capability 61 1cf4: freeing capability 61 2780: new worker task (taskCount: 63) 3b88: cap 62: schedule() 2780: new worker task (taskCount: 64) 30e0: cap 63: schedule() 3b88: giving up capability 62 3b88: freeing capability 62 1ca8: cap 64: schedule() 1ca8: giving up capability 64 1ca8: freeing capability 64 30e0: giving up capability 63 30e0: freeing capability 63 2780: new worker task (taskCount: 65) 2780: new worker task (taskCount: 66) 2e74: cap 65: schedule() 2e74: giving up capability 65 2e74: freeing capability 65 2780: new worker task (taskCount: 67) 27d0: cap 66: schedule() 27d0: giving up capability 66 27d0: freeing capability 66 2780: new worker task (taskCount: 68) 6e4: cap 67: schedule() 6e4: giving up capability 67 6e4: freeing capability 67 2780: new worker task (taskCount: 69) 326c: cap 68: schedule() 2780: new worker task (taskCount: 70) 2e78: cap 69: schedule() 326c: giving up capability 68 326c: freeing capability 68 aa0: cap 70: schedule() 2e78: giving up capability 69 2e78: freeing capability 69 aa0: giving up capability 70 aa0: freeing capability 70 2780: new worker task (taskCount: 71) 2780: new worker task (taskCount: 72) 2748: cap 71: schedule() 2748: giving up capability 71 2748: freeing capability 71 2780: new worker task (taskCount: 73) 3bd8: cap 72: schedule() 3bd8: giving up capability 72 3bd8: freeing capability 72 2780: new worker task (taskCount: 74) 2ecc: cap 73: schedule() 2ecc: giving up capability 73 2ecc: freeing capability 73 2780: new worker task (taskCount: 75) some: 2e4c: SetThreadGroupAffinity: The parameter is incorrect. cap 74: schedule() 2e4c: giving up capability 74 2e4c: freeing capability 74 2780: new worker task (taskCount: 76) 1b50: cap 75: schedule() 1b50: giving up capability 75 1b50: freeing capability 75 2780: new worker task (taskCount: 77) 3498: cap 76: schedule() 3498: giving up capability 76 3498: freeing capability 76 2780: new worker task (taskCount: 78) 8a4: cap 77: schedule() 2780: new worker task (taskCount: 79) 317c: cap 78: schedule() 317c: giving up capability 78 317c: freeing capability 78 340c: cap 79: schedule() 340c: giving up capability 79 340c: freeing capability 79 8a4: giving up capability 77 8a4: freeing capability 77 2780: new worker task (taskCount: 80) 2780: new worker task (taskCount: 81) 3b98: cap 80: schedule() 3b98: giving up capability 80 3b98: freeing capability 80 2780: new worker task (taskCount: 82) 3200: cap 81: schedule() 3200: giving up capability 81 3200: freeing capability 81 2780: new worker task (taskCount: 83) 2870: cap 82: schedule() 2870: giving up capability 82 2870: freeing capability 82 2780: new worker task (taskCount: 84) 3378: cap 83: schedule() 3378: giving up capability 83 3378: freeing capability 83 2780: new worker task (taskCount: 85) 2780: new worker task (taskCount: 86) 2784: cap 85: schedule() 17a8: cap 84: schedule() 17a8: giving up capability 84 17a8: freeing capability 84 2784: giving up capability 85 2784: freeing capability 85 2a04: cap 86: schedule() 2a04: giving up capability 86 2a04: freeing capability 86 2780: new worker task (taskCount: 87) 3650: cap 87: schedule() 3650: giving up capability 87 3650: freeing capability 87 2780: new task (taskCount: 88) 2780: returning; I want capability 87 2780: resuming capability 87 2780: cap 87: created thread 1 2780: new bound thread (1) 2780: cap 87: schedule() 2780: cap 87: running thread 1 (ThreadRunGHC) 2780: cap 87: created thread 2 2780: cap 87: thread 1 stopped (finished) 2780: bound thread (1) finished 2780: passing capability 87 to worker 0x3650 2780: task exiting 2780: new task (taskCount: 88) 2780: returning; I want capability 87 2780: resuming capability 87 2780: cap 87: created thread 3 2780: new bound thread (3) 2780: cap 87: schedule() 2780: cap 87: 2 threads, 0 sparks, and 1 free capabilities, sharing... 2780: cap 87: thread 2 migrating to cap 0 2780: starting new worker on capability 0 3650: woken up on capability 87 3650: capability 87 is owned by another task 2780: new worker task (taskCount: 89) 2780: cap 87: running thread 3 (ThreadRunGHC) 2780: cap 87: created thread 4 2780: cap 87: created thread 5 2780: cap 87: created thread 6 2780: cap 87: created thread 7 2780: cap 87: created thread 8 2780: cap 87: created thread 9 2780: cap 87: thread 3 stopped (yielding) 2780: cap 87: 7 threads, 0 sparks, and 6 free capabilities, sharing... 2780: cap 87: thread 4 migrating to cap 1 2780: cap 87: thread 5 migrating to cap 2 2780: cap 87: thread 6 migrating to cap 3 2780: cap 87: thread 7 migrating to cap 4 2780: cap 87: thread 8 migrating to cap 5 2780: cap 87: thread 9 migrating to cap 6 2780: passing capability 1 to worker 0x2e28 2780: passing capability 2 to worker 0x335c 2780: passing capability 3 to worker 0x33bc 2780: passing capability 4 to worker 0x2e3c 2780: passing capability 5 to worker 0x2b2c 2780: passing capability 6 to worker 0x34dc 2780: cap 87: running thread 3 (ThreadRunGHC) 2780: cap 87: created thread 10 2780: cap 87: created thread 11 2780: cap 87: thread 3 stopped (yielding) 2780: passing capability 1 to worker 0x2e28 2780: passing capability 2 to worker 0x335c 2780: passing capability 3 to worker 0x33bc 2780: passing capability 4 to worker 0x2e3c 2780: passing capability 5 to worker 0x2b2c 2780: passing capability 6 to worker 0x34dc 2780: cap 87: 3 threads, 0 sparks, and 2 free capabilities, sharing... 2780: cap 87: thread 10 migrating to cap 7 2780: cap 87: thread 11 migrating to cap 8 2780: passing capability 7 to worker 0x754 2780: passing capability 8 to worker 0x242c 2780: cap 87: running thread 3 (ThreadRunGHC) 2780: cap 87: created thread 12 2780: cap 87: thread 3 stopped (blocked on an MVar) t 335c: woken up on capability 2 335c: resuming capability 2 335c: cap 2: running thread 5 (ThreadRunGHC) hread 754: woken up on capability 7 754: resuming capability 7 754: cap 7: running thread 10 (ThreadRunGHC) 34dc: woken up on capability 6 34dc: resuming capability 6 34dc: cap 6: running thread 9 (ThreadRunGHC) 2e3c: woken up on capability 4 2e3c: resuming capability 4 2e3c: cap 4: running thread 7 (ThreadRunGHC) 3 @ 0000000035d05b98 is blocked on 28a8: cap 0: schedule() an MVar @ 0000000035d049a8 (TSO_DIRTY) 28a8: cap 0: running thread 2 (ThreadRunGHC) 754: cap 7: message: thread 10 blocking on blackhole 0000000030704000 754: cap 7: forwarding message to cap 2 754: cap 7: thread 10 stopped (blocked on black hole owned by thread 5) thread 10 @ 0000000035d07800 is blocked on a black hole 0000000030704000 (TSO_DIRTY) 34dc: cap 6: message: thread 9 blocking on blackhole 0000000030704000 34dc: cap 6: forwarding message to cap 2 34dc: cap 6: thread 9 stopped (blocked on black hole owned by thread 5) thread 2e3c: 9 @ cap 4: message: thread 7 blocking on blackhole 0000000030704000 2e3c: cap 4: forwarding message to cap 2 0000000035d07400 2e3c: cap 4: thread is blocked on a black hole 0000000030704000 (TSO_DIRTY) 7 stopped (blocked on black hole owned by thread 5) thread 28a8: cap 0: waking up thread 3 on cap 87 7 @ 0000000035d06c00 is blocked on a black hole 0000000030704000 (TSO_DIRTY) 28a8: cap 0: message: try wakeup thread 3 on cap 87 28a8: cap 0: thread 2 stopped (suspended while making a foreign call) 28a8: starting new worker on capability 0 2e28: woken up on capability 1 2e28: resuming capability 1 2e28: cap 1: running thread 4 (ThreadRunGHC) 2e28: cap 1: message: thread 4 blocking on blackhole 0000000030704000 2e28: cap 1: forwarding message to cap 2 2e28: cap 1: thread 4 stopped (blocked on black hole owned by thread 5) 2e3c: giving up capability 4 thre 2e3c: freeing capability 4 ad 2e3c: woken up on capability 4 2e3c: resuming capability 4 4 @ 0000000035d06000 is blocked on 2e3c: giving up capability 4 2e3c: freeing capability 4 a 2780: giving up capability 87 2780: passing capability 87 to black hole worker 0x3650 0000000030704000 3650: (TSO_DIRTY) woken up on capability 87 3650: resuming capability 87 3650: cap 87: running thread 12 (ThreadRunGHC) 3650: cap 87: message: thread 12 blocking on blackhole 0000000030704000 3650: cap 87: forwarding message to cap 2 3650: cap 87: thread 12 stopped (blocked on black hole owned by thread 5) t 34dc: giving up capability 6 hread 34dc: freeing capability 6 34dc: woken up on capability 6 34dc: resuming capability 6 754: giving up capability 7 754: freeing capability 7 335c: cap 2: thread 5 stopped (yielding) 12 @ 0000000035d08000 335c: cap 2: message: thread 12 blocking on blackhole 0000000030704000 335c: cap 2: thread 12 blocked on thread 5 335c: cap 2: message: thread 4 blocking on blackhole 0000000030704000 335c: cap 2: thread 4 blocked on thread 5 335c: cap 2: message: thread 7 blocking on blackhole 0000000030704000 335c: cap 2: thread 7 blocked on thread 5 335c: cap 2: message: thread 9 blocking on blackhole 0000000030704000 335c: cap 2: thread 9 blocked on thread 5 335c: cap 2: message: thread 10 blocking on blackhole 0000000030704000 335c: cap 2: thread 10 blocked on thread 5 335c: cap 2: runining thread 5 (ThreadRunGHC) s blocked on a black hole 00 335c: cap 2: thread 5 stopped (yielding) 00000030704000 (TSO_DIRTY) 335c: cap 2: running thread 5 (ThreadRunGHC) 33bc: woken up on capability 3 33bc: resuming capability 3 33bc: cap 3: running thread 6 (ThreadRunGHC) 33bc: cap 3: message: thread 6 blocking on blackhole 0000000030704000 33bc: cap 3: forwarding message to cap 2 33bc: cap 3: thread 6 stopped (blocked on black hole owned by thread 5) thread 6 @ 3650: cap 87: message: try wakeup thread 3 0000000035d06800 3650: cap 87: waking up thread 3 on cap 87 is blocked on a black hole 0000000030704000 (TSO_DIRTY) 3650: giving up capability 87 3650: passing capability 87 to bound task 0x2780 2780: woken up on capability 87 2780: resuming capability 87 2780: cap 87: running thread 3 (ThreadRunGHC) 2780: cap 87: thread 3 stopped (yielding) 2780: cap 87: running thread 3 (ThreadRunGHC) 2780: cap 87: thread 3 stopped (blocked on an MVar) 2b2c: woken up on capability 5 th 2b2c: resuming capability 5 read 3 @ 0000000035d05b98 is blocked on an MVar @ 0000000035d04cd8 (TSO_DIRTY) 28a8: new worker task (taskCount: 90) 28a8: returning; I want capability 0 335c: cap 2: thread 5 stopped (yielding) 335c: cap 2: message: thread 6 blocking on blackhole 0000000030704000 335c: cap 2: thread 6 blocked on thread 5 335c: cap 2: running thread 5 (ThreadRunGHC) 2b2c: cap 5: running thread 8 (ThreadRunGHC) 2780: giving up capability 87 2780: freeing capability 87 242c: woken up on capability 8 242c: resuming capability 8 242c: cap 8: running thread 11 (ThreadRunGHC) 242c: cap 8: message: thread 11 blocking on blackhole 0000000030704000 242c: cap 8: forwarding message to cap 2 242c: cap 8: thread 11 stopped (blocked on black hole owned by thread 5) thread 2c88: cap 0: schedule() 11 @ 0000000035d07c00 2e28: giving up capability 1 2e28: freeing capability 1 is blocked on a black hole 0000000030704000 (TSO_DIRTY) 2e28: woken up on capability 1 2e28: resuming capability 1 2e28: giving up capability 1 2e28: freeing capability 1 33bc: giving up capability 3 33bc: freeing capability 3 33bc: woken up on capability 3 33bc: resuming capability 3 33bc: giving up capability 3 33bc: freeing capability 3 34dc: giving up capability 6 34dc: freeing capability 6 335c: cap 2: thread 5 stopped (stack overflow) 335c: cap 2: allocating new stack chunk of size 32768 bytes 335c: cap 2: message: thread 11 blocking on blackhole 0000000030704000 335c: cap 2: thread 11 blocked on thread 5 335c: cap 2: running thread 5 (ThreadRunGHC) 335c: cap 2: thread 5 stopped (yielding) 335c: cap 2: running thread 5 (ThreadRunGHC) 2b2c: cap 5: message: thread 8 blocking on blackhole 0000000030704000 2b2c: cap 5: forwarding message to cap 2 2b2c: cap 5: thread 8 stopped (blocked on black hole owned by thread 5) thread 8 @ 0000000035d07000 is blocked on a black hole 0000000030704000 (TSO_DIRTY) 335c: cap 2: thread 5 stopped (heap overflow) 2c88: giving up capability 0 2c88: passing capability 0 to worker 0x28a8 28a8: resuming capability 0 28a8: cap 0: running thread 2 (ThreadRunGHC) 28a8: cap 0: created thread 13 28a8: cap 0: waking up thread 3 on cap 87 28a8: passing capability 87 to worker 0x3650 28a8: cap 0: message: try wakeup thread 3 on cap 87 28a8: cap 0: thread 2 stopped (suspended while making a foreign call) 28a8: passing capability 0 to worker 0x2c88 2c88: woken up on capability 0 2c88: resuming capability 0 2c88: cap 0: starting GC 335c: cap 2: requesting parallel GC 335c: 0 idle caps 335c: passing capability 1 to worker 0x2e28 335c: passing capability 3 to worker 0x33bc 335c: passing capability 4 to worker 0x2e3c 335c: passing capability 6 to worker 0x34dc 335c: passing capability 7 to worker 0x754 335c: passing capability 9 to worker 0x26a8 33bc: woken up on capability 3 33bc: resuming capability 3 33bc: cap 3: starting GC 242c: giving up capability 8 242c: freeing capability 8 3650: woken up on capability 87 3650: resuming capability 87 3650: cap 87: starting GC 335c: passing capability 10 to worker 0x2f44 335c: passing capability 11 to worker 0x2bc4 335c: passing capability 12 to worker 0x17d8 335c: passing capability 13 to worker 0x3ba8 2e28: woken up on capability 1 2e28: resuming capability 1 2e28: cap 1: starting GC 26a8: woken up on capability 9 26a8: resuming capability 9 26a8: cap 9: starting GC 2bc4: woken up on capability 11 2bc4: resuming capability 11 2bc4: cap 11: starting GC 335c: passing capability 14 to worker 0x2664 335c: passing capability 15 to worker 0x1694 335c: passing capability 16 to worker 0x1cc8 335c: passing capability 17 to worker 0x2248 335c: passing capability 18 to worker 0x2e88 335c: passing capability 19 to worker 0x185c 335c: passing capability 20 to worker 0x263c 335c: passing capability 21 to worker 0x2d6c 335c: passing capability 22 to worker 0x3b90 335c: passing capability 23 to worker 0xb20 335c: passing capability 24 to worker 0x2054 335c: passing capability 25 to worker 0x13ac 335c: passing capability 26 to worker 0x25c4 335c: passing capability 27 to worker 0x2288 335c: passing capability 28 to worker 0x2404 335c: passing capability 29 to worker 0x275c 335c: passing capability 30 to worker 0x2cac 335c: passing capability 31 to worker 0x2d4c 335c: passing capability 32 to worker 0x131c 335c: passing capability 33 to worker 0x1604 335c: passing capability 34 to worker 0x1e94 263c: woken up on capability 20 263c: resuming capability 20 263c: cap 20: starting GC 3ba8: woken up on capability 13 3ba8: resuming capability 13 3ba8: cap 13: starting GC 754: woken up on capability 7 754: resuming capability 7 754: cap 7: starting GC 2b2c: giving up capability 5 2b2c: passing capability 5 to worker 0x2b2c 2b2c: woken up on capability 5 2b2c: resuming capability 5 2b2c: cap 5: starting GC 2288: woken up on capability 27 2288: resuming capability 27 2288: cap 27: starting GC 2e88: woken up on capability 18 2e88: resuming capability 18 2e88: cap 18: starting GC 2cac: woken up on capability 30 2cac: resuming capability 30 2cac: cap 30: starting GC 28a8: returning; I want capability 0 131c: woken up on capability 32 131c: resuming capability 32 131c: cap 32: starting GC 17d8: woken up on capability 12 17d8: resuming capability 12 17d8: cap 12: starting GC 2664: woken up on capability 14 2664: resuming capability 14 2664: cap 14: starting GC b20: woken up on capability 23 b20: resuming capability 23 b20: cap 23: starting GC 13ac: woken up on capability 25 13ac: resuming capability 25 13ac: cap 25: starting GC 2f44: woken up on capability 10 2f44: resuming capability 10 2f44: cap 10: starting GC 275c: woken up on capability 29 275c: resuming capability 29 275c: cap 29: starting GC 34dc: woken up on capability 6 34dc: resuming capability 6 34dc: cap 6: starting GC 1e94: woken up on capability 34 1e94: resuming capability 34 1e94: cap 34: starting GC 3b90: woken up on capability 22 3b90: resuming capability 22 3b90: cap 22: starting GC 1cc8: woken up on capability 16 1cc8: resuming capability 16 1cc8: cap 16: starting GC 2404: woken up on capability 28 2404: resuming capability 28 2404: cap 28: starting GC 185c: woken up on capability 19 185c: resuming capability 19 185c: cap 19: starting GC 2d6c: woken up on capability 21 2d6c: resuming capability 21 2d6c: cap 21: starting GC 25c4: woken up on capability 26 25c4: resuming capability 26 25c4: cap 26: starting GC 2d4c: woken up on capability 31 2d4c: resuming capability 31 2d4c: cap 31: starting GC 1694: woken up on capability 15 1694: resuming capability 15 1694: cap 15: starting GC 2e3c: woken up on capability 4 2e3c: resuming capability 4 2e3c: cap 4: starting GC 2054: woken up on capability 24 2054: resuming capability 24 2054: cap 24: starting GC 335c: passing capability 35 to worker 0x31a0 2248: woken up on capability 17 2248: resuming capability 17 2248: cap 17: starting GC 31a0: woken up on capability 35 31a0: resuming capability 35 335c: passing capability 36 to worker 0x3758 335c: passing capability 37 to worker 0x2758 31a0: cap 35: starting GC 1604: woken up on capability 33 1604: resuming capability 33 1604: cap 33: starting GC 2758: woken up on capability 37 2758: resuming capability 37 2758: cap 37: starting GC 3758: woken up on capability 36 3758: resuming capability 36 3758: cap 36: starting GC 335c: passing capability 38 to worker 0x3458 335c: passing capability 39 to worker 0x2754 3458: woken up on capability 38 3458: resuming capability 38 3458: cap 38: starting GC 335c: passing capability 40 to worker 0x1b20 2754: woken up on capability 39 2754: resuming capability 39 2754: cap 39: starting GC 335c: passing capability 41 to worker 0x2c28 1b20: woken up on capability 40 1b20: resuming capability 40 1b20: cap 40: starting GC 2c28: woken up on capability 41 2c28: resuming capability 41 2c28: cap 41: starting GC 335c: passing capability 42 to worker 0x30e8 335c: passing capability 43 to worker 0x23e0 30e8: woken up on capability 42 30e8: resuming capability 42 30e8: cap 42: starting GC 335c: passing capability 44 to worker 0x2b94 23e0: woken up on capability 43 23e0: resuming capability 43 23e0: cap 43: starting GC 335c: passing capability 45 to worker 0x24ec 335c: passing capability 46 to worker 0x239c 335c: passing capability 47 to worker 0x284c 335c: passing capability 48 to worker 0x2138 335c: passing capability 49 to worker 0x2b68 335c: passing capability 50 to worker 0x3228 335c: passing capability 51 to worker 0x35e8 335c: passing capability 52 to worker 0x11fc 335c: passing capability 53 to worker 0x3694 335c: passing capability 54 to worker 0x1888 335c: passing capability 55 to worker 0x1348 335c: passing capability 56 to worker 0x3038 335c: passing capability 57 to worker 0x3b70 335c: passing capability 58 to worker 0x30ec 335c: passing capability 59 to worker 0x12dc 335c: passing capability 60 to worker 0x1b00 335c: passing capability 61 to worker 0x1cf4 335c: passing capability 62 to worker 0x3b88 335c: passing capability 63 to worker 0x30e0 335c: passing capability 64 to worker 0x1ca8 335c: passing capability 65 to worker 0x2e74 335c: passing capability 66 to worker 0x27d0 335c: passing capability 67 to worker 0x6e4 335c: passing capability 68 to worker 0x326c 335c: passing capability 69 to worker 0x2e78 335c: passing capability 70 to worker 0xaa0 335c: passing capability 71 to worker 0x2748 335c: passing capability 72 to worker 0x3bd8 335c: passing capability 73 to worker 0x2ecc 335c: passing capability 74 to worker 0x2e4c 335c: passing capability 75 to worker 0x1b50 335c: passing capability 76 to worker 0x3498 335c: passing capability 77 to worker 0x8a4 335c: passing capability 78 to worker 0x317c 335c: passing capability 79 to worker 0x340c 335c: passing capability 80 to worker 0x3b98 335c: passing capability 81 to worker 0x3200 335c: passing capability 82 to worker 0x2870 335c: passing capability 83 to worker 0x3378 335c: passing capability 84 to worker 0x17a8 335c: passing capability 85 to worker 0x2784 335c: passing capability 86 to worker 0x2a04 3228: woken up on capability 50 3228: resuming capability 50 3228: cap 50: starting GC 1888: woken up on capability 54 1888: resuming capability 54 1888: cap 54: starting GC 3bd8: woken up on capability 72 3bd8: resuming capability 72 3bd8: cap 72: starting GC 317c: woken up on capability 78 317c: resuming capability 78 317c: cap 78: starting GC 239c: woken up on capability 46 239c: resuming capability 46 239c: cap 46: starting GC 3b70: woken up on capability 57 3b70: resuming capability 57 3b70: cap 57: starting GC 2e78: woken up on capability 69 2e78: resuming capability 69 2e78: cap 69: starting GC 2748: woken up on capability 71 2748: resuming capability 71 2748: cap 71: starting GC 2138: woken up on capability 48 2138: resuming capability 48 2138: cap 48: starting GC 11fc: woken up on capability 52 11fc: resuming capability 52 11fc: cap 52: starting GC 1b00: woken up on capability 60 1b00: resuming capability 60 1b00: cap 60: starting GC 3200: woken up on capability 81 3200: resuming capability 81 3200: cap 81: starting GC 3378: woken up on capability 83 3378: resuming capability 83 3378: cap 83: starting GC 8a4: woken up on capability 77 8a4: resuming capability 77 8a4: cap 77: starting GC 2a04: woken up on capability 86 2a04: resuming capability 86 2a04: cap 86: starting GC 1348: woken up on capability 55 1348: resuming capability 55 1348: cap 55: starting GC 30ec: woken up on capability 58 30ec: resuming capability 58 30ec: cap 58: starting GC 30e0: woken up on capability 63 30e0: resuming capability 63 30e0: cap 63: starting GC 3038: woken up on capability 56 3038: resuming capability 56 3038: cap 56: starting GC 27d0: woken up on capability 66 27d0: resuming capability 66 27d0: cap 66: starting GC 2e74: woken up on capability 65 2e74: resuming capability 65 2e74: cap 65: starting GC 340c: woken up on capability 79 340c: resuming capability 79 340c: cap 79: starting GC 35e8: woken up on capability 51 35e8: resuming capability 51 35e8: cap 51: starting GC 17a8: woken up on capability 84 17a8: resuming capability 84 17a8: cap 84: starting GC 335c: passing capability 8 to worker 0x242c 2b94: woken up on capability 44 2e4c: woken up on capability 74 2e4c: resuming capability 74 2e4c: cap 74: starting GC 1b50: woken up on capability 75 1b50: resuming capability 75 1b50: cap 75: starting GC 6e4: woken up on capability 67 6e4: resuming capability 67 6e4: cap 67: starting GC 2b68: woken up on capability 49 2b68: resuming capability 49 2b68: cap 49: starting GC 3b98: woken up on capability 80 3b98: resuming capability 80 3b98: cap 80: starting GC 3498: woken up on capability 76 3498: resuming capability 76 3498: cap 76: starting GC 335c: passing capability 44 to worker 0x2b94 242c: woken up on capability 8 242c: resuming capability 8 242c: cap 8: starting GC 3b88: woken up on capability 62 3b88: resuming capability 62 3b88: cap 62: starting GC aa0: woken up on capability 70 aa0: resuming capability 70 aa0: cap 70: starting GC 284c: woken up on capability 47 284c: resuming capability 47 284c: cap 47: starting GC 24ec: woken up on capability 45 335c: passing capability 45 to worker 0x24ec 2b94: resuming capability 44 2b94: cap 44: starting GC 12dc: woken up on capability 59 12dc: resuming capability 59 12dc: cap 59: starting GC 1ca8: woken up on capability 64 1ca8: resuming capability 64 1ca8: cap 64: starting GC 2784: woken up on capability 85 2784: resuming capability 85 2784: cap 85: starting GC 2ecc: woken up on capability 73 2ecc: resuming capability 73 2ecc: cap 73: starting GC 1cf4: woken up on capability 61 1cf4: resuming capability 61 1cf4: cap 61: starting GC 24ec: resuming capability 45 24ec: cap 45: starting GC 326c: woken up on capability 68 326c: resuming capability 68 326c: cap 68: starting GC 3694: woken up on capability 53 2870: woken up on capability 82 2870: resuming capability 82 2870: cap 82: starting GC 335c: passing capability 53 to worker 0x3694 3694: resuming capability 53 3694: cap 53: starting GC all threads: threads on capability 0: thread 13 @ 00000000305053a0 is not blocked (TSO_DIRTY) threads on capability 1: threads on capability 2: thread 5 @ 0000000035d06400 is not blocked (TSO_DIRTY) threads on capability 3: threads on capability 4: threads on capability 5: threads on capability 6: threads on capability 7: threads on capability 8: threads on capability 9: threads on capability 10: threads on capability 11: threads on capability 12: threads on capability 13: threads on capability 14: threads on capability 15: threads on capability 16: threads on capability 17: threads on capability 18: threads on capability 19: threads on capability 20: threads on capability 21: threads on capability 22: threads on capability 23: threads on capability 24: threads on capability 25: threads on capability 26: threads on capability 27: threads on capability 28: threads on capability 29: threads on capability 30: threads on capability 31: threads on capability 32: threads on capability 33: threads on capability 34: threads on capability 35: threads on capability 36: threads on capability 37: threads on capability 38: threads on capability 39: threads on capability 40: threads on capability 41: threads on capability 42: threads on capability 43: threads on capability 44: threads on capability 45: threads on capability 46: threads on capability 47: threads on capability 48: threads on capability 49: threads on capability 50: threads on capability 51: threads on capability 52: threads on capability 53: threads on capability 54: threads on capability 55: threads on capability 56: threads on capability 57: threads on capability 58: threads on capability 59: threads on capability 60: threads on capability 61: threads on capability 62: threads on capability 63: threads on capability 64: threads on capability 65: threads on capability 66: threads on capability 67: threads on capability 68: threads on capability 69: threads on capability 70: threads on capability 71: threads on capability 72: threads on capability 73: threads on capability 74: threads on capability 75: threads on capability 76: threads on capability 77: threads on capability 78: threads on capability 79: threads on capability 80: threads on capability 81: threads on capability 82: threads on capability 83: threads on capability 84: threads on capability 85: threads on capability 86: threads on capability 87: other threads: thread 12 @ 0000000035d08000 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 11 @ 0000000035d07c00 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 10 @ 0000000035d07800 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 9 @ 0000000035d07400 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 8 @ 0000000035d07000 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 7 @ 0000000035d06c00 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 6 @ 0000000035d06800 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 4 @ 0000000035d06000 is blocked on a black hole 0000000030704000 (TSO_DIRTY) thread 3 @ 0000000035d05b98 is blocked on an MVar @ 0000000035d04cd8 (TSO_DIRTY) thread 2 @ 0000000035d05798 is blocked on an external call (TSO_DIRTY) 335c: cap 2: starting GC 33bc: cap 3: GC working 1e94: cap 34: GC working 1e94: cap 34: GC idle 335c: cap 2: GC working 35e8: cap 51: GC working 2054: cap 24: GC working 3b70: cap 57: GC working 3038: cap 56: GC working 3038: cap 56: GC idle 3650: cap 87: GC working 31a0: cap 35: GC working 242c: cap 8: GC working 2404: cap 28: GC working 185c: cap 19: GC working b20: cap 23: GC working 3bd8: cap 72: GC working 2f44: cap 10: GC working 1b20: cap 40: GC working 1b20: cap 40: GC idle 1348: cap 55: GC working 1348: cap 55: GC idle 2ecc: cap 73: GC working 2ecc: cap 73: GC idle 2870: cap 82: GC working }}} -- Ticket URL: GHC The Glasgow Haskell Compiler