From ghc-devs at haskell.org Sat Apr 1 00:03:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 00:03:39 -0000 Subject: [GHC] #13474: GHC HEAD regression: Prelude.!!: index too large In-Reply-To: <050.a141e95defa8fbf6040db0fc9540e547@haskell.org> References: <050.a141e95defa8fbf6040db0fc9540e547@haskell.org> Message-ID: <065.796e1cc40ef388a9c7cf243f869fdf9d@haskell.org> #13474: GHC HEAD regression: Prelude.!!: index too large -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It looks like Phab:D3316 (6575f4b635a393775295798ca86c7c3ba00819be) did indeed fix this, as I can no longer reproduce the panic on GHC HEAD. Should we add a regression test for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 03:20:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 03:20:59 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.916961b99dd337f7ab70a9f4943f96d6@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"71916e1c018dded2e68d6769a2dbb8777da12664/ghc" 71916e1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71916e1c018dded2e68d6769a2dbb8777da12664" Remove Core Lint pass on occurrence analysis output (#13220) It was expensive, as the simplifier runs for many iterations, and probably not very useful. Test Plan: harbormaster Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3391 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 10:12:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 10:12:16 -0000 Subject: [GHC] #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC In-Reply-To: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> References: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> Message-ID: <057.54213ea770c7e3bca2e9c39b3675b990@haskell.org> #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC ----------------------------------------+------------------------------- Reporter: jms | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"74615f412ad3de2910a156ff494bfe5497fada7e/ghc" 74615f41/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74615f412ad3de2910a156ff494bfe5497fada7e" UNREG: ignore -fllvm (Trac #13495) Unregisterised GHC can only use C as a target backend (option used to be called -fvia-C). -fasm option was ignored with a warhing, but not -fllvm. jms noticed the failure when tried to use quick-cross build flavour. quick-cross enables -fllvm in makefile. "inplace/bin/ghc-stage1" ... -fllvm ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.0.2 for powerpc-unknown-linux): LlvmCodeGen.Ppr: Cross compiling without valid target info. This change ignores -fllvm as well. Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 10:15:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 10:15:58 -0000 Subject: [GHC] #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC In-Reply-To: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> References: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> Message-ID: <057.2142803db026f630ae09323d2da20fe1@haskell.org> #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC -------------------------------------+------------------------------------- Reporter: jms | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 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 slyfox): * status: new => merge * architecture: powerpc => Unknown/Multiple Comment: I've tested 'quick-cross' on powerpc-linux-gnuspe target. Works with the patch above. Should be harmless to backport to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 14:57:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 14:57:04 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.f0bd21258d90ec28efa65194b60a4cb6@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 52d14ba3a0bafafee5620091a3c22717a883a2d7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 15:00:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 15:00:58 -0000 Subject: [GHC] #13474: GHC HEAD regression: Prelude.!!: index too large In-Reply-To: <050.a141e95defa8fbf6040db0fc9540e547@haskell.org> References: <050.a141e95defa8fbf6040db0fc9540e547@haskell.org> Message-ID: <065.e542b8ddca315a0a9457fc696df12c81@haskell.org> #13474: GHC HEAD regression: Prelude.!!: index too large -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"616a3b49f085c01ff676424a1c3297ce0888e7ae/ghc" 616a3b49/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="616a3b49f085c01ff676424a1c3297ce0888e7ae" testsuite: Add regression test for #13474 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 15:01:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 15:01:58 -0000 Subject: [GHC] #13474: GHC HEAD regression: Prelude.!!: index too large In-Reply-To: <050.a141e95defa8fbf6040db0fc9540e547@haskell.org> References: <050.a141e95defa8fbf6040db0fc9540e547@haskell.org> Message-ID: <065.494223291eaedb584399abe83a9e0be8@haskell.org> #13474: GHC HEAD regression: Prelude.!!: index too large -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13474 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * testcase: => typecheck/should_compile/T13474 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 15:48:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 15:48:01 -0000 Subject: [GHC] #13507: Changes to environment files don't apply in GHCi on :reload Message-ID: <046.cc710f7ed51e19d194b1bc2bbdc33e1f@haskell.org> #13507: Changes to environment files don't apply in GHCi on :reload -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Changes to (or creation of) package environment files don't apply in GHCi when the user performs a `:reload`. This is likely contrary to the user's expectation. This was first noted in Phab:D3392 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 19:01:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 19:01:40 -0000 Subject: [GHC] #13458: Panic with unsafeCoerce and -dcore-lint In-Reply-To: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> References: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> Message-ID: <060.bd63d0de6768453278beae4ea2da5a1e@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13458 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, the lint checks where reverted in 03c7dd0941fb4974be54026ef3e4bb97451c3b1f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 1 21:40:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Apr 2017 21:40:20 -0000 Subject: [GHC] #13508: Clarify Some Restrictions on Compact Regions Message-ID: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> #13508: Clarify Some Restrictions on Compact Regions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: ezyang Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 8.1 libraries/compact | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been reading over the docs for using compact regions here: [https ://phabricator-files.haskell.org/file/data/uqmgx4accjldseyd34xj/PHID-FILE- 3sihhhdhl4gaeszvphzb/Compact.hs]. I'm pretty excited about this feature, but there's one thing that the docs don't make totally clear. Can MutableByteArray# be placed in a compact region? Near the top, the docs specifically say that "object[s] with mutable pointer fields" cannot be compacted, but that doesn't rule out `MutableByteArray#`. Later down, in the docs for `compact`, this restriction is broadened to any mutable data. I would like to see the docs clarify this better. The existence of `resizeMutableByteArray#` makes me think that it should not possible, but I'd like to be sure. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 00:26:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 00:26:33 -0000 Subject: [GHC] #13508: Clarify Some Restrictions on Compact Regions In-Reply-To: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> References: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> Message-ID: <064.383722cdbe63654ca39b236eaca02e0b@haskell.org> #13508: Clarify Some Restrictions on Compact Regions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: ezyang Type: bug | Status: patch Priority: lowest | Milestone: 8.2.1 Component: | Version: 8.1 libraries/compact | 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:D3407 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3407 * milestone: => 8.2.1 Comment: I believe mutable byte arrays should be fine. The limitation is merely that you can't have things with **mutable pointers**. This limitation is due to the principle invariant of a compact region: that all objects in the transitive closure of an given member must also be members of the region. This invariant is enforced when the region is constructed. Allowing mutable pointers (e.g. `MutableArray#` and `MutVar#`) would enable the user to break this invariant by introducing a pointer to an object residing outside of the region. I agree that the language in the documentation could be improved. How does Phab:D2407 look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 03:27:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 03:27:18 -0000 Subject: [GHC] #13509: Perplexing type error Message-ID: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> #13509: Perplexing type error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- The `fast-digits` package fails to build with 8.2.0-rc1, {{{ [1 of 2] Compiling Data.FastDigits.Internal ( src/Data/FastDigits/Internal.hs, dist/build/Data/FastDigits/Internal.o ) src/Data/FastDigits/Internal.hs:42:34: error: • Couldn't match a lifted type with an unlifted type Expected type: Word# -> (# Word#, Word# #) Actual type: Word# -> (# Word#, Word# #) • In the expression: go pw2 In a pattern binding: (# n, pw2n #) = go pw2 In the expression: let (# n, pw2n #) = go pw2 in case timesWord2# pw pw2n of (# 0##, pw2n1 #) -> (# n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) _ -> (# n `timesWord#` 2##, pw2n #) | 42 | -> let (# n, pw2n #) = go pw2 in | ^^^^^^ src/Data/FastDigits/Internal.hs:43:33: error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Word#’ • In the second argument of ‘timesWord2#’, namely ‘pw2n’ In the expression: timesWord2# pw pw2n In the expression: case timesWord2# pw pw2n of (# 0##, pw2n1 #) -> (# n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) _ -> (# n `timesWord#` 2##, pw2n #) | 43 | case timesWord2# pw pw2n of | ^^^^ src/Data/FastDigits/Internal.hs:44:37: error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Word#’ • In the first argument of ‘timesWord#’, namely ‘n’ In the first argument of ‘plusWord#’, namely ‘n `timesWord#` 2##’ In the expression: n `timesWord#` 2## `plusWord#` 1## | 44 | (# 0##, pw2n1 #) -> (#n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 03:30:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 03:30:25 -0000 Subject: [GHC] #13509: Perplexing type error In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.9eb24e0a6502a91aa42ac7b9af59bbf4@haskell.org> #13509: Perplexing type error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The function in question is, {{{#!hs selectPower :: Word# -> (# Word#, Word# #) selectPower 2## = (# 63##, 9223372036854775808## #) selectPower base = go base where go :: Word# -> (# Word#, Word# #) go pw = case timesWord2# pw pw of (# 0##, pw2 #) -> let (# n, pw2n #) = go pw2 in case timesWord2# pw pw2n of (# 0##, pw2n1 #) -> (#n `timesWord#` 2## `plusWord#` 1##, pw2n1 #) _ -> (# n `timesWord#` 2##, pw2n #) _ -> (# 1##, pw #) }}} Adding a type signature, `go :: Word# -> (# Word#, Word# #)`, appears to allow compilation to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 08:03:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 08:03:36 -0000 Subject: [GHC] #13510: GHC panic with -fdefer-type-errors Message-ID: <050.586437ea79068b37eddb30e002344721@haskell.org> #13510: GHC panic with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: chrismwendt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program causes GHCi to panic: {{{ import Data.Monoid a = "" x :: () -> Int x b = a <> b }}} {{{ $ stack --version Version 1.3.2 x86_64 hpack-0.15.0 $ stack exec ghci program.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/chrismwendt/.ghci [1 of 1] Compiling Main ( program.hs, interpreted ) program.hs:6:12: warning: [-Wdeferred-type-errors] • Couldn't match expected type ‘Int’ with actual type ‘()’ • In the second argument of ‘(<>)’, namely ‘b’ In the expression: a <> b In an equation for ‘x’: x b = a <> b ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): corePrepPgm [False] cobox_r1MZ = typeError @ 'VoidRep @ (Int :: *) ~# (() :: *) "program.hs:6:12: error:\n\ \ \\226\\128\\162 Couldn't match expected type \\226\\128\\152Int\\226\\128\\153 with actual type \\226\\128\\152()\\226\\128\\153\n\ \ \\226\\128\\162 In the second argument of \\226\\128\\152(<>)\\226\\128\\153, namely \\226\\128\\152b\\226\\128\\153\n\ \ In the expression: a <> b\n\ \ In an equation for \\226\\128\\152x\\226\\128\\153: x b = a <> b\n\ \(deferred type error)"# }}} Here's my ~/.ghci config: {{{ :set -fdefer-type-errors :set -XOverloadedStrings :set +t }}} Both -fdefer-type-errors and -XOVerloadedStrings are necessary to cause the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:31:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:31:06 -0000 Subject: [GHC] #13511: ApplicativeDo incorrectly requiring Monad Message-ID: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> #13511: ApplicativeDo incorrectly requiring Monad -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 ran into this bug in production, this is a simplified reproduction. The following program will not type check, requiring an unnecessary Monad instance: {{{ {-# LANGUAGE ApplicativeDo, GeneralizedNewtypeDeriving #-} import Data.Functor.Identity import Data.Monoid newtype A x = A (Identity x) deriving (Functor, Applicative) shouldWork :: A () shouldWork = do a <- pure () b <- pure () let ab = a <> b return ab }}} {{{ pepe:~/code/snippets$ ghci ApplicativeDoBug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ApplicativeDoBug.hs, interpreted ) ApplicativeDoBug.hs:10:14: error: • No instance for (Monad A) arising from a do statement • In the expression: do { a <- pure (); b <- pure (); let ab = a <> b; return ab } In an equation for ‘shouldWork’: shouldWork = do { a <- pure (); b <- pure (); let ab = ...; return ab } Failed, modules loaded: none. }}} There is a simple workaround, which worked for us in production: {{{ workaround :: A () workaround = do a <- pure () b <- pure () return $ let ab = a <> b in ab }}} I asked in #ghc and it seems this is not yet fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:49:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:49:10 -0000 Subject: [GHC] #13511: ApplicativeDo incorrectly requiring Monad In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.f89bac40986e60ba6aded347441e513a@haskell.org> #13511: ApplicativeDo incorrectly requiring Monad -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo 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: simonmar (added) * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:51:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:51:10 -0000 Subject: [GHC] #13309: Use liftA2 in ApplicativeDo In-Reply-To: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> References: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> Message-ID: <060.59484e953f2ba5ccc6cffcc24235bfef@haskell.org> #13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: ApplicativeDo 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): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:51:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:51:57 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.a1c50db321056cfd72ddbc11d7785995@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:53:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:53:45 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo In-Reply-To: <047.3e578efe5e273399089fa654398b6d79@haskell.org> References: <047.3e578efe5e273399089fa654398b6d79@haskell.org> Message-ID: <062.58477ba193fe771ddac212024889de17@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: ApplicativeDo 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): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:54:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:54:37 -0000 Subject: [GHC] #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification In-Reply-To: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> References: <043.8ac9d7ee78bb56330fcaae81eb995749@haskell.org> Message-ID: <058.c62b844e217bce1c78d0e1d97a458b28@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: ApplicativeDo 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): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:56:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:56:29 -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.9828c6f36883677e44659c5448de9d04@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: ApplicativeDo 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 RyanGlScott): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:57:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:57:46 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.1a38b8ae719f4e68b8b02b9e76354bae@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo 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): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 11:58:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 11:58:13 -0000 Subject: [GHC] #10976: Applicative Comprehensions In-Reply-To: <046.b8fb42a1a67c05a5fd3b2ee681f1abcf@haskell.org> References: <046.b8fb42a1a67c05a5fd3b2ee681f1abcf@haskell.org> Message-ID: <061.1c888e7d155f597b27de39bbaf062c56@haskell.org> #10976: Applicative Comprehensions -------------------------------------+------------------------------------- Reporter: davidar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8914 Related Tickets: #8914 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 13:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 13:01:31 -0000 Subject: [GHC] #13510: GHC panic with -fdefer-type-errors In-Reply-To: <050.586437ea79068b37eddb30e002344721@haskell.org> References: <050.586437ea79068b37eddb30e002344721@haskell.org> Message-ID: <065.267fd3376bf40c5fc14db18ae99fb8c9@haskell.org> #13510: GHC panic with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: chrismwendt | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13292 Comment: Thanks for the bug report. This panic no longer occurs in GHC 8.2 or HEAD, which makes me believe it's a duplicate of #13292, so I'll close this ticket as such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 13:07:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 13:07:30 -0000 Subject: [GHC] #13511: ApplicativeDo incorrectly requiring Monad In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.b213d83b02120bb5bea97df243555e96@haskell.org> #13511: ApplicativeDo incorrectly requiring Monad -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo 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): * type: bug => feature request Comment: The user's guide makes it pretty clear that a case like this is not currently expected to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 13:13:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 13:13:02 -0000 Subject: [GHC] #13511: ApplicativeDo incorrectly requiring Monad In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.781396f33b0cdf5b3d8f4d33fdd7926f@haskell.org> #13511: ApplicativeDo incorrectly requiring Monad -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnislaih): The user's guide doesn't explicitly mention let bindings, it only says: >In general, the rule for when a do statement incurs a Monad constraint is as follows. If the do-expression has the following form: {{{ do p1 <- E1; ...; pn <- En; return E }}} >where none of the variables defined by p1...pn are mentioned in E1...En, then the expression will only require Applicative. Otherwise, the expression will require Monad. The block may return a pure expression E depending upon the results p1...pn with either return or pure. Or were you referring to something else ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 13:14:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 13:14:24 -0000 Subject: [GHC] #7780: GHC HEAD dll fails to build on Windows In-Reply-To: <047.7e5ddf4ebd5ce7d534b18129d5da342a@haskell.org> References: <047.7e5ddf4ebd5ce7d534b18129d5da342a@haskell.org> Message-ID: <062.180086d9ddcf6bd261436d3c617657b2@haskell.org> #7780: GHC HEAD dll fails to build on Windows ----------------------------------------+--------------------------------- Reporter: rassilon | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------------+--------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"03e34256e2cba964adf6dcdb1682618f26400b3a/ghc" 03e34256/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03e34256e2cba964adf6dcdb1682618f26400b3a" compiler/ghc.mk: fix GhcWithInterpreter=NO build failure When GhcWithInterpreter=NO is set in mk/build.mk build fails as: $ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" ... Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Extra modules: ByteCodeTypes InteractiveEvalTypes Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 13:36:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 13:36:32 -0000 Subject: [GHC] #13509: Perplexing type error In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.ed108105a54929bed71539ded5c7972d@haskell.org> #13509: Perplexing type error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: The commit e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9 (Update levity polymorphism) introduced this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 13:36:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 13:36:45 -0000 Subject: [GHC] #13509: Perplexing type error In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.6931f8c35258c09d946e7be6348f6e94@haskell.org> #13509: Perplexing type error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 14:17:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 14:17:04 -0000 Subject: [GHC] #13512: GHC incorrectly warns that a variable used in a type application is unused Message-ID: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> #13512: GHC incorrectly warns that a variable used in a type application is unused -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug is reproducible on GHC 8.0.1, 8.0.2, 8.2, and HEAD. {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -Wunused-foralls #-} module Bug where import Data.Proxy proxy :: forall k (a :: k). Proxy a proxy = Proxy data SomeProxy where SomeProxy :: forall k (a :: k). Proxy a -> SomeProxy someProxy :: forall k (a :: k). SomeProxy someProxy = SomeProxy (proxy @k @a) }}} {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.3.20170327: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:23: warning: [-Wunused-foralls] Unused quantified type variable ‘(a :: k)’ In the type ‘forall k (a :: k). SomeProxy’ | 17 | someProxy :: forall k (a :: k). SomeProxy | ^^^^^^^^ Ok, modules loaded: Bug. }}} But that `a` is used in `proxy @k @a`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 14:55:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 14:55:11 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets (was: ApplicativeDo incorrectly requiring Monad) In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.6311522cfc572745829351a668c44ec4@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo 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.4.1 Comment: Perhaps the users guide language could be improved. Currently the `return` case is a rather narrow, purely syntactic rewrite which does not handle `let`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 15:18:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 15:18:58 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.9062308668eb5dee8e3d056d12f2abec@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnislaih): If we stick to the definition of ApplicativeDo in the users guide, and given that join is not needed here, I think it is fair to say that this is a bug: > The language option -XApplicativeDo enables an alternative translation for the do-notation, which uses the operators <$>, <*>, along with join as far as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 17:24:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 17:24:10 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.ddf85008d522f60cfb051e7759f4283e@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * os: MacOS X => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 18:35:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 18:35:12 -0000 Subject: [GHC] #13513: Incorrect behavior on arm64 with optimisations Message-ID: <047.a4ba0434831678c830befedb77f73790@haskell.org> #13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I compiled ghc manually on a chromebook running ubuntu on aarch64 (arm64). I used `perf-llvm` build during compilation. This might be related to [https://ghc.haskell.org/trac/ghc/ticket/11578], but I am not sure how. While working with stack and cabal I experienced unusually long compilation times or seemingly random build failures from time to time. Luckily, at some point I got very interesting error in package `text`: {{{#!hs Prelude> import qualified Data.Text as T Prelude T> T.splitOn (T.pack " ") (T.pack "Hello world!") ["Hello","world!\54497\44724?\NUL\54521\44724?\NUL\NUL\NUL\NUL\NUL\34560...BIG BLOB OF BYTES HERE...\NUL"] }}} By default this package compiles with `-O2`, so I tried various options to determine when the result is correct and when is not. To test this I used bare GHC installation and `cabal-install-1.24.0.2`, (`cabal sandbox init && cabal install text --ghc-options="..."`). Here is what I tried so far: * BAD: `-O2` * BAD: `-O2 -fllvm -optlc-O3` * OK: `-O1 -fllvm -optlc-O3` * OK: `-O1 -fllvm -fliberate-case -fregs-graph -fspec-constr -optlc-O3` That is: when `text` package is compiled with `-O2` the result of `Text.splitOn` function is garbaged with random data; when it is compiled with `-O1`, the result is correct. Since `text` is represented using `ByteArray#` internally, I would suggest something is wrong with `ByteArray#`'s length attribute, but I am not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:08:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:08:57 -0000 Subject: [GHC] #13458: Panic with unsafeCoerce and -dcore-lint In-Reply-To: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> References: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> Message-ID: <060.4fc5fce0663e536d23dc7abc9f873551@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13458 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have reverted comment:12 in `ghc-8.2` in 3ebbc387e3207dc7b5743a1dc6e20df6d4152282. We'll need to re-assess this situation prior to the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:11:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:11:50 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows Message-ID: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows --------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- {{{ =====> annrun01(normal) 1 of 57 [0, 0, 22] cd "./annotations/should_run/annrun01.run" && $MAKE -s --no-print- directory config cd "./annotations/should_run/annrun01.run" && "C:/msys64/home/ben/ghc/inplace/bin/ghc-stage2.exe" --make -o annrun01 annrun01 -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fd iagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package ghc -static Compile failed (exit code 1) errors were: [1 of 3] Compiling Annrun01_Help ( Annrun01_Help.hs, Annrun01_Help.o ) ghc-stage2.exe: unable to load package `Win32-2.5.3.0' ghc-stage2.exe: | C:\msys64\home\ben\ghc\libraries\Win32\dist- install\build\HSWin32-2.5.3.0.o: unknown symbol `_GetWindowLongPtrW' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:19:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:19:51 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows In-Reply-To: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> References: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> Message-ID: <061.83e8087153cb51c1291485981f3215ea@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * cc: Phyx- (added) Comment: I'm seeing several other tests fail with similar failures including, {{{ TEST="annrun01 ghci062 ghci038 T6106" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:24:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:24:31 -0000 Subject: [GHC] #13280: Consider deriving more Foldable methods In-Reply-To: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> References: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> Message-ID: <060.3d1b3990b0d960b877a0cd3a9725f8f3@haskell.org> #13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"bf5e0eab60a11d494671793740122e381a707c1a/ghc" bf5e0ea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bf5e0eab60a11d494671793740122e381a707c1a" Derive the definition of null We can sometimes produce much better code by deriving the definition of `null` rather than using the default. For example, given data SnocList a = Lin | Snoc (SnocList a) a the default definition of `null` will walk the whole list, but of course we can stop as soon as we see `Snoc`. Similarly, if a constructor contains some other `Foldable` type, we want to use its `null` rather than folding over the structure. Partially fixes Trac #13280 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3402 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:25:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:25:32 -0000 Subject: [GHC] #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows Message-ID: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows --------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- The `T11223_simple_duplicate_lib` test seems to fail on 32-bit Windows with, {{{#!patch diff --git a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib .stderr-mingw32 b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib .stderr-mingw32 index 4d4656f..5fdd70f 100644 --- a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr- mingw32 +++ b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr- mingw32 @@ -1,15 +1,15 @@ GHC runtime linker: fatal error: I found a duplicate definition for symbol - a + _a whilst processing object file - E:\ghc- dev\msys64\home\Tamar\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\libfoo_dup_lib.a + C:\msys64\home\ben\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\libfoo_dup_lib.a The symbol was previously defined in - E:\ghc- dev\msys64\home\Tamar\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\bar_dup_lib.o + C:\msys64\home\ben\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\bar_dup_lib.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. -ghc-stage2.exe: ^^ Could not load 'c', dependency unresolved. See top entry above. +ghc-stage2.exe: ^^ Could not load '_c', dependency unresolved. See top entry above. ByteCodeLink: can't find label }}} While this difference looks innocuous enough, I can't recall anything in recent history that would cause such a change so I want to make sure we have a record of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:32:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:32:32 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.31097f8903379fe251e82e9da886395e@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #13309 Comment: We should also use `liftA2` when appropriate, which can as much as halve allocation in some cases. That is ticket #13309. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:32:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:32:58 -0000 Subject: [GHC] #13309: Use liftA2 in ApplicativeDo In-Reply-To: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> References: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> Message-ID: <060.e0645ea9bb68497da496fd07e026b5b5@haskell.org> #13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10892 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #10892 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:42:34 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows In-Reply-To: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> References: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> Message-ID: <061.532ff8ad27e75b596fab78a0cdffa89b@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by bgamari): I suspect the cause is described by [[https://msdn.microsoft.com/en- us/library/windows/desktop/ms633585(v=vs.85).aspx|this]] quirk described on MSDN, > Note To write code that is compatible with both 32-bit and 64-bit versions of Windows, use GetWindowLongPtr. When compiling for 32-bit Windows, GetWindowLongPtr is defined as a call to the GetWindowLong function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 20:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 20:44:14 -0000 Subject: [GHC] #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows In-Reply-To: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> References: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> Message-ID: <061.45918f58c2e89e9f12520592c71ae884@haskell.org> #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Phyx-): The test has just never passed on x86 Windows. The failure is just simply a difference between the ABI of x86 and x86_64 Windows. x86 Windows is an underscore platform whilst x86_64 is not (no __cdecl). The normalizer that removes the paths for comparison doesn't take this into account, which is why the test fails. the regexpr has to be extended to normalise the symbol names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 21:00:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 21:00:19 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows In-Reply-To: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> References: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> Message-ID: <061.0c940dfc6ba2bd8f7c5ddec57c78e383@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Phyx-): Indeed, I have opened https://github.com/haskell/win32/issues/85 The fix is easy enough but the next version of Win32 (2.6.0.0) has breaking changes so I'll probably make a `2.5.4.0` with just this fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 21:51:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 21:51:03 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.58e7438dd3ec361594ddb90fd29eaf39@haskell.org> #13332: Report unrecognized pragmas earlier -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by richardfung): Looking into this a bit more, I think you're right in that the warning is generated. However, I am a little bit confused here because from what I've seen, the error is thrown in checkNoErrs. checkNoErrs calls failM so the warnings are indeed not shown. However, even when I print the messages from getErrsVar (via traceTc) there are no warnings. Is that because the warning is not a typecheck warning and thus not stored in the TcRnMonad? Also, it seems that there's not really a clear path forward on what to do with respect to this ticket. I've enjoyed looking into it as a means to learn more about the internals but I don't think I'm in a position to decide what the best thing to do here is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 21:59:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 21:59:35 -0000 Subject: [GHC] #13508: Clarify Some Restrictions on Compact Regions In-Reply-To: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> References: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> Message-ID: <064.6889fa370e8f264593879f6110c1e431@haskell.org> #13508: Clarify Some Restrictions on Compact Regions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: ezyang Type: bug | Status: patch Priority: lowest | Milestone: 8.2.1 Component: | Version: 8.1 libraries/compact | 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:D3407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): We should seriously think about how to set up a "can be compacted" type class, either by hand in the 'compact' package, or with special solver support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 22:11:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 22:11:57 -0000 Subject: [GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler In-Reply-To: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> References: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> Message-ID: <059.d158ee011708d89fa4286bc1579c5f37@haskell.org> #13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Hi vanto, do you need this specifically for something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 2 23:34:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Apr 2017 23:34:11 -0000 Subject: [GHC] #13513: Incorrect behavior on arm64 with optimisations In-Reply-To: <047.a4ba0434831678c830befedb77f73790@haskell.org> References: <047.a4ba0434831678c830befedb77f73790@haskell.org> Message-ID: <062.4f6cbe013bbe7e2d211688fab75b32d3@haskell.org> #13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: erikd, angerman (added) * milestone: => 8.4.1 Comment: Very interesting. I wish I had hardware to test this one. Adding erikd and angerman, who have both done work on aarch64 in the past. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 02:13:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 02:13:42 -0000 Subject: [GHC] #13126: Support for hexadecimal floats In-Reply-To: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> References: <045.78755c3363c3135e2f66061ffc2a520b@haskell.org> Message-ID: <060.ce13a4f501d26f32baa1aeca8e4a8dd4@haskell.org> #13126: Support for hexadecimal floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) 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): Phab:D3066 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D3066 Comment: And an implementation at Phab:D3066 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 04:10:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 04:10:36 -0000 Subject: [GHC] #13309: Use liftA2 in ApplicativeDo In-Reply-To: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> References: <045.0874e12bcfabf449003f3d4de58526a5@haskell.org> Message-ID: <060.3c3c27070437a94864817727bfbabc76@haskell.org> #13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10892 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: dfeuer => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 06:45:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 06:45:44 -0000 Subject: [GHC] #13516: broken pipe when printing infinite list (maybe interrupt handler error?) Message-ID: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> #13516: broken pipe when printing infinite list (maybe interrupt handler error?) --------------------------------------+------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: broken pipe | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- {{{#!hs shell> ghc -e "mapM print [1..]" 1 2 3 ... 44435 Ctrl^Z : user interrupt ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): : hFlush: resource vanished (Broken pipe) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 06:51:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 06:51:26 -0000 Subject: [GHC] #13373: Handle long file paths on Windows In-Reply-To: <045.872d530b642536033e5f70fd0cb14d01@haskell.org> References: <045.872d530b642536033e5f70fd0cb14d01@haskell.org> Message-ID: <060.4588372adb32fa4a7836077e6c622371@haskell.org> #13373: Handle long file paths on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:6 Rufflewind]: > TL;DR: It does not seem possible to set the current directory to a long path except through the Win-10 only mechanism. It cannot be set at once... but what about getting there in multiple steps as a workaround with multiple `SetCurrentDirectoryW` calls, where the first one uses an absolute path, and the subsequent ones use relative paths? I know... I'm two days late for such suggestions :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 07:30:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 07:30:49 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.dedb3d114ce9a5777ba349143179e542@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400 -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: rwbarton => (none) * resolution: fixed => Comment: Ben, I'm puzzled here. This commit seems to implement comment:15 (in `rebuildCase`) but not comment:11 and its antecedents. How does your commit relate to Reid's work on this ticket? And did this one change cure the leak? Reid thinks not? I'd like to work through comment:19 too. Moreover, presumably the commit you did make (in `rebuildCase`) presumably does help something substantially, or you would not have done it (esp given its equivocal effect on other perf tests). But neither the commit message, nor (more importantly) the comment in the code, says what! `DynFlags` perhaps? Please say, so that someone wondering if they can now take it out knows what they have to test against. I'm re-opening pending resolving some of these mysteries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 07:36:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 07:36:38 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.b47f6667f0d14f9bbaad1ef1b37fef1d@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: lukemaurer => (none) * status: closed => new * resolution: fixed => Comment: comment:31 not yet attended to, so re-opening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 08:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 08:32:49 -0000 Subject: [GHC] #13517: No warnings produced, yet the pattern matching fails at runtime. Message-ID: <054.96be821451657586c9b8c45a393039e9@haskell.org> #13517: No warnings produced, yet the pattern matching fails at runtime. -------------------------------------+------------------------------------- Reporter: | Owner: (none) timotej.tomandl | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code below should produce a warning about a non-exhaustive pattern in the failure, yet it compiles alright. {{{ #!div style="font-size: 80%" {{{#!haskell {-# OPTIONS_GHC -Wall -Werror #-} action :: (Monad m)=>t->m (Maybe a) action _=return Nothing failure :: (Monad m)=>Int->(m Int) failure x=do Just y<-action x return y main :: IO() main=do y<-failure 1 putStrLn $ (show y) }}} }}} The same should be the case if we replace the definition of failure with {{{ #!div style="font-size: 80%" {{{#!haskell failure :: (Monad m)=>Int->(m Int) failure x=(action x)>>=(\(Just y)->return y) }}} }}} yet once again no warnings are produced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 08:40:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 08:40:26 -0000 Subject: [GHC] #13513: Incorrect behavior on arm64 with optimisations In-Reply-To: <047.a4ba0434831678c830befedb77f73790@haskell.org> References: <047.a4ba0434831678c830befedb77f73790@haskell.org> Message-ID: <062.eba0c551fded539c9f4d31a3eb4f2781@haskell.org> #13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I used to have access to an aarch64 machine (via ssh across the Pacific) but unfortunately, do not any more. Happy to be CCed and offer whatever help I can. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 09:45:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 09:45:53 -0000 Subject: [GHC] #13513: Incorrect behavior on arm64 with optimisations In-Reply-To: <047.a4ba0434831678c830befedb77f73790@haskell.org> References: <047.a4ba0434831678c830befedb77f73790@haskell.org> Message-ID: <062.824b324cf8fea7e0936ae012d3c2f8f5@haskell.org> #13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by achirkin): I feel I need to add more information here for one who decides to work on this. At first, I use two Ubuntu 16.04 machines to test it: Samsung Chromebook plus (arm64) and x86_64 machine with static arm64 qemu (was quite easy to set up using following instructions [https://wiki.debian.org/Arm64Qemu]). The second one runs quite slow; e.g. fully optimized build of GHC takes 10-20 hours. I compiled several versions of GHC-8.0.2 and saved configuration/build options I used; accessible by the following link [https://drive.google.com/open?id=1aO4owbg8oAt7F3tjfPXUntmaEXBj_6HH7aNgRFfftik]. Ticket [https://ghc.haskell.org/trac/ghc/ticket/10174] says that somebody failed to compile GHC using quick-llvm, but succeeded using perf-llvm. This might be related to my issue. In contrast to 10174, [https://ghc.haskell.org/trac/ghc/ticket/10383] shows that some tests fail with optimization, but pass without it. {{{ $ ghc --info [ ("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld.gold") ,("ld flags"," -z noexecstack") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchARM64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","/usr/bin/llc-3.7") ,("LLVM opt command","/usr/bin/opt-3.7") ,("Project version","8.0.2") ,("Project Git commit id","8c7250379d0d2bad1d07dfd556812ff7aa2c42e8") ,("Booter version","8.0.2") ,("Stage","2") ,("Build platform","aarch64-unknown-linux") ,("Host platform","aarch64-unknown-linux") ,("Target platform","aarch64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/ghc-8.0.2/lib/ghc-8.0.2") ,("Global Package DB","/usr/local/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d") ] }}} Finally, for those who want to try unregisterized build of ghc-8.0.2 on arm right now, these stack options are working for me (precompiled stack and ghc can be found in my google drive): {{{ $ cat ~/.stack/config.yaml system-ghc: true jobs: 4 local-bin-path: /home/achirkin/.local/stackbin ghc-options: "*": -O1 -fllvm -fliberate-case -fregs-graph -fspec-constr -optlc-O3 apply-ghc-options: everything }}} The ghc options I specified are the closest ones to `-O2` that do not cause the strange bug discussed in this ticket (at least, for me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 10:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 10:16:54 -0000 Subject: [GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler In-Reply-To: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> References: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> Message-ID: <059.a5341a6b9d38b8bb38f3e349cf9c0282@haskell.org> #13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hi ezyang,\\ Yes, it is another way to pay tribute to the elders and also to the new ones who have been or are now part of the Committee.\\ I will soon make a proposal for that.\\ Everyone can already give an opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 10:44:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 10:44:30 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD Message-ID: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I'm trying to implement `Float` <-> `Word32` bit casts (`Double` <-> `Word64` works fine) in CMM using: {{{ stg_word32ToFloatzh(I32 w) { F_ f; P_ ptr; STK_CHK_GEN_N (FLOAT_STACK_WDS); reserve FLOAT_STACK_WDS = ptr { I32[ptr] = w; f = F_[ptr]; } return (f); } stg_floatToWord32zh(F_ f) { I32 w; P_ ptr; STK_CHK_GEN_N (FLOAT_STACK_WDS); reserve FLOAT_STACK_WDS = ptr { I32[ptr] = f; w = I32[ptr]; } return (w); } }}} This compiles correctly and passes all tests with ghc 8.0.2, but compiling the above CMM with git HEAD (currently 1e58efb16f7) results in: {{{ Cmm lint error: in basic block cq in assignment: _cj::I32 = R1; Reg ty: I32 Rhs ty: I64 Program was: {offset cq: // global _cj::I32 = R1; //tick src goto cm; cm: // global if ((old + 0) - 8 / 8 < SpLim) (likely: False) goto co; else goto cp; co: // global I64[(young + 8)] = cn; call stg_gc_noregs() returns to cn, args: 8, res: 8, upd: 8; cn: // global goto cm; cp: // global _cl::P64 = (old + 16); //tick src I32[_cl::P64] = _cj::I32; _ck::F32 = F32[_cl::P64]; F1 = _ck::F32; call (P64[(old + 8)])(F1) args: 8, res: 0, upd: 8; } }}} ghc 8.0.2 is accepts this code and gives the correct results, so I can only assume that git HEAD is incorrect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 10:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 10:45:06 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.50953242239c7edac1e9b5d3ba57aa0f@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * failure: Other => Incorrect error/warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 11:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 11:07:05 -0000 Subject: [GHC] #13509: Perplexing type error In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.f98c930ce431fd2e1f0c5c88c923ad3a@haskell.org> #13509: Perplexing type error -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Even shorter repro case {{{ {-# LANGUAGE UnboxedTuples, MagicHash #-} module T13509 where import GHC.Exts import Data.Word selectPower :: Word# -> (# Word#, Word# #) selectPower base = go base where go :: Word# -> (# Word#, Word# #) go pw = let (# n, pw2n #) = go pw in (# n `timesWord#` 2##, pw2n #) }}} This compiles. Commenting out the signature for `go` makes it fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 12:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 12:35:56 -0000 Subject: [GHC] #13519: hWaitForInput does not work on linux. Message-ID: <054.27aaf9dcd2702cf6994ac888c1e691f2@haskell.org> #13519: hWaitForInput does not work on linux. -------------------------------------+------------------------------------- Reporter: | Owner: (none) junji.hashimoto | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- hWaitForInput does not work on linux. When hWaitForInput has non-zero waiting time, it always fails. The code is following ghci-code. This is because inputReady.c (https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/cbits/inputReady.c#L27) does not allow 'msecs != 0'. {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :m + System.IO Prelude System.IO> f <-openFile "stack.yaml" ReadMode Prelude System.IO> hWaitForInput f 10 fdReady: msecs != 0, this shouldn't happenAborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 12:51:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 12:51:11 -0000 Subject: [GHC] #13519: hWaitForInput does not work on linux. In-Reply-To: <054.27aaf9dcd2702cf6994ac888c1e691f2@haskell.org> References: <054.27aaf9dcd2702cf6994ac888c1e691f2@haskell.org> Message-ID: <069.d4e60c5d0ef4a6e0eb3ed4a8c64e623b@haskell.org> #13519: hWaitForInput does not work on linux. -------------------------------------+------------------------------------- Reporter: junji.hashimoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by junji.hashimoto): * component: Compiler => Core Libraries * os: Unknown/Multiple => Linux * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 14:38:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 14:38:24 -0000 Subject: [GHC] #13517: No warnings produced, yet the pattern matching fails at runtime. In-Reply-To: <054.96be821451657586c9b8c45a393039e9@haskell.org> References: <054.96be821451657586c9b8c45a393039e9@haskell.org> Message-ID: <069.de330a0617ec8e8de34a12d9e5223625@haskell.org> #13517: No warnings produced, yet the pattern matching fails at runtime. -------------------------------------+------------------------------------- Reporter: timotej.tomandl | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Both of these examples are working as expected, for some definition of "expected". One thing to note here: the versions of `failure` you've given are not quite semantically equivalent. I'll go over the second example first, since it's easier to explain: {{{#!hs failure :: (Monad m)=>Int->(m Int) failure x=(action x)>>=(\(Just y)->return y) }}} You're right—this is partial, and moreover, `-Wall` doesn't warn about this. There //is// a flag that warns about this, however: `-Wincomplete- uni-patterns`. As for why it's not a part of `-Wall`, [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/using- warnings.html#ghc-flag--Wincomplete-uni-patterns to quote the users' guide:] > This option isn’t enabled by default because it can be a bit noisy, and it doesn’t always indicate a bug in the program. However, it’s generally considered good practice to cover all the cases in your functions, and it is switched on by `-W`. So you can enable `-Wincomplete-uni-patterns` or `-W` if you want a warning for this. Now, back to the first example: {{{#!hs failure :: (Monad m)=>Int->(m Int) failure x=do Just y<-action x return y }}} Pattern matching in `do`-notation is handled a bit differently than in other contexts. The Haskell Report has [https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-470003.14 a nice section] on this. Effectively, that implementation of `failure` gets desugared down to this: {{{#!hs failure :: Monad m => Int -> m Int failure x = let ok (Just y) = return y ok _ = fail "Pattern match failure in do expression..." in action x >>= ok }}} Which is actually total! But it does rely on the `fail` method of `Monad`, which some find a bit unsavory. Relatedly, `fail` will eventually be [https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail split out] of `Monad` and into a separate `MonadFail` class at some point in the future. It's important to note that not all implementations of `fail` throw exceptions. For instance, here are some demonstrations of `failure` used on particular `Monad`s: {{{ λ> failure 1 :: IO Int *** Exception: user error (Pattern match failure in do expression at Bug.hs:7:5-10) λ> failure 1 :: Maybe Int Nothing λ> failure 1 :: [Int] [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 15:37:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 15:37:20 -0000 Subject: [GHC] #13513: Incorrect behavior on arm64 with optimisations In-Reply-To: <047.a4ba0434831678c830befedb77f73790@haskell.org> References: <047.a4ba0434831678c830befedb77f73790@haskell.org> Message-ID: <062.d11442aaa4973988877074dddd5ef78a@haskell.org> #13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by achirkin): * Attachment "testsuite_summary.txt" added. Run GHC testsuite: make fasttest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 16:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 16:31:27 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.c41d07b26643cd54b10cc1dd6a1a14a2@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, yes, fair point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 16:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 16:33:22 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.72a5d72b8674be26132e7f5812faf68e@haskell.org> #13332: Report unrecognized pragmas earlier -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: newcomer => Comment: I investigated this today. The relevant code path starts in `ghc/Main.hs` under the comment "do the business" which catches and displays errors. Warnings on the other hand are dealt with by `runHsc` and are already baked into the `HscMonad`. The main logic of how the parser and type checker link together is in `hscTypecheck`. The typechecker is invoked by the `tcRnModule` function but wrapped with `ioMsgMaybe` which throws an error if the typechecker fails. It seems like the best solution would be to also stop using `throwIO` to report errors and also bake them into the `Hsc` type so that `runHsc` deals with throwing both warnings and exceptions so we can isolate the logic and which are displayed into one place. I fear that this would be quite a difficult change as a lot of the compiler is designed using these unchecked exceptions. Thanks for looking at this Richard but I agree that it's not very easy to fix properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 16:37:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 16:37:01 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.51d4b97bb1beb30c924cac563bb1be19@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Assuming that this is on a 64-bit machine it seems to me that the Cmm lint error here is absolutely correct. You are assigning a 64-bit value to a 32-bit register. You would need to use one of the narrowing operations to do this correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 16:42:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 16:42:06 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.e6e1a6f537c930255d866bc290d1d909@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To clarify, I think this would need to look something like, {{{ reserve FLOAT_STACK_WDS = ptr { I32[ptr] = %sx32(w); f = F_[ptr]; } -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 18:05:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 18:05:01 -0000 Subject: [GHC] #13520: instance Alternative ZipList Message-ID: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The paper "From monoids to near-semirings: the essence of MonadPlus and Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 18:05:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 18:05:43 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.a87d54b2e521ae6cc7ed948240819ee5@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * type: bug => feature request Old description: > The paper "From monoids to near-semirings: > the essence of MonadPlus and Alternative`" mentions > > > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. > Like the `Alternative` instance for `Maybe`, the one for `ZipList` has > a left bias. > > > > {{{#!hs > > instance Alternative ZipList where > > empty :: ZipList a > > empty = ZL [] > > > > (<|>) :: ZipList a -> ZipList a -> ZipList a > > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > > }}} > > Has this been considered for base? New description: The paper "From monoids to near-semirings: the essence of `MonadPlus` and `Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 18:06:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 18:06:35 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.241d8e7375b0eecab0f77510ac47e503@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > The paper "From monoids to near-semirings: > the essence of `MonadPlus` and `Alternative`" mentions > > > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. > Like the `Alternative` instance for `Maybe`, the one for `ZipList` has > a left bias. > > > > {{{#!hs > > instance Alternative ZipList where > > empty :: ZipList a > > empty = ZL [] > > > > (<|>) :: ZipList a -> ZipList a -> ZipList a > > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > > }}} > > Has this been considered for base? New description: The paper "From monoids to near-semirings: the essence of `MonadPlus` and `Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. > Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 18:07:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 18:07:10 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.a56fdd34fdfa21a0b2d9d94bf5dcc772@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > The paper "From monoids to near-semirings: > the essence of `MonadPlus` and `Alternative`" mentions > > > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. > > Like the `Alternative` instance for `Maybe`, the one for `ZipList` has > a left bias. > > > > {{{#!hs > > instance Alternative ZipList where > > empty :: ZipList a > > empty = ZL [] > > > > (<|>) :: ZipList a -> ZipList a -> ZipList a > > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > > }}} > > Has this been considered for base? New description: The paper "From monoids to near-semirings: the essence of `MonadPlus` and `Alternative`" mentions > Perhaps surprisingly, `ZipList`s have an `Alternative` instance. > Like the `Alternative` instance for `Maybe`, the one for `ZipList` has a left bias. > > {{{#!hs > instance Alternative ZipList where > empty :: ZipList a > empty = ZL [] > > (<|>) :: ZipList a -> ZipList a -> ZipList a > ZL xs <|> ZL ys = ZL (xs ++ drop (length xs) ys) > }}} Has this been considered for base? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 19:29:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 19:29:05 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.b497379d98121a2e8e243d8972e673b4@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 RyanGlScott): * keywords: => newcomer Comment: Indeed it has! See https://mail.haskell.org/pipermail/libraries/2015-July/025975.html, where it garnered a general consensus of support. Now all we need is someone to submit the patch which implements this. Will you be the one? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 20:18:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 20:18:59 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.434b9984aa44c19d3cd1650aa4804793@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I tried the `%sx32` but get the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 21:03:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 21:03:43 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.5518126e85d22e293f7d250843c5784e@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: patch 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): Phab:D3212 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3212 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 21:23:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 21:23:36 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.dbc51248c13debe1c216ca5fa4f958c0@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: I've found a few issues: - the implementations are slightly nonsymmetric (floatToWord# lacked F_ cast) - i suspect cmm won't allow you to have non-Word sized integrals (the first error you get) - integral return type should also be Word-sized That compiles for me on both 32/64 targets: {{{ #include "Cmm.h" stg_word32ToFloatzh(W_ w) { F_ f; P_ ptr; STK_CHK_GEN_N (1); reserve 1 = ptr { I32[ptr] = W_TO_INT(w); f = F_[ptr]; } return (f); } stg_floatToWord32zh(F_ f) { W_ w; P_ ptr; STK_CHK_GEN_N (1); reserve 1 = ptr { F_[ptr] = f; w = TO_W_(I32[ptr]); } return (w); } }}} {{{ $ m68k-unknown-linux-gnu-ghc -c a.cmm -dcmm-lint -O2 $ powerpc64le-unknown-linux-gnu-ghc -c a.cmm -dcmm-lint -O2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 21:55:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 21:55:58 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn In-Reply-To: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> References: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> Message-ID: <061.db8fe64f9ab1e937ef015724158c1abd@haskell.org> #13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3170 Wiki Page: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > When introducing type-in-type, Richard elaborated the free varaible > finder so that it finds three things at once (in `CoreFV`): > {{{ > data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression > , fva_ty_fvs :: DVarSet -- free only in expression's > type > , fva_ty :: Type -- expression's type > } > }}} > I think `fva_ty` is needed only to support `fva_ty_fvs`. And > `fva_ty_fvs` seems to be used only to support the calls to > `freeVarsOfType` in `FloatIn`. And those calls in turn are only to > suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. > > In conversation yesterday, Richard and I agreed that all this is > unnecessary. Coercion bindings simply do not float inwards, so we do not > need to take these precautions. (We should add a Note to explain why > they don't float, and what problem might arise if they did.) > > To confirm this I set `used_in_ty` to `False` and compiled from scratch; > everything is fine. > > So I propose that we > > * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` > * simplfy `FVAnn` to just gather free variables (ie one field only) > > Result: it's all simpler. > > Richard will do this when he gets a moment. But I really hope for 8.2 New description: When introducing type-in-type, Richard elaborated the free variable finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. But I really hope for 8.2 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 22:04:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 22:04:20 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.ecc701e4d25b253bb333ff621e8579d9@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): > That compiles for me on both 32/64 targets: With GHC git HEAD? I've got something that with with ghc 8.0.2, but I can't get it to work with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 22:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 22:13:08 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.50461744b8c8728b179a03afaa6ba79a@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): The snippet from #comment:5 compiles on: powerpc64le-unknown-linux-gnu-ghc-8.3.20170402 changeset:852a43f360af09416d15777c8f10d704b5423a96 m68k-unknown-linux-gnu-ghc-8.3.20170403 changeset:1e58efb16f76b52c059d5e5d6c4c5d91c2abaad2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 22:38:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 22:38:37 -0000 Subject: [GHC] #13422: INLINE CONLIKE sometimes fails to inline In-Reply-To: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> References: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> Message-ID: <060.c15cd0e6be0e8de444e0f22c20441cbf@haskell.org> #13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Reproduction instructions: Clone the `wip/cheapBuild` branch. Compile the following file: {{{#!hs module Ischeap where import Data.List foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} using `ghc-stage2` with `-O2 -ddump-simpl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 22:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 22:55:02 -0000 Subject: [GHC] #4374: Remove in-tree gmp In-Reply-To: <044.575b6a5cf46d3389303e9ef7b4655e5d@haskell.org> References: <044.575b6a5cf46d3389303e9ef7b4655e5d@haskell.org> Message-ID: <059.505714d909630f99450c0ebe6d1c1b77@haskell.org> #4374: Remove in-tree gmp -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8156, #7655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #8156 => #8156, #7655 Comment: Also see #7655 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:18:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:18:09 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.f281bd6bb2e643fe31eeead4abbe5f28@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400 -------------------------------------+------------------------------------- Comment (by bgamari): I'll have to defer to Reid on this. I merely merged the patch he provided in response to my request for a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:28:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:28:41 -0000 Subject: [GHC] #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows In-Reply-To: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> References: <046.085d5d4204c467ff87c6d5281d72775d@haskell.org> Message-ID: <061.58fd0c5440ad278692dda4ff1d9c31a4@haskell.org> #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by bgamari): This has been fixed upstream. Need to bump `Win32` submodule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:37:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:37:59 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.75ee677b399659a1fd8fd223f5af5ae1@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: dterei => michalt Comment: This is Michal's domain currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:49:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:49:57 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.d8a0b4a36c05f0df89fa4c0d78e26ba3@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Wow, something really subtle is going on. Pasting your exact code made it work. Using `FLOAT_STACK_WDS` set to `2` to get stack alignment correct didn't. It even passes the test! Just need to clean it up and get it up on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:51:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:51:34 -0000 Subject: [GHC] #12461: Document -O3 In-Reply-To: <047.3f32e602233425465e11e52a3692f683@haskell.org> References: <047.3f32e602233425465e11e52a3692f683@haskell.org> Message-ID: <062.c74b9e0fe7d92ad0ca59c590a01d0ca6@haskell.org> #12461: Document -O3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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 mpickering): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:58:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:58:11 -0000 Subject: [GHC] #13521: Remove comments about API annotations Message-ID: <049.3bd3ebae9a4504c7b325699da41e840f@haskell.org> #13521: Remove comments about API annotations -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are lots of comments scattered around the code which look like {{{ -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation }}} these are meant to tell you which annotations are associated with each syntax element. They were added in an heroic effort by alanz but are very hard to keep up to date and verify the correctness of. It would be much better if we had a programatic description of which annotations could be attached to which syntax elements and thankfully one already exists in `ghc-exactprint`. This library isn't in the source tree but I don't think this really matters, users can just depend on it if they want to use them. I think we should remove all these comments to clean up the source a bit and point users to `ghc-exactprint` from the `ApiAnnotations` page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 3 23:59:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Apr 2017 23:59:39 -0000 Subject: [GHC] #12461: Document -O3 In-Reply-To: <047.3f32e602233425465e11e52a3692f683@haskell.org> References: <047.3f32e602233425465e11e52a3692f683@haskell.org> Message-ID: <062.a56f6fb15530d107e13d7a17d7e0e40d@haskell.org> #12461: Document -O3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Comment (by crockeea): I still feel this behavior should be documented. GHC accepts a mysterious argument, but doesn't say anything about what happens when you pass it -O3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:08:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:08:31 -0000 Subject: [GHC] #13516: broken pipe when printing infinite list (maybe interrupt handler error?) In-Reply-To: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> References: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> Message-ID: <059.296367e796892a9f1264855b8cfa2ff9@haskell.org> #13516: broken pipe when printing infinite list (maybe interrupt handler error?) -------------------------------+-------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: broken pipe Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by mpickering): * cc: Phyx- (added) Comment: Doesn't happen for me on OS X. Have you seen this before Tamar? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:09:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:09:37 -0000 Subject: [GHC] #13516: broken pipe when interrupting on Windows (was: broken pipe when printing infinite list (maybe interrupt handler error?)) In-Reply-To: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> References: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> Message-ID: <059.67fb1fb1590a1c4ca984b1b8e0d54565@haskell.org> #13516: broken pipe when interrupting on Windows -------------------------------+-------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: broken pipe Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:11:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:11:03 -0000 Subject: [GHC] #13509: Perplexing type error with unboxed tuples (was: Perplexing type error) In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.19b86b0fa7aef7e55026b4d26f770278@haskell.org> #13509: Perplexing type error with unboxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:14:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:14:17 -0000 Subject: [GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler In-Reply-To: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> References: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> Message-ID: <059.039697d2f20d7f88cd0289371372cea5@haskell.org> #13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It isn't clear to me who the current committee is meant to be. The people who have commit access is already listed on the [https://ghc.haskell.org/trac/ghc/wiki/TeamGHC wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:14:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:14:32 -0000 Subject: [GHC] #13512: GHC incorrectly warns that a variable used in a type application is unused In-Reply-To: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> References: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> Message-ID: <065.d6688f3c808837894f72a8d90be91649@haskell.org> #13512: GHC incorrectly warns that a variable used in a type application is unused -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: TypeApplications => TypeApplications, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:15:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:15:48 -0000 Subject: [GHC] #9596: Create monoidal category framework for arrow desugarer In-Reply-To: <050.5943b671786c1c07283b6317d06d031c@haskell.org> References: <050.5943b671786c1c07283b6317d06d031c@haskell.org> Message-ID: <065.16adea88e4e56a1efc4a187a0481cdf5@haskell.org> #9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: spacekitteh Type: task | Status: closed Priority: normal | Milestone: Component: GHC API | Version: Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7828 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => wontfix Comment: This ticket is a bit nebulous. The link to the blog post is also dead so I will close it unless further information is made available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:18:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:18:46 -0000 Subject: [GHC] #13516: broken pipe when interrupting on Windows In-Reply-To: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> References: <044.57550189f00ceea809a0cbc3f4f15dfd@haskell.org> Message-ID: <059.88dfc969cdbd2e65bf51608c15952973@haskell.org> #13516: broken pipe when interrupting on Windows ----------------------------------+-------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: broken pipe Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13396 #13359 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Phyx-): * related: => #13396 #13359 Comment: I haven't seen this particular panic, but I do know the rts does panic when interrupted on Windows. I am however currently punting these tickets till the console I/O has been replaced by native ones as I'm having a hard time getting the interrupt handler to fire deterministically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 00:28:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 00:28:14 -0000 Subject: [GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout In-Reply-To: <042.260955fa92da12cf89056e026fcec607@haskell.org> References: <042.260955fa92da12cf89056e026fcec607@haskell.org> Message-ID: <057.3a221d38019597af7db06f3173864972@haskell.org> #10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #1741 | 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 Apr 4 01:23:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 01:23:26 -0000 Subject: [GHC] #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC In-Reply-To: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> References: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> Message-ID: <057.fad5946b25c4de3fe2c041b01594774c@haskell.org> #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC -------------------------------------+------------------------------------- Reporter: jms | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 70530b42c41d97a8accd3e8565b4fa31ca80b5d6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 01:34:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 01:34:49 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows In-Reply-To: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> References: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> Message-ID: <061.fb1092b4dfebb14921a0d4e8ae25d6ef@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by Ben Gamari ): In [changeset:"e815901d8f1d0e8c6916fcf0e87c68998475407e/ghc" e815901d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e815901d8f1d0e8c6916fcf0e87c68998475407e" Bump Win32 submodule Fixes #13514. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 01:34:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 01:34:49 -0000 Subject: [GHC] #13508: Clarify Some Restrictions on Compact Regions In-Reply-To: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> References: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> Message-ID: <064.cbf96d744b20d23459cf18a8f50b43d1@haskell.org> #13508: Clarify Some Restrictions on Compact Regions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: ezyang Type: bug | Status: patch Priority: lowest | Milestone: 8.2.1 Component: | Version: 8.1 libraries/compact | 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:D3407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"38f9eadd8e4746c2fabf83045073134f5a554a06/ghc" 38f9ead/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38f9eadd8e4746c2fabf83045073134f5a554a06" compact: Clarify mutability restriction Fixes #13508. [skip ci] Test Plan: Read it Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3407 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 03:01:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 03:01:50 -0000 Subject: [GHC] #13522: unhandled ELF relocation(RelA) type 19 Message-ID: <047.514a32773a571e9b96667baeaa92aec0@haskell.org> #13522: unhandled ELF relocation(RelA) type 19 -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Linking) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to build accelerate-llvm(http://hackage.haskell.org/package /accelerate-llvm-1.0.0.0) using GHC 8.0.2 (DYNAMIC_GHC_PROGRAMS = NO), I got the following errors: {{{ ghc: /usr/lib/llvm-4.0/lib/libLLVMAnalysis.a: unhandled ELF relocation(RelA) type 19 ghc: Could not on-demand load symbol '_ZN4llvm30initializeAAEvalLegacyPassPassERNS_12PassRegistryE' ghc: /usr/lib/llvm-4.0/lib/libLLVMAnalysis.a: unknown symbol `_ZN4llvm30initializeAAEvalLegacyPassPassERNS_12PassRegistryE' ghc: Could not on-demand load symbol 'LLVMVerifyModule' ghc: /home/alang/src/tsuru/trader/_mk/8.0.2/extsrc/install/lib/x86_64 -linux-ghc-8.0.2/llvm-hs-4.0.1.0-ENiuGLzCFNYJ02bgm8NYWg/HSllvm- hs-4.0.1.0-ENiuGLzCFNYJ02bgm8NYWg.o: unknown symbol `LLVMVerifyModule' ghc: unable to load package `llvm-hs-4.0.1.0' }}} Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-51-generic x86_64), gcc version 5.4.0 20160609, ld 2.26.1 This seems to happen in an other environment (ubuntu 14.04. ghc 8.0.2, gcc 4.8.4, ld 2.24). GitHub issue: https://github.com/AccelerateHS/accelerate/issues/369 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 03:27:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 03:27:45 -0000 Subject: [GHC] #13422: INLINE CONLIKE sometimes fails to inline In-Reply-To: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> References: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> Message-ID: <060.0b5b9074de4846d31cb6d054584ae686@haskell.org> #13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've quickly looked at this and it seems that one crucial difference is that when `n` is banged the first phase simplifier considers it to be a `ValueArg` as it has a conlike unfolding, whereas without it is merely ` TrivialArg`. At first simplification proceeds similarly in both cases, * `$fEnumInt_$cenumFromTo` * `sum` is inlined (the unfolding of which contains a `foldl`). It is interesting to note that the list argument is considered to be a `ValueArg` with the bang, but a `TrivialArg` without. * `foldl` is inlined * `$fNumInt_$cfromInteger` is inlined This is where the two programs diverge. While the `fold/cheapBuild` rule fires in the banged case, it fails to fire on the unbanged program. After that point, things obviously proceed much differently. While `cheapBuild` itself is eventually inlined in the unbanged version, it the fusion rule never fires. This is rather curious since, * the desugared core is identical between the banged and unbanged case * the performed inlinings are identical -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 03:28:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 03:28:36 -0000 Subject: [GHC] #13522: unhandled ELF relocation(RelA) type 19 In-Reply-To: <047.514a32773a571e9b96667baeaa92aec0@haskell.org> References: <047.514a32773a571e9b96667baeaa92aec0@haskell.org> Message-ID: <062.a570ec375fe4d2878c90438a18c1f00f@haskell.org> #13522: unhandled ELF relocation(RelA) type 19 -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: tmcdonell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 03:58:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 03:58:57 -0000 Subject: [GHC] #13508: Clarify Some Restrictions on Compact Regions In-Reply-To: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> References: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> Message-ID: <064.2eceee26c822075067b3cc6fbbcad916@haskell.org> #13508: Clarify Some Restrictions on Compact Regions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: ezyang Type: bug | Status: closed Priority: lowest | Milestone: 8.2.1 Component: | Version: 8.1 libraries/compact | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3407 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 03:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 03:59:10 -0000 Subject: [GHC] #13508: Clarify Some Restrictions on Compact Regions In-Reply-To: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> References: <049.b8e964864d639de324ebf0fdc7842c44@haskell.org> Message-ID: <064.04bafe67a1ccc076b663badbfcdfe50c@haskell.org> #13508: Clarify Some Restrictions on Compact Regions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: ezyang Type: bug | Status: closed Priority: lowest | Milestone: 8.2.1 Component: | Version: 8.1 libraries/compact | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 04:00:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 04:00:15 -0000 Subject: [GHC] #12461: Document -O3 In-Reply-To: <047.3f32e602233425465e11e52a3692f683@haskell.org> References: <047.3f32e602233425465e11e52a3692f683@haskell.org> Message-ID: <062.54c3a84f3c2c447238fe761ce0fb5449@haskell.org> #12461: Document -O3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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): * status: closed => new * resolution: invalid => Comment: I agree, if the flag is accepted its behavior should be documented, even if it is currently a no-op. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 04:13:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 04:13:01 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.51676b546b122adb96603bb7fd09bd2e@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Given the adverse performance effects of comment:6 we have reverted it on `ghc-8.2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 06:22:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 06:22:09 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.4cd0e6b7aae4070fb9b1fb90541d31cd@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2811,#3398 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Benefits: Looks pretty. Disadvantages: If LANG is not set any attempts of reading ghc output by a haskell program you get this instead: `hGetContents: invalid argument (invalid byte sequence)` I think I've wasted much more time debugging this problem (in my scenario things are still broken) than actually looking at those pretty quotes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 06:27:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 06:27:29 -0000 Subject: [GHC] #13521: Remove comments about API annotations In-Reply-To: <049.3bd3ebae9a4504c7b325699da41e840f@haskell.org> References: <049.3bd3ebae9a4504c7b325699da41e840f@haskell.org> Message-ID: <064.2a91e44933e70be219a1242d6b880e30@haskell.org> #13521: Remove comments about API annotations -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * related: => #13012 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 08:24:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 08:24:05 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.3cd70da8a7ef7ca8034d54523d2a61db@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => invalid Comment: Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 08:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 08:57:00 -0000 Subject: [GHC] #13512: GHC incorrectly warns that a variable used in a type application is unused In-Reply-To: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> References: <050.687d21cbfd81cb6ee046dbe45731918c@haskell.org> Message-ID: <065.6ac097965f425cb66d9b2af1b3f57303@haskell.org> #13512: GHC incorrectly warns that a variable used in a type application is unused -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | TypeApplications, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ugh, yes, quite right. To fix this the renamer needs to propagate usages of type variables in a binding to their binding sites in the corresponding type signature. That is somewhat fiddly,and would require some refactoring in `RnBinds.rnValBindsRHS`. Volunteers welcome! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 08:58:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 08:58:31 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.40a865f9353a1c427e3258e5e03382a1@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: 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): simonmar: do you know what is happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 09:14:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 09:14:39 -0000 Subject: [GHC] #12650: Too many warnigns about consistentCafInfo In-Reply-To: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> References: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> Message-ID: <061.900309ef8a70a1333370fd77d2d909e1@haskell.org> #12650: Too many warnigns about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I looked at this a little bit this morning but I don't understand this part of the compiler well enough. Looking at the assertion code, it seems that `binding_is_caffy` is the truth about the binding and we are checking that it agrees with what we predicted earlier. 1. Why is this property checked at all? 2. Why it is predicted in CorePrep rather than discovered in CoreToStg? 3. How involved would it be to implement the suggestion in comment:1? I also observed this with a dictionary like Joachim did in the original example so perhaps there is something slightly wrong with the analysis of dictionaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 09:19:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 09:19:34 -0000 Subject: [GHC] #12650: Too many warnings about consistentCafInfo (was: Too many warnigns about consistentCafInfo) In-Reply-To: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> References: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> Message-ID: <061.f1880781609f051f330c58355ab473fc@haskell.org> #12650: Too many warnings about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > Building GHC with debug on yiedls in many (97!) warnings of the form > {{{ > WARNING: file compiler/stgSyn/CoreToStg.hs, line 252 > $fFunctorIOEnv True False > }}} > > The code in question is > {{{ > -- Assertion helper: this checks that the CafInfo on the Id matches > -- what CoreToStg has figured out about the binding's SRT. The > -- CafInfo will be exact in all cases except when CorePrep has > -- floated out a binding, in which case it will be approximate. > consistentCafInfo :: Id -> GenStgBinding Var Id -> Bool > consistentCafInfo id bind > = WARN( not (exact || is_sat_thing) , ppr id <+> ppr id_marked_caffy > <+> ppr binding_is_caffy ) > safe > where > safe = id_marked_caffy || not binding_is_caffy > exact = id_marked_caffy == binding_is_caffy > id_marked_caffy = mayHaveCafRefs (idCafInfo id) > binding_is_caffy = topStgBindHasCafRefs bind > is_sat_thing = occNameFS (nameOccName (idName id)) == fsLit "sat" > }}} > > It would be nice to have less warnings, to make them more useful. I don’t > know if the warning is not right, or if there is something that can be > fixed about the thing it is warning about. New description: Building GHC with debug on yields in many (97!) warnings of the form {{{ WARNING: file compiler/stgSyn/CoreToStg.hs, line 252 $fFunctorIOEnv True False }}} The code in question is {{{ -- Assertion helper: this checks that the CafInfo on the Id matches -- what CoreToStg has figured out about the binding's SRT. The -- CafInfo will be exact in all cases except when CorePrep has -- floated out a binding, in which case it will be approximate. consistentCafInfo :: Id -> GenStgBinding Var Id -> Bool consistentCafInfo id bind = WARN( not (exact || is_sat_thing) , ppr id <+> ppr id_marked_caffy <+> ppr binding_is_caffy ) safe where safe = id_marked_caffy || not binding_is_caffy exact = id_marked_caffy == binding_is_caffy id_marked_caffy = mayHaveCafRefs (idCafInfo id) binding_is_caffy = topStgBindHasCafRefs bind is_sat_thing = occNameFS (nameOccName (idName id)) == fsLit "sat" }}} It would be nice to have less warnings, to make them more useful. I don’t know if the warning is not right, or if there is something that can be fixed about the thing it is warning about. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 10:18:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 10:18:24 -0000 Subject: [GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler In-Reply-To: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> References: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> Message-ID: <059.9c8830e0ed3cb6824fb3f2d5f3543064@haskell.org> #13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hi mpickering,\\ Yes and that's good!. Well! I will explain in this way:\\ The Wills Memorial Building is located in Bristol. It can also be found on postcards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 11:40:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 11:40:03 -0000 Subject: [GHC] #12650: Too many warnings about consistentCafInfo In-Reply-To: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> References: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> Message-ID: <061.b8b311ecfeab108d90b832eb65adcb18@haskell.org> #12650: Too many warnings about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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 simonpj): See #9718, which answers (2). For (1) we check because if the predication is incorrect (e.g. says that it has no CAF refs when actually it does) we could fail to keep stuff alive during GC that was alive, with resulting seg-faults. Re (3), not too hard! And very valuable. See #9718. I'm keen to get this done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 12:59:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 12:59:13 -0000 Subject: [GHC] #13522: unhandled ELF relocation(RelA) type 19 In-Reply-To: <047.514a32773a571e9b96667baeaa92aec0@haskell.org> References: <047.514a32773a571e9b96667baeaa92aec0@haskell.org> Message-ID: <062.4cd3664d3cbb9ae69151b1e1e1c88de8@haskell.org> #13522: unhandled ELF relocation(RelA) type 19 -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like this is relocation type `R_X86_64_TLSGD`. I believe this relocation may be described by either this[[http://www.fsfla.org/~lxoliva/writeups/TLS/RFC- TLSDESC-x86.txt|this]] or [[http://people.redhat.com/drepper/tls.pdf|that]] document. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 13:06:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 13:06:34 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.e1c71f86b3e4c4d42edb076639db04ea@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The `do` expression doesn't match the requirements as described in the docs, so I don't think it's a bug. Perhaps we could expand the heuristics to handle this case, but then the docs would get more complicated, and where does it end? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 13:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 13:16:15 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.060700371a9e1d734736ae39e32b5b54@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnislaih): Fair enough. I wasn't aware that Applicativedo didn't handle let bindings, and neither was anyone in #ghc for what it's worth. The docs ought to make this more evident. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 13:43:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 13:43:51 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.0b5384e160b86c7c54898171941b09d2@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It depends what you mean by "doesn't handle". It does have some heuristics to collect let bindings and prevent them from causing spurious dependencies, but that's aimed more at using Applicative with Monad, rather than the Applicative-only context. If there's a way to expand the desugaring that would also be simple to describe, then I wouldn't be averse to adding it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 14:20:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 14:20:30 -0000 Subject: [GHC] #13422: INLINE CONLIKE sometimes fails to inline In-Reply-To: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> References: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> Message-ID: <060.b5aac50f8ad5293ef4b844146a7e7edd@haskell.org> #13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's the reason. We get {{{ let xs = case n of I# n1 -> cheapBuild blah in ...(foldr k z xs)...(foldr k2 z2 xs)... }}} So the `cheapBuild` is hidden behind that `case n` and the `foldr/cheapBuild` rule does not fire. The problem comes from {{{ instance Enum Int where ... enumFromTo (I# x) (I# y) = eftInt x y }}} So `[1..n]` desugars into `(case n of I# n' -> eftInt 1# n')`. This doesn't hurt normal foldr/build because if we see {{{ foldr k z (case n of I# n' -> build blah) }}} we know that `foldr` is strict and so float the case outwards. This doesn't happen with the `cheapBuild` stuff since the producer and consumer are further apart. But the solution is, I think, easy: move the evaluation of n into `eftInt`. So we have {{{ instance Enum Int where ... enumFromTo x y = eftInt x y }}} Now `eftInt` takes boxed `Ints` but it can evaluate them just fine. I've pushed a patch to `wip/cheap-build`, and it works just fine. '''However''': * It needs a serious note (steal the text above) * Other uses of `cheapBuild` need similar treatment. So the commit needs work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 14:30:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 14:30:22 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows In-Reply-To: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> References: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> Message-ID: <061.5f15316ea770a61fa4483b62c9bc2d1b@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * status: new => merge Comment: Merged to `ghc-8.2` in fb90e692daf782bade1c8a040b1c32c5aba4f05d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 14:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 14:30:27 -0000 Subject: [GHC] #13514: Unexpected failure of `annrun01` on 32-bit Windows In-Reply-To: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> References: <046.4747900692bbef2efbc98bbc6cf77bb9@haskell.org> Message-ID: <061.4b297f182008f37d7a1a87326cf06ddf@haskell.org> #13514: Unexpected failure of `annrun01` on 32-bit Windows ---------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 14:39:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 14:39:23 -0000 Subject: [GHC] #13509: Perplexing type error with unboxed tuples In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.a4044a4d4849816e98b5e91d71a87987@haskell.org> #13509: Perplexing type error with unboxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interestingly, comment:4 fails with GHC 7.10 and 8.0 as well. But comment:1 succeeds (I don't know why yet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 14:41:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 14:41:40 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.bed4cae81056b6634692b28ae4db5c51@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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:D3416 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ehubinette): * status: new => patch * differential: => Phab:D3416 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 15:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 15:38:29 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives Message-ID: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 came up during the GHC call while discussing #13397 and I thought it would be good to record. Often in the compiler we end up with a case analysis with a number of alternatives and a `DEFAULT` case in place of the remaining alternative, {{{!#hs case x of True -> a DEFAULT -> b }}} Arguably we should instead generate, {{{ case x of True -> a False -> b }}} instead as this may allow the code generator may be able to emit better code when it knows the finite bounds of the switch (e.g. using a jump table). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 15:38:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 15:38:59 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives In-Reply-To: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> References: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> Message-ID: <061.23995f0e644bfd397a90967a5e8c599d@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 bgamari: Old description: > This came up during the GHC call while discussing #13397 and I thought it > would be good to record. > > Often in the compiler we end up with a case analysis with a number of > alternatives and a `DEFAULT` case in place of the remaining alternative, > {{{!#hs > case x of > True -> a > DEFAULT -> b > }}} > Arguably we should instead generate, > {{{ > case x of > True -> a > False -> b > }}} > instead as this may allow the code generator may be able to emit better > code when it knows the finite bounds of the switch (e.g. using a jump > table). New description: This came up during the GHC call while discussing #13397 and I thought it would be good to record. Often in the compiler we end up with a case analysis with a number of alternatives and a `DEFAULT` case in place of the remaining alternative, {{{#!hs case x of True -> a DEFAULT -> b }}} Arguably we should instead generate, {{{#!hs case x of True -> a False -> b }}} instead as this may allow the code generator may be able to emit better code when it knows the finite bounds of the switch (e.g. using a jump table). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 15:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 15:40:15 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives In-Reply-To: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> References: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> Message-ID: <061.1cf48ab101cd15f417e2f4e40d517eaa@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 bgamari: Old description: > This came up during the GHC call while discussing #13397 and I thought it > would be good to record. > > Often in the compiler we end up with a case analysis with a number of > alternatives and a `DEFAULT` case in place of the remaining alternative, > > {{{#!hs > case x of > True -> a > DEFAULT -> b > }}} > > Arguably we should instead generate, > > {{{#!hs > case x of > True -> a > False -> b > }}} > instead as this may allow the code generator may be able to emit better > code when it knows the finite bounds of the switch (e.g. using a jump > table). New description: This came up during the GHC call while discussing #13397 and I thought it would be good to record. Often in the compiler we end up with a case analysis with a number of alternatives and a `DEFAULT` case in place of the remaining alternative, {{{#!hs data T = Con1 | Con2 | Con3 ... case x of Con1 -> a Con2 -> b DEFAULT -> c }}} Arguably we should instead generate, {{{#!hs case x of Con1 -> a Con2 -> b Con3 -> c }}} instead as this may allow the code generator may be able to emit better code when it knows the finite bounds of the switch (e.g. using a jump table). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 16:12:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 16:12:09 -0000 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> References: <051.38b1ebfeec872e08862a450e1303ba1d@haskell.org> Message-ID: <066.0067aeacad73c8773afc0f325d317810@haskell.org> #2507: quotation characters in error messages -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: 7.8.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2811,#3398 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): pacak, if there is an issue can you open a ticket? I'm afraid I don't know what you mean and this ticket is already closed. Do feel free to leave a reference to your new ticket here, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 16:28:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 16:28:07 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives In-Reply-To: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> References: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> Message-ID: <061.8e120dd488baa62564f171cf27a82c76@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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): If there is only one remaining constructor, GHC already replaces DEFAULT by that constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 17:37:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 17:37:03 -0000 Subject: [GHC] #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 In-Reply-To: <048.15995c38bd0c9449abab339f2616c179@haskell.org> References: <048.15995c38bd0c9449abab339f2616c179@haskell.org> Message-ID: <063.ac62f0f82704422f4b430ff9c25ab002@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => upstream Comment: It seems like this is likely an issue that will need to be fixed upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 17:38:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 17:38:53 -0000 Subject: [GHC] #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 In-Reply-To: <048.15995c38bd0c9449abab339f2616c179@haskell.org> References: <048.15995c38bd0c9449abab339f2616c179@haskell.org> Message-ID: <063.87d971522f46599a14c0b8f60abbdb13@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: upstream => closed * resolution: => fixed Comment: Way ahead of you :) The `timeOfDay` issue (or to be more precise, the `timeOfDay64` issue) was [https://github.com/bos/aeson/pull/536 fixed upstream] in `aeson` HEAD. As a result, I'll go ahead and close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 17:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 17:45:06 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications Message-ID: <047.235119fd783f4106c422b2bed378dde5@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- The following code compiles with 8.0.2. Note that the order of variables on `pt1` is `a :: *` and `expr :: * -> *`, and this is the order of the type application in `main`. {{{ {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -fno-warn-partial-type-signatures #-} type Empty a = () foo :: expr a -> expr a -> expr (Empty a) foo = undefined newtype Expr a = SPT {run :: String} pt1 :: forall a ptexpr . ptexpr a -> ptexpr (Empty a) --pt1 :: forall a ptexpr . ptexpr a -> ptexpr _ pt1 a = foo a a main :: IO () main = putStrLn $ run $ pt1 @Int @Expr undefined }}} If I use partial type signatures with the alternate signature for `pt1` (which has the same order of the `forall`), I get these errors: {{{ Bug.hs:19:25: error: • Couldn't match type ‘Int’ with ‘Expr’ Expected type: Expr (Empty Expr) Actual type: Int (Empty Expr) • In the second argument of ‘($)’, namely ‘pt1 @Int @Expr undefined’ In the second argument of ‘($)’, namely ‘run $ pt1 @Int @Expr undefined’ In the expression: putStrLn $ run $ pt1 @Int @Expr undefined Bug.hs:19:30: error: • Expected kind ‘* -> *’, but ‘Int’ has kind ‘*’ • In the type ‘Int’ In the second argument of ‘($)’, namely ‘pt1 @Int @Expr undefined’ In the second argument of ‘($)’, namely ‘run $ pt1 @Int @Expr undefined’ Bug.hs:19:35: error: • Expecting one more argument to ‘Expr’ Expected a type, but ‘Expr’ has kind ‘* -> *’ • In the type ‘Expr’ In the second argument of ‘($)’, namely ‘pt1 @Int @Expr undefined’ In the second argument of ‘($)’, namely ‘run $ pt1 @Int @Expr undefined’ }}} The errors are saying that the kinds of the type applications are incorrect, but nothing in the order of `pt1`s `forall` nor the order of application has changed. However, if I then change the order of the type applications in `main` to `main = putStrLn $ run $ pt1 @Expr @Int undefined`, GHC accepts the program, even though the kinds of types in the application are incorrect with respect to the order listed in `pt1` (so it should reject the program). Somehow GHC has swapped the order of `a` and `ptexpr` in the variable list for `pt1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 18:16:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 18:16:03 -0000 Subject: [GHC] #8373: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 tries to run target compiled inplace/lib/bin/mkGmpDerivedConstants on host/build In-Reply-To: <048.7d05199162bcbff566de88eaaa54b074@haskell.org> References: <048.7d05199162bcbff566de88eaaa54b074@haskell.org> Message-ID: <063.5a62c5ad24c88bef0bb9bf7e28fbaec0@haskell.org> #8373: Cross-compiling from x86_64-unknown-linux-gnu to x86_64-sun-solaris2 tries to run target compiled inplace/lib/bin/mkGmpDerivedConstants on host/build -------------------------------------+------------------------------------- Reporter: AlainODea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by travismoore): Additional info about Solaris: [[https://www.everipedia.com/Solaris_(operating_system)/|wiki]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 18:45:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 18:45:34 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.812d4e7fee5fdc5811343ff5436b8431@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:8 erikd]: > Using `FLOAT_STACK_WDS` set to `2` to get stack alignment correct didn't. I don't understand this comment: the Haskell stack is only word-aligned and the argument to `reserve` is in words, so it cannot unalign the stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 18:52:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 18:52:51 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.ddad54f43db5993d770ae3f1bcea734c@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Cmm lint could still do a better job with the original program, as slyfox pointed out. * I believe `I32 w` in the formal argument list is meaningless, or misleading. I don't think `I32` is a possible type for a function argument. (Here it is wrong anyways since on the Haskell side you presumably intend to give the function the type `Word# -> Float#`.) * `I32[ptr] = f;` should be an error because `f` is a `F32` not `I32`. * Returning `I32` seems dubious for the same reason that accepting `I32` as an argument does. I think Cmm lint ought to catch all of these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 18:57:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 18:57:47 -0000 Subject: [GHC] #13519: hWaitForInput does not work on linux. In-Reply-To: <054.27aaf9dcd2702cf6994ac888c1e691f2@haskell.org> References: <054.27aaf9dcd2702cf6994ac888c1e691f2@haskell.org> Message-ID: <069.798fbbe2eaeb75ea6ef8ce3f01606523@haskell.org> #13519: hWaitForInput does not work on linux. -------------------------------------+------------------------------------- Reporter: junji.hashimoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by junji.hashimoto): This is the same as a comment of https://ghc.haskell.org/trac/ghc/ticket/8684. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:00:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:00:03 -0000 Subject: [GHC] #13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn In-Reply-To: <051.ca911afc496192412d6a1ba78621943c@haskell.org> References: <051.ca911afc496192412d6a1ba78621943c@haskell.org> Message-ID: <066.449a0daa138d8ee45dcf6f1a7baf35c9@haskell.org> #13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ugh, this is rather unfortunate. I wonder what other language implementations do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:09:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:09:17 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences In-Reply-To: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> References: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> Message-ID: <066.87d13650a8974960a7cfd9d1b2e33429@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ekmett (added) Comment: They seem to differ subtly in their bottoming behavior, but it's far from clear whether this was intentional. Edward, you wrote this code originally, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:18:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:18:02 -0000 Subject: [GHC] #13470: Pattern synonyms bind variables out of scope In-Reply-To: <051.2f4dd426cb769effcd9b2e38f2ab45c1@haskell.org> References: <051.2f4dd426cb769effcd9b2e38f2ab45c1@haskell.org> Message-ID: <066.f407e5b2bc9c4be03735b4004a3392a3@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | patsyn/should_fail/T13470 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3377 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * testcase: => patsyn/should_fail/T13470 * resolution: => fixed Comment: This is fixed by comment:7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:26:05 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort Message-ID: <046.94d45988b3f89221effa39c9029b4490@haskell.org> #13525: hWaitForInput with timeout causes program to abort --------------------------------------+---------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 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: --------------------------------------+---------------------------------- This program, {{{#!hs import System.IO import System.Timeout main = hWaitForInput stdin (5 * 1000) }}} causes the program to abort (tested on Linux), {{{ $ ghc hi.hs [1 of 1] Compiling Main ( hi.hs, hi.o ) Linking hi ... $ ./hi fdReady: msecs != 0, this shouldn't happenAborted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:27:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:27:30 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.1f6af70abfd59eab1cec0211841590fc@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * related: => #12912, #8684 Comment: This was originally reported as a result of #12912. #8684 is also relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:29:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:29:56 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences In-Reply-To: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> References: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> Message-ID: <066.3565b5cb3cdbfc18520171deca0c7464@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): We can drop one of them. The `Data.List.NonEmpty` API was originally made by consolidating 2-3 different APIs from different authors to get a common API we could agree on. I apparently missed de-duplicating this corner of it. It probably should be `unfoldr` in name. I have no preference between the two implementations though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:32:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:32:13 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences In-Reply-To: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> References: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> Message-ID: <066.03d76502f5ca0f3c5fd9fe1066818c0c@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.2.1 Comment: Alright, I suppose at this point we should probably go through the usual three-release deprecation cycle. We can at very least try to add the deprecation pragma in 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 19:34:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 19:34:46 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.98946780c17991d3f0da38d629d04423@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeApplications Comment: Even spookier, this actually //works// on GHC 8.0.1—it's only in GHC 8.0.2 (and HEAD) that I can reproduce the incorrect type variable order when using the partial type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:09:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:09:24 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.75b7c5c5a83414dcdf8b9617f92d3f69@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: niteria (added) Comment: This regression first popped up in c9bcaf3165586ac214fa694e61c55eb45eb131ab (Kill varSetElemsWellScoped in quantifyTyVars). You can also reproduce the same error in GHC 8.0.1 by compiling with `-dunique-increment=-1` (after uncommenting the partial type signature, of course). cc'ing niteria, in case he has an idea of what might be happening here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:15:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:15:37 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences In-Reply-To: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> References: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> Message-ID: <066.1e2355a510b25a1e42dd76f58f874067@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): We can deprecate it in one release and remove it in the next and comply with the three release policy just fine. The other combinator already exists, and you can write code that is backwards compatible for 3 releases just by using whichever one we don't deprecate. Heck, the three release policy would be satisfied with just outright removing one with no deprecation period at all, so its more just a courtesy than anything to deprecate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:21:17 -0000 Subject: [GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE Message-ID: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE FlexibleContexts, FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses, UndecidableInstances #-} module Test where import Foreign.Ptr class DescendentOf a b where upCast :: Ptr b -> Ptr a upCast = castPtr class ChildOf b c | c -> b instance {-# OVERLAPPING #-} DescendentOf a a where upCast = id instance (DescendentOf a b, ChildOf b c) => DescendentOf a c data Value operateOnValue :: Ptr Value -> IO () operateOnValue _ = pure () typeOf :: DescendentOf Value v => Ptr v -> IO () typeOf = operateOnValue . upCast }}} The above code results in the following warning with GHC 8.2rc1 {{{ Test.hs:21:11: warning: [-Wsimplifiable-class-constraints] The constraint ‘DescendentOf Value v’ matches an instance declaration instance (DescendentOf a b, ChildOf b c) => DescendentOf a c -- Defined at Test.hs:14:10 This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance | 21 | typeOf :: DescendentOf Value v => Ptr v -> IO () }}} However, if I add `OVERLAPPABLE` to the second instance, the warning disappears because such instances are explicitly excluded in the check for this warning. I think it would make sense to silence this warning also if there is any `OVERLAPPING` instance that matches. The current warning is confusing since in this case the constraint actually can’t be simplified without changing the meaning of the code (the first instance would no longer match). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:38:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:38:58 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.ebf35f56dd8a1d5a4824287989a711dd@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): > I don't understand this comment: the Haskell stack is only word-aligned and the argument to reserve is in words, so it cannot unalign the stack. On 32 but systems, `Double` is two words and on 64 bit systems, `Float` is half a word. I did have some CPP which tried to account for this and that is what was breaking when I first tries @slyfox's `TO_W_` technique. > I believe I32 w in the formal argument list is meaningless So how does one express a `Word32` in a portable way in CMM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:38:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:38:58 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.d62acef2fa1de1c773f4c772d368f956@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: Phab:D3399, Phab:D3400 => Phab:D3399, Phab:D3400, Phab:D3421 Comment: Yes, I'm not sure what happened here but one of the parts of the patch seems to have been lost in a rebase. Thanks for catching this Simon! > Moreover, presumably the commit you did make (in `rebuildCase`) presumably does help something substantially, or you would not have done it (esp given its equivocal effect on other perf tests). But neither the commit message, nor (more importantly) the comment in the code, says what! `DynFlags` perhaps? Please say, so that someone wondering if they can now take it out knows what they have to test against. Yes, good point. Together with the missing part of the patch, it reduces the space usage while compiling `DynFlags` by at least a factor of 2. Unfortunately I was unable to construct a simpler test case that shows a similarly dramatic improvement, or diagnose exactly what is so special about `DynFlags`... maybe I'll try again to come up with a perf test case, even if the effect is not as dramatic as for `DynFlags`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:51:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:51:09 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.880483081402caea0c36caf5819ccd4d@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by rwbarton): Regarding comment:19: this is only needed for the subsequent change to make `coreBindsSize` less strict without introducing new space leaks. It's not needed to get the space usage under control in the first place, for which Phab:D3421 should be sufficient. That said I think it is still worth pursuing that line, I'm just not sure about the timing for 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:55:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:55:25 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.252533a7c18c8f55537b726c8dda7ff4@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by rwbarton): Now I see that Phab:D3421 is also about forcing types that go into a `SimplCont`, so is the situation similar to that of comment:19 where it would be better to force the types when we take them out of the `SimplCont` and put them into the actual program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 20:58:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 20:58:22 -0000 Subject: [GHC] #13521: Remove comments about API annotations In-Reply-To: <049.3bd3ebae9a4504c7b325699da41e840f@haskell.org> References: <049.3bd3ebae9a4504c7b325699da41e840f@haskell.org> Message-ID: <064.76f3831084a8def0a6c34fe2335c1997@haskell.org> #13521: Remove comments about API annotations -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I agree and had been meaning to suggest doing this myself. Particularly the comments on `HsExpr` occupy a lot of prime real estate for something which most people working with `HsExpr` won't need to know about (I still don't really understand what any of this `ApiAnnotation` is about). It would be better to move this information somewhere else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 21:19:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 21:19:05 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.950e51e89608a3da1c1362d4cb42d25a@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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 niteria): Hmm, I would have expected 7e96526ac2ef5987ecb03217d3d616b6281c1441 to fix it and #13371 to be related. But you tested with HEAD, so that's a bit odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 21:20:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 21:20:17 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.b35fb96d9f6862fb656b684e4ea81b97@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by simonpj): > would be better to force the types when we take them out of the SimplCont and put them into the actual program? Yes for the type in the `Stop` continuation; but I think no for the types in `ApplyToTy` continuation, which will certainly be used. I'd force the latter on the way in; but the former only on the way out in `contResultType`. Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 21:59:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 21:59:06 -0000 Subject: [GHC] #13504: registerTimeout can wait too little because it uses Doubles for times In-Reply-To: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> References: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> Message-ID: <057.a53dfde174a5d31739e9fdf8e5b85745@haskell.org> #13504: registerTimeout can wait too little because it uses Doubles for times -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.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): * owner: nh2 => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 21:59:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 21:59:29 -0000 Subject: [GHC] #13504: registerTimeout can wait too little because it uses Doubles for times In-Reply-To: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> References: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> Message-ID: <057.8313f4fd48e18e7d81ee7f46a5a1dbe0@haskell.org> #13504: registerTimeout can wait too little because it uses Doubles for times -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.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): Phab:D3417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3417 * milestone: => 8.4.1 Comment: Here is a quick (but rather under-tested) fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:07:05 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.9da753b221d0aced7e9e837133c30ebb@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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): Hmm. When the user gives a partial type signature, a whole new code path is used when checking the function. It seems this code path does not respect the order of specified type variables. @niteria's patch likely just exposed the underlying fragility; I don't think investigating that patch will yield any tasty fruit. I'm afraid I'm unable to address this right now, unfortunately. We could advertise this as an infelicity (I'm fairly confident the problem will happen only with a partial type signature). Perhaps even better, we could label variables in partial type signatures as "inferred", meaning that GHC will prevent them from being available for type application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:08:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:08:19 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings Message-ID: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) 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: -------------------------------------+------------------------------------- Found on a crash when ghc tried to print a warning in a huge assembly file. I've simplified it to autogenerated C file with an error: {{{ # generate 10 million lines file # and put an error into the very end of file $ { for i in `seq 1 $((10 * 1000 * 1000))`; do echo "// a comment number $i"; done; echo 'static int foo = ;'; } > a.c }}} {{{ $ LANG=C powerpc64le-unknown-linux-gnu-ghc -c a.c +RTS -K128M stack overflow: use +RTS -K to increase it }}} C compiler tried to output something like the following to stderr: {{{ a.c:10000001:0: error: error: expected expression before ';' token static int foo = ; }}} GHC finds 'a.c:10000001' location and tries to pretty-print the line. We get a space leak somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:21:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:21:33 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.90cf9a37853775496a1f9bbaa7dcdb32@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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): > Perhaps even better, we could label variables in partial type signatures as "inferred", meaning that GHC will prevent them from being available for type application. Yes! After all, if you write {{{ f :: forall a. _ -> a -> a f = ... }}} you might end up with more type variables; e.g. f's signature might really be {{{ f :: forall a b c. (b,c) -> a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:31:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:31:13 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.1d2af1cd9dee5fde4fbbb68edca8d1df@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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 crockeea): I'm confused here: are you suggesting that you would be able to apply `f` to `a`, but not to `b` or `c`, or are you saying you would disallow type applications completely on functions that have partial type signatures? In the former case, new variables aren't causing my issue; GHC is reordering explicitly listed variables. In the latter case, this really weakens these two features! I'd rather guess the right order through trial and (compile) error than be disallowed completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:31:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:31:34 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.4bde46d3a4bf389c2b85ca9c84fd3f70@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think there's a bit of confusion here. The issue is not that wildcards are being treated as visible type variables, as evidenced in this GHCi session: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170329: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-foralls -XPartialTypeSignatures λ> let foo :: _ -> b; foo _ = undefined :2:12: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘w’ Where: ‘w’ is a rigid type variable bound by the inferred type of foo :: w -> b at :2:20-36 • In the type signature: foo :: _ -> b λ> :type +v foo foo :: forall {w} b. w -> b }}} The fresh type variable that gets used in place of `_` is implicitly quantified and unspecified, so it is not available for visible type application in the first place: {{{ λ> :set -XTypeApplications λ> :type +v foo @Int foo @Int :: forall {w}. w -> Int λ> :type +v foo @Int @Char :1:1: error: • Cannot apply expression of type ‘w0 -> Int’ to a visible type argument ‘Char’ • In the expression: foo @Int @Char }}} This part is working as expected. The issue is the order in which the //explicitly// quantified type variables are being returned in the presence of `PartialTypeSignatures`. If you take this code {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -fno-warn-partial-type-signatures #-} type Empty a = () foo :: expr a -> expr a -> expr (Empty a) foo = undefined newtype Expr a = SPT {run :: String} pt1 :: forall a ptexpr . ptexpr a -> ptexpr _ pt1 a = foo a a }}} and load it into GHCi, you can see for yourself the exact (incorrect) order in which `pt1`'s type variables are appearing: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170329: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, modules loaded: Main. λ> :set -fprint-explicit-foralls λ> :type +v pt1 pt1 :: forall (ptexpr :: * -> *) a. ptexpr a -> ptexpr (Empty a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:33:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:33:56 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.aac51fdf2cc224c1c12d3dd5248c71e7@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I heartily agree with crockeea that we should not disable VTA altogther for things with partial type signatures. I think that would be even more confusing than the current behavior, in fact! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 4 22:35:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Apr 2017 22:35:42 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.febaa3599b13ffe811a5972e650d144c@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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 crockeea): @RyanGlScott Thank you for helping to clear up the question; you nailed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 00:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 00:49:34 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.8aa6eb72283e50db2e8bfafcbc09cc51@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5b7f504f3c190375903b57a541338bc939ca2dae/ghc" 5b7f504/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b7f504f3c190375903b57a541338bc939ca2dae" testsuite: Add test for #13524 Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3418 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 00:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 00:49:34 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.0f2fe5c5ac5f8cfb3a95cfd8de73a14f@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"3d523fd990bbb31ca97ea22059ec9d53f0705d8c/ghc" 3d523fd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3d523fd990bbb31ca97ea22059ec9d53f0705d8c" base: Add test for #13525 Reviewers: austin, hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3419 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 00:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 00:49:34 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.5d4c7eb8a6b5b5fe90c29568d4b2984b@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: snoyberg Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | 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:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"37d7c1596ee936ec6597a5c1898e1fdca7c04f77/ghc" 37d7c15/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37d7c1596ee936ec6597a5c1898e1fdca7c04f77" base: Add test for #8684 Reviewers: austin, hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3420 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 00:53:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 00:53:10 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.07932316dba0412f90875b02b57cd8cc@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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): My comment:4 says: > Perhaps even better, we could label variables in partial type signatures as "inferred", meaning that GHC will prevent them from being available for type application. This was always meant to be a stopgap solution, in case the status quo is unacceptable for 8.2. I've already put this bug in my queue for my summer bug roundup. But I simply can't get to it in the next month. "Even better" is suggesting that reliable, explainable behavior is better than capricious behavior, but @crockeea's comment:6 disagrees with this suggestion. I certainly don't feel strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 00:56:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 00:56:49 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.40858399b27ef2129632557892dfcbda@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hi Duog, thanks for your work on this and sorry for the delayed response; I unfortunately missed the notification for this. It would be great if you could put this up on Phabricator. See [wiki:Phabricator] to get started and don't hesitate to reach out to me via email or IRC if you need help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 01:01:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 01:01:37 -0000 Subject: [GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling In-Reply-To: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> References: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> Message-ID: <061.d81e05693669144496903b2e669b5a63@haskell.org> #11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: GHC API | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Tools like [[https://github.com/DanielG/ghc-mod/|ghc-mod]] typically just > want `TypecheckedModule`s. Sadly, the GHC API currently doesn't provide a > good way to get at these in all cases (see this > [[https://github.com/DanielG/ghc-mod/issues/205|ghc-mod ticket]]). Each > of the options we offer are cursed with their own limitations (largely > quoting from the ghc-mod ticket), > > == HscNothing == > > At first glance this looks like what you would want. But... > > * Pros > * Doesn't generate code of any sort and is therefore rather > lightweight > * Cons > * It lacks support for Template Haskell > * Has trouble with `foreign export`s > * [https://github.com/DanielG/ghc-mod/pull/145 Fails] to issue pattern > match checker warnings > > == HscInterpreted == > > Okay, so `HscNothing` doesn't work. Maybe `HscInterpreted` is better? > > * Pros > * Supports Template Haskell > * Cons > * Can't deal with unboxed tuples (#1257) > * Slower as we need to produce unnecessary bytecode > * Large memory footprint > * Also can't deal with `foreign export`s > > == HscAsm == > > * Pros > * Supports all compilable code > * Cons > * Slow > * Produces `.o` files > > This is quite unfortunate. It seems like we need something in between > `HscNothing` and `HscInterpreted` which is willing to use the interpreter > to evaluate Template Haskell splices when necessary, but doesn't produce > bytecode. Unfortunately it's unclear what to do about `foreign export` > (but arguably most tools would be fine with some approximate > representation). New description: Tools like [[https://github.com/DanielG/ghc-mod/|ghc-mod]] typically just want `TypecheckedModule`s. Sadly, the GHC API currently doesn't provide a good way to get at these in all cases (see this [[https://github.com/DanielG/ghc-mod/issues/205|ghc-mod ticket]]). Each of the options we offer are cursed with their own limitations (largely quoting from the ghc-mod ticket), == HscNothing == At first glance this looks like what you would want. But... * Pros * Doesn't generate code of any sort and is therefore rather lightweight * Cons * It lacks support for Template Haskell * Has trouble with `foreign export`s * [https://github.com/DanielG/ghc-mod/pull/145 Fails] to issue pattern match checker warnings (#10600) == HscInterpreted == Okay, so `HscNothing` doesn't work. Maybe `HscInterpreted` is better? * Pros * Supports Template Haskell * Cons * Can't deal with unboxed tuples (#1257) * Slower as we need to produce unnecessary bytecode * Large memory footprint * Also can't deal with `foreign export`s == HscAsm == * Pros * Supports all compilable code * Cons * Slow * Produces `.o` files This is quite unfortunate. It seems like we need something in between `HscNothing` and `HscInterpreted` which is willing to use the interpreter to evaluate Template Haskell splices when necessary, but doesn't produce bytecode. Unfortunately it's unclear what to do about `foreign export` (but arguably most tools would be fine with some approximate representation). -- Comment (by bgamari): Duog has provided an interesting approach to making `-fno-code` usable in the presence of Template Haskell. See ticket:8025#comment:7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 01:02:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 01:02:04 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.d40f8f9458218ce6e8aabb8ffe7d465b@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: duog (added) * owner: (none) => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 01:10:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 01:10:48 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.87b13eceb8829c15b794dedd81965e90@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Duog, your approach seems like a very interesting compromise that I had not considered. Great work! There is the question of which `HscTarget` we want to use here. Arguably `HscInterpreted` is more appropriate as it is faster to generate, faster to link, and doesn't unexpected leave object files lying around. However, it unfortunately lacks support for unboxed tuples and sums, which may break some (I suspect quite small) fraction of programs. It would be interesting to characterize the difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 01:17:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 01:17:22 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible (was: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved) In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.841b7fb463022aa01f45c9ac1bd285d3@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Old description: > Building the included project with > {{{ > cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno- > code" > }}} > results in the following typechecker error: > {{{ > ByteCodeLink.lookupCE > During interactive linking, GHCi couldn't find the following symbol: > supabugzm0zi1zi0_A_makeLenseszq_closure > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, > specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi. > If you suspect the latter, please send a bug report to: > glasgow-haskell-bugs at haskell.org > }}} New description: Building the included project with {{{ cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno- code" }}} results in the following typechecker error: {{{ ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: supabugzm0zi1zi0_A_makeLenseszq_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} The problem here is that GHC goes looking for the code of modules needed for TemplateHaskell splices, which was not produced due to `-fno-code`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 01:20:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 01:20:45 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences In-Reply-To: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> References: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> Message-ID: <066.2d3dade385ad8aa24d9c6fd08e6f313c@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: high | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3422 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 02:23:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 02:23:01 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.4322e7b4135f4e3ae3407836990c00ca@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Rev(s): Phab:D3404 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"af941a96f62101a6539f3cc35d82df3fd964539c/ghc" af941a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af941a96f62101a6539f3cc35d82df3fd964539c" Add regression test for #7944 Commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba happened to fix the bug reported in #7944. Let's add a regression test so that it stays that way. Fixes #7944. Test Plan: make test TEST=T7944 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3404 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 02:23:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 02:23:02 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.cef5245fbb2b39d2963ea716a8bacd28@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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:D3416 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"486b8db05fefd1cfa916928c74958f8099b9f9f8/ghc" 486b8db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="486b8db05fefd1cfa916928c74958f8099b9f9f8" Add Alternative instance for ZipList (fix #13520). Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: adamse, RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3416 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 02:24:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 02:24:09 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.bccc596523c5b71c090acfdb70aabba2@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Rev(s): Phab:D3404 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 Wed Apr 5 02:25:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 02:25:49 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences In-Reply-To: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> References: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> Message-ID: <066.cc7aa02e5fcb1e08e4c05f25505ebecc@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged as ce9b6170b0ac9ff417000d8e7bdff7b2298f2978. Merged to `ghc-8.2` as 881793ec8730a1c98da424bdac0d03dfe77e5c1f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 02:26:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 02:26:49 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.367a1cb32b9f9c3482e2d9068923b991@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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): Phab:D3416 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 02:44:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 02:44:24 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.cc8478ad08f47e34b2e2984b48ccf65f@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by rwbarton): After writing comment:28 I got the validate results from Phab:D3421 which show a ~75% increase in allocations when compiling [https://raw.githubusercontent.com/ghc/ghc/master/testsuite/tests/perf/compiler/T5631.hs T5631] which involves many very large types; the only change in that commit being to the `App fun arg` case of `simplExprF1`. I see that the `sc_arg_ty` is (almost) always used because it occurs as the type a function is applied to in the output program. But `sc_hole_ty` is only ever used via `contHoleType` and put in a `mkBoringStop`. There is even a Note `[The hole type in ApplyToTy]` which suggests that evaluating `sc_hole_ty` eagerly would be bad. I tried going back to using `substTy` for the `sc_hole_ty` field, while using `simplType` for the `sc_arg_ty` field. This still avoids the space leak when compiling `DynFlags` and also avoids the regression in T5631. So it seems to be the right thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 07:33:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 07:33:18 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.00a170cd3212a04d94aa0dda87795b44@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by simonpj): > But sc_hole_ty is only ever used via contHoleType and put in a mkBoringStop Ah, very good! Yes yes. Let's make sure we document all this carefully when we are done :-). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 08:59:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 08:59:35 -0000 Subject: [GHC] #13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn In-Reply-To: <051.ca911afc496192412d6a1ba78621943c@haskell.org> References: <051.ca911afc496192412d6a1ba78621943c@haskell.org> Message-ID: <066.c5a9e3f86bb0d4f45700e715700bc490@haskell.org> #13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewufrank): i do not see a systematically correct solution (given that BOM is not a systematically correct feature ..). therefore warnings in the different haddock comments for putStrLn - invisible characters (e.g. BOM) may not be shown (use "putStrLn . show" to make them visible) parsec (and others): consider invisible characters (e.g. a BOM mark at the start of the file) and use optional (char '\65279') -- to remove BOM if present the problem is not BOM in particular, but the existence of completely invisible characters in UTF8. alternatively, consider a readFile alternate which does not read BOM at the beginning. none of these solutions are really attractive! andrew -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 10:38:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 10:38:11 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.4699b063f5cf0e4974e467da2a8632ef@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Here's yet another proposal, I think we should compile string literals into `byteArray` using UTF8 encoding. I don't know if this is feasible, but this will make a universal `byteArray` based bytes library possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 11:21:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 11:21:23 -0000 Subject: [GHC] #13528: Unqualified export of constructors Message-ID: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> #13528: Unqualified export of constructors -------------------------------------+------------------------------------- Reporter: dmendler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Unqualified exports of constructors doesn't work anymore in 8.2.1-rc1. It worked before in 8.0. Is this intended or a regression? {{{ module Test ( GHC.Exts.IsList( Item , fromList , toList ) , Data.Bool.Bool(True, False) ) where import qualified GHC.Exts import qualified Data.Bool }}} The error: {{{ • Not in scope: data constructor ‘False’ Perhaps you meant ‘Prelude.False’ (imported from Prelude) • In the export: Data.Bool.Bool(False, True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 11:22:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 11:22:08 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore (was: Unqualified export of constructors) In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.1437bbab884f0cf58a6113d87ee02765@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 12:15:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 12:15:26 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls Message-ID: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently eventlog file doesn't contain more information about FFI than: "stopping thread ### (making a foreign call)" It would be very-very useful if we know what actual foreign calls are made. For example: "stopping thread ### (making a foreign call to function YYYY) So we could see which function and how much time is spent on that call. If creation of threads because of in-bound foreign calls (callbacks) have which callbacks are created for it will be very useful, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 12:16:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 12:16:32 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls In-Reply-To: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> References: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> Message-ID: <060.db68d3867e17f248e4b9411d7381060b@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by varosi): * Attachment "Core88_threadprofile.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 12:48:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 12:48:24 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType Message-ID: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 this {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Foo where import GHC.Exts g :: Int -> (# Int#, a #) g (I# y) = (# y, undefined #) f :: Int -> (# Int#, Int# #) f x = g x }}} With GHC 8 we get {{{ Foo.hs:11:7: error: • Couldn't match a lifted type with an unlifted type Expected type: (# Int#, Int# #) Actual type: (# Int#, Int# #) }}} What a terrible error message!! It was much better in GHC 7.10: {{{ Foo.hs:11:7: Couldn't match kind ‘*’ with ‘#’ When matching types a0 :: * Int# :: # Expected type: (# Int#, Int# #) Actual type: (# Int#, a0 #) }}} What's going on? The constraint solver sees {{{ [W] alpha::TYPE LiftedRep ~ Int#::TYPE IntRep }}} So it homogenises the kinds, ''and unifies alpha'' (this did not happen in GHC 7.10), thus {{{ alpha := Int# |> TYPE co [W] co :: LiftedRep ~ IntRep }}} Of course the new constraint fails. But since we have unified alpha, when we print out the types are are unifying they both look like `(# Int#, Int# #)` (there's a suppressed cast in the second component). I'm not sure what to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 12:51:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 12:51:51 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.661115a58f82fc06bdfddcecaffe8ac4@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 Wed Apr 5 12:53:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 12:53:00 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.13f2dba859570b0e350cbd85ce3de1e1@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: mpickering (added) Comment: Matthew, might you be able to look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 13:27:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 13:27:40 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file Message-ID: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13137, #9868, | #10355 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For ghc 8.0.2 (on Linux, in nixpkgs `0c041520c3` for exact reproducibility), when TH is used in a `ghc --make -j1` invocation, and thus ghc does the whole {{{ cc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-std=c++14' -Wno- deprecated-declarations --print-file-name liblibglog.so Loading object (dynamic) glog ... done }}} business, and the `.so` file in question does not exist, then usually GHC prints {{{ : user specified .o/.so/.DLL could not be loaded (libglog.so: cannot open shared object file: No such file or directory) }}} However, I found that when parallel compilation is enabled, (e.g. `ghc -j4`), I can get this instead: {{{ [ 23 of 130] Compiling Mymodule ( Mymodule.hs, dist/build/Mymodule.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): Dynamic linker not initialised 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 Apr 5 13:28:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 13:28:05 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.04df943a1714250cf9b110e5da7e1191@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Does your build use `ghc -j`? If yes, see #13531 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 13:30:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 13:30:32 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file In-Reply-To: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> References: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> Message-ID: <057.eaca848fc4c25f077e35e2ca02773450@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13137, #9868, | Differential Rev(s): #10355 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): {{{ (13:52:43) Phyx-: it seems like a race condition, something is calling a linker function which requires the persistent state without first calling initDynLinker (13:52:52) Phyx-: would make sense if it goes away with -j1 (13:53:26) nh2: Phyx-: that sounds plausible to me; would a `ghc -v` dump help here (does it show when it initialises the linker)? (13:54:46) Phyx-: no, that part is mostly completely silent. you might get lucky with a debug build and +RTS -Dl (13:56:57) Phyx-: all the top level exposed functions in Linker.hs call initDynLinker though. (13:58:11) Phyx-: except for extendLoadedPkgs, extendLinkEnv and deleteFromLinkEnv (13:59:17) Phyx-: If you can reproduce it consistently, easiest would be just to add some print statements and see what calls what (14:00:55) Phyx-: nh2: or, better yet, try a profiling build and see if you get a stack trace from the panic (15:16:05) nh2: Phyx-: the race condition seems to happen only when the linking actually _fails_, e.g. when you would get "no such file or directory" when GHC -j1 tries to load something (15:19:40) Phyx-: nh2: then my completely wild speculation is that the function that failed was supposed to initialise the linker but didn't because of the error. (15:20:17) Phyx-: I think one of the tickets RyanGlScott said it also happens for Windows. I'll see if I can repo }}} Note I can reproduce this 100% in nixpkgs but haven't extracted it into a publicly available reproduction yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 14:45:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 14:45:09 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls In-Reply-To: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> References: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> Message-ID: <060.c4eda53b57448a9104e76bb5ca7f5b49@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): How do you propose we would identify which foreign function is being called? I can think of a few ways, * Have the compiler produce a string which is passed to the RTS when generating code for safe foreign calls * Use the symbol table lookup of the callee's address * Use DWARF information of the callee's address All of these have their costs and I do wonder whether this sort of instrumentation might not be better left to the user to implement themselves with, e.g. `traceEvent`, if they need it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 15:40:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 15:40:13 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.28c78d7643cae55cb4c19aa2f8c5ae2b@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Regarding comment:56, I don't think we would want to give every string literal the overhead of a full heap object. Even just adding a length as is proposed in this ticket is adding a significant binary size overhead for small strings, which occur quite often. The additional few words that a `ByteArray` closure would bring is far too expensive to stomach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 16:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 16:22:00 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls In-Reply-To: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> References: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> Message-ID: <060.b1fec80daa7f1fc2f5f5817691988a9c@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I'm not aware of GHC architecture and cannot help with actual implementation much. If there are many foreign calls or we're using third-party libraries, like wxHaskell - it will be hard to place traceEvent everywhere. Automated adding of such traceEvent could be very helpful, i.e. automated instrumentation. About DWARF - there is no DWARF support under Windows, so this limit debugging capabilities. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 16:22:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 16:22:47 -0000 Subject: [GHC] #13529: eventlog to report more information about stopping threads because of FFI calls In-Reply-To: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> References: <045.0d924e6da940a794deee9a3dd208e86d@haskell.org> Message-ID: <060.a7649c74deb74f6d51362a70f28b0261@haskell.org> #13529: eventlog to report more information about stopping threads because of FFI calls ------------------------------------+-------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by varosi): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 16:47:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 16:47:25 -0000 Subject: [GHC] #13532: Work out better way of interacting with boot library upstreams Message-ID: <046.043934c0a6e18f2db4ac00a6d6495b33@haskell.org> #13532: Work out better way of interacting with boot library upstreams -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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: -------------------------------------+------------------------------------- Currently our protocol for tracking boot library upstreams is a bit painful. Namely, I periodically try updating the library submodules, typically all at once, and see what breaks. We then have to go about pushing various patches fixing the breakage. After a week or three when all of these patches are upstream we can try bumping the submodules again. Ideally nothing else has broken and we can push the result. However, let's just say that Murphy's law has an unfortunately truth to it. I wonder whether moving in the direction of what we currently do with `haddock` would be an improvement. Namely, we maintain a `ghc-head` branch of each of the libraries. We can then pull upstream in `master` and make fixes as necessary. These changes can then be asynchronously pushed upstream. In principle, we could even try pulling nightly to catch issues early. Of course, prior to a release we would ensure that `ghc-head` sat on a proper `master` commit. Anyways, I've been meaning to do something about this. Another task for post-8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 16:47:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 16:47:32 -0000 Subject: [GHC] #13532: Work out better way of interacting with boot library upstreams In-Reply-To: <046.043934c0a6e18f2db4ac00a6d6495b33@haskell.org> References: <046.043934c0a6e18f2db4ac00a6d6495b33@haskell.org> Message-ID: <061.0c39d3b7ed3a8b37e09e4e0e8caf7582@haskell.org> #13532: Work out better way of interacting with boot library upstreams -------------------------------------+------------------------------------- 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: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 17:03:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 17:03:32 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.e37e278521a21bf88709528c7026e89b@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 this is #11198. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 18:52:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 18:52:42 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.d660f455c36a43e0fb15b80cb9bb761f@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: | -------------------------------------+------------------------------------- Comment (by simonpj): See #13530 for a concrete and very simple test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 18:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 18:53:08 -0000 Subject: [GHC] #11544: SCC call-stack from `error` missing call-sites In-Reply-To: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> References: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> Message-ID: <064.c7ad26a5fb32f04de68ae7862f123613@haskell.org> #11544: SCC call-stack from `error` missing call-sites -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc1 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 varosi): How could we find such an error in large application where we doesn't know where this Prelude.tail usage come from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 20:13:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 20:13:30 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.b8253f00d512d4dff8939aab5f55dcf0@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 simonpj): Dead right. We should fix this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 21:02:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 21:02:08 -0000 Subject: [GHC] Batch modify: #6087, #6132, #7273, #8763, #9221, #10141, #10536, ... In-Reply-To: <573.ff3eafee80cf0c91892dd0a3889d138f@haskell.org> References: <573.ff3eafee80cf0c91892dd0a3889d138f@haskell.org> Message-ID: <588.91f4b4aa1f41f9be6da4438c66396c82@haskell.org> Batch modification to #6087, #6132, #7273, #8763, #9221, #10141, #10536, #10640, #10770, #10789, #10853, #10878, #11092, #11197, #11204, #11259, #11260, #11323, #11359, #11369, #11392, #11474, #11495, #11587, #11634, #11686, #11719, #11721, #11749, #11765, #11827, #11836, #11954, #11955, #12021, #12038, #12075, #12090, #12193, #12369, #12388, #12517, #12581, #12599, #12619, #12636, #12652, #12669, #12712, #12714, #12715, #12737, #12765, #12774, #12808, #12825, #12875, #12926, #12932, #12934, #12937, #12938, #12940, #12949, #12962, #12964, #12999, #13003, #13069, #13078, #13080, #13090, #13092, #13093, #13165, #13182, #13226, #13280, #13346, #13390, #13471, #2725, #7723, #9249, #9981, #10582, #10930, #11091, #11958, #13001, #13064 by bgamari: milestone to 8.4.1 Comment: Given that 8.2.1-rc1 is imminent, I'm bumping these off to the 8.4 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 21:12:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 21:12:00 -0000 Subject: [GHC] #13533: -ddump-warnings Message-ID: <051.bc216f5659ab02ecec2553725df8df71@haskell.org> #13533: -ddump-warnings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 useful to have a way to dump the warnings from a compilation to a file, and seemingly the most natural way to do that would be to extend with {{{-ddump-warnings}}}. The use case is that developers often want to develop and debug without worrying so much about warnings, but should almost always resolve the warnings before committing. If you build with {{{-Werror}}} that impedes development. If you don't build with {{{-Werror}}} then you may check in code that later fails continuous integration tests, or have to do a clean build to get the warnings out. An alternative workflow would be to always dump warnings to a file, then before commit have a script to quickly check if any of the files are non-empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 22:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 22:30:41 -0000 Subject: [GHC] #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base In-Reply-To: <045.e8d5052962549532effd4485f8aa5560@haskell.org> References: <045.e8d5052962549532effd4485f8aa5560@haskell.org> Message-ID: <060.369c4e1318bb25aaabe046796c6ed5b4@haskell.org> #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 Wed Apr 5 23:42:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 23:42:54 -0000 Subject: [GHC] #6063: GHC's build-time ld-flag checks are problematic In-Reply-To: <044.2e055ef1bb401ab8aa4d1f1ae9a51f02@haskell.org> References: <044.2e055ef1bb401ab8aa4d1f1ae9a51f02@haskell.org> Message-ID: <059.070efb1436c7f72c205d15efe0aa49cc@haskell.org> #6063: GHC's build-time ld-flag checks are problematic -------------------------------------+------------------------------------- Reporter: parcs | Owner: thoughtpolice Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: #4862 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): A summary of how to use gold for linking for those who are looking for instructions [http://stackoverflow.com/questions/43243322/how-to-link- with-the-gnu-gold-linker-instead-of-ld-in-haskell/ can be found here.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 5 23:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Apr 2017 23:43:05 -0000 Subject: [GHC] #4862: Enable usage of gold linker with GHC In-Reply-To: <042.3442092387d4ef4c250e40df3ea4af8a@haskell.org> References: <042.3442092387d4ef4c250e40df3ea4af8a@haskell.org> Message-ID: <057.d081f901cd94f6e7541b26a09846ed78@haskell.org> #4862: Enable usage of gold linker with GHC -------------------------------------+------------------------------------- Reporter: ajd | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.4.3 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): A summary of how to use gold for linking for those who are looking for instructions [http://stackoverflow.com/questions/43243322/how-to-link- with-the-gnu-gold-linker-instead-of-ld-in-haskell/ can be found here.] It is much faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:06:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:06:20 -0000 Subject: [GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build Message-ID: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------------+--------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: timeout | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- {{{ Looks like you don't have timeout, building it first... make -C ../timeout all make[2]: Entering directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe python3 calibrate '' > calibrate.out Traceback (most recent call last): File "calibrate", line 20, in compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') File "/usr/lib64/python3.6/os.py", line 920, in spawnl return spawnv(mode, file, args) File "/usr/lib64/python3.6/os.py", line 871, in spawnv return _spawnvef(mode, file, args, None, execv) File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef raise ValueError('argv first element cannot be empty') ValueError: argv first element cannot be empty make[2]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' make[2]: *** [Makefile:54: calibrate.out] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] Error 2 make: *** [Makefile:217: test] Error 2 }}} Full buildlog at https://copr- be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/00536407-ghc/build.log.gz (for a couple of weeks) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:06:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:06:52 -0000 Subject: [GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build In-Reply-To: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> References: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> Message-ID: <065.70feec763f0bf8bc352b4f7ccb733a4f@haskell.org> #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------+-------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: timeout Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+-------------------------------------- Description changed by juhpetersen: Old description: > {{{ > Looks like you don't have timeout, building it first... > make -C ../timeout all > make[2]: Entering directory > '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' > rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe > python3 calibrate '' > calibrate.out > Traceback (most recent call last): > File "calibrate", line 20, in > compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') > File "/usr/lib64/python3.6/os.py", line 920, in spawnl > return spawnv(mode, file, args) > File "/usr/lib64/python3.6/os.py", line 871, in spawnv > return _spawnvef(mode, file, args, None, execv) > File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef > raise ValueError('argv first element cannot be empty') > ValueError: argv first element cannot be empty > make[2]: Leaving directory > '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' > make[2]: *** [Makefile:54: calibrate.out] Error 1 > make[1]: Leaving directory > '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' > make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] > Error 2 > make: *** [Makefile:217: test] Error 2 > }}} > > Full buildlog at https://copr- > be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/00536407-ghc/build.log.gz > (for a couple of weeks) New description: {{{ : Looks like you don't have timeout, building it first... make -C ../timeout all make[2]: Entering directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe python3 calibrate '' > calibrate.out Traceback (most recent call last): File "calibrate", line 20, in compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') File "/usr/lib64/python3.6/os.py", line 920, in spawnl return spawnv(mode, file, args) File "/usr/lib64/python3.6/os.py", line 871, in spawnv return _spawnvef(mode, file, args, None, execv) File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef raise ValueError('argv first element cannot be empty') ValueError: argv first element cannot be empty make[2]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' make[2]: *** [Makefile:54: calibrate.out] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] Error 2 make: *** [Makefile:217: test] Error 2 }}} Full buildlog at https://copr- be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/00536407-ghc/build.log.gz (for a couple of weeks) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:10:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:10:09 -0000 Subject: [GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build In-Reply-To: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> References: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> Message-ID: <065.b650017229a146a6dad88f37bf4ef779@haskell.org> #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------+-------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: timeout Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+-------------------------------------- Description changed by juhpetersen: Old description: > {{{ > : > Looks like you don't have timeout, building it first... > make -C ../timeout all > make[2]: Entering directory > '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' > rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe > python3 calibrate '' > calibrate.out > Traceback (most recent call last): > File "calibrate", line 20, in > compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') > File "/usr/lib64/python3.6/os.py", line 920, in spawnl > return spawnv(mode, file, args) > File "/usr/lib64/python3.6/os.py", line 871, in spawnv > return _spawnvef(mode, file, args, None, execv) > File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef > raise ValueError('argv first element cannot be empty') > ValueError: argv first element cannot be empty > make[2]: Leaving directory > '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' > make[2]: *** [Makefile:54: calibrate.out] Error 1 > make[1]: Leaving directory > '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' > make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] > Error 2 > make: *** [Makefile:217: test] Error 2 > }}} > > Full buildlog at https://copr- > be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/00536407-ghc/build.log.gz > (for a couple of weeks) New description: {{{ + make test make -C testsuite/tests CLEANUP=1 SUMMARY_FILE=../../testsuite_summary.txt make[1]: Entering directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' "/builddir/build/BUILD/ghc-8.2.0.20170404/inplace/bin/ghc-stage2" --make -o ../mk/ghc-config ../mk/ghc-config.hs [1 of 1] Compiling Main ( ../mk/ghc-config.hs, ../mk/ghc- config.o ) Linking ../mk/ghc-config ... ../mk/ghc-config "/builddir/build/BUILD/ghc-8.2.0.20170404/inplace/bin /ghc-stage2" >"../mk/ghcconfig_builddir_build_BUILD_ghc-8.2.0 .20170404_inplace_bin_ghc-stage2.mk"; if [ $? != 0 ]; then rm -f "../mk/ghcconfig_builddir_build_BUILD_ghc-8.2.0.20170404_inplace_bin_ghc- stage2.mk"; exit 1; fi Looks like you don't have timeout, building it first... make -C ../timeout all make[2]: Entering directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe python3 calibrate '' > calibrate.out Traceback (most recent call last): File "calibrate", line 20, in compiler_name, 'TimeMe.hs', '-o', 'TimeMe', '-O2') File "/usr/lib64/python3.6/os.py", line 920, in spawnl return spawnv(mode, file, args) File "/usr/lib64/python3.6/os.py", line 871, in spawnv return _spawnvef(mode, file, args, None, execv) File "/usr/lib64/python3.6/os.py", line 838, in _spawnvef raise ValueError('argv first element cannot be empty') ValueError: argv first element cannot be empty make[2]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/timeout' make[2]: *** [Makefile:54: calibrate.out] Error 1 make[1]: Leaving directory '/builddir/build/BUILD/ghc-8.2.0.20170404/testsuite/tests' make[1]: *** [../mk/test.mk:293: ../timeout/install-inplace/bin/timeout] Error 2 make: *** [Makefile:217: test] Error 2 }}} Full buildlog at https://copr- be.cloud.fedoraproject.org/results/petersen/ghc-8.2.1/fedora-26-x86_64/00536407-ghc/build.log.gz (for a couple of weeks) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:18:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:18:19 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 Message-ID: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- First noticed [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]. I haven't managed to boil this down to a test case with no dependencies yet, so for the time being, this requires `vector`. To reproduce, follow these steps: {{{ $ git clone https://github.com/erikd/vector $ cd vector/ $ cabal install --only-dependencies --enable-tests -w /opt/ghc/8.2.1/bin/ghc $ cabal configure --enable-tests -w /opt/ghc/8.2.1/bin/ghc $ cabal test }}} When building `vector-tests-O2`, GHC will stall when compiling the `Tests.Vector` module. On machines with modest memory allowances (e.g., [https://travis-ci.org/haskell/vector/jobs/218749281#L1270 the machines used on Travis CI]), GHC will be killed with an out-of-memory error after trying to compile `Tests.Vector` for a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:35:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:35:10 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.b462853128c112318cc6a17aa0b3d7c3@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In particular, limiting GHC's memory to 4 GB is sufficient: {{{ $ bash -c 'ulimit -v 4000000; cabal test' ... Preprocessing test suite 'vector-tests-O2' for vector-0.12.0.1... [6 of 7] Compiling Tests.Vector ( tests/Tests/Vector.hs, dist/build /vector-tests-O2/vector-tests-O2-tmp/Tests/Vector.o ) tests/Tests/Vector.hs:9:1: warning: [-Wunused-imports] The import of ‘Data.Foldable’ is redundant except perhaps to import instances from ‘Data.Foldable’ To import instances alone, use: import Data.Foldable() | 9 | import Data.Foldable (Foldable(foldMap)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ tests/Tests/Vector.hs:25:1: warning: [-Wunused-imports] The import of ‘Data.Monoid’ is redundant except perhaps to import instances from ‘Data.Monoid’ To import instances alone, use: import Data.Monoid() | 25 | import Data.Monoid | ^^^^^^^^^^^^^^^^^^ tests/Tests/Vector.hs:29:1: warning: [-Wunused-imports] The import of ‘Data.Functor.Identity’ is redundant except perhaps to import instances from ‘Data.Functor.Identity’ To import instances alone, use: import Data.Functor.Identity() | 29 | import Data.Functor.Identity | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ tests/Tests/Vector.hs:438:5: warning: [-Wname-shadowing] This binding for ‘limitUnfolds’ shadows the existing binding imported from ‘Utilities’ at tests/Tests/Vector.hs:5:1-24 | 438 | limitUnfolds f (theirs, ours) | ^^^^^^^^^^^^ ghc: out of memory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:40:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:40:11 -0000 Subject: [GHC] #13000: minor doc bug about list fusion in GHC user's guide In-Reply-To: <045.b6f36678f58a796f7f2fbf38ed7ca155@haskell.org> References: <045.b6f36678f58a796f7f2fbf38ed7ca155@haskell.org> Message-ID: <060.a329cb26b4a4eaff13112a562451c64f@haskell.org> #13000: minor doc bug about list fusion in GHC user's guide -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: low | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: nomeata (added) Comment: I believe as a result of the work of Joachim Breitner there are other functions that are good consumers. e.g. sum, product, foldl and foldl'. We should get Joachim to confirm those and possibly others -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 00:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 00:45:06 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.0e491e7a35332e5bbb10a24602b388be@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): From my testing this is fixed in 8.0.2-rc1 (8.2.0.20170404) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 01:55:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 01:55:35 -0000 Subject: [GHC] #13000: minor doc bug about list fusion in GHC user's guide In-Reply-To: <045.b6f36678f58a796f7f2fbf38ed7ca155@haskell.org> References: <045.b6f36678f58a796f7f2fbf38ed7ca155@haskell.org> Message-ID: <060.13679c94508d2df9ab95efaa5ebca737@haskell.org> #13000: minor doc bug about list fusion in GHC user's guide -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: low | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Grepping through the git log (`-G RULES -p libraries/base` etc.) it seems that these functions recently became fusable, mostly due to work by David Feuer: `words`, `unwords`, `takeWhile`, `scanl`, `mapAccumL`, `scanr`, `mapMaybe`, `findIndices`, `unfoldr`, `filterM`, `foldl` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 02:02:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 02:02:59 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.0d884c6ef9b1053cc43980fe17674787@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): If i remember correctly, a `ByteArray#` would have an extra header and a length field, which in turn bring a 2 words overhead, one word more compareing to the `(# int#, addr# #)` solution. But i would argue this overhead can bring a nice solution to ghc's long lasting literal problem, for example, `vector` package and `text` package can provide some TH to directly save some `byteArray#` literal using hexadecimal notation, this save many extra copying during runtime. Finally, by nature of binary loading, this `ByteArray#` is pinned, so we can still get its address without trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 02:58:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 02:58:34 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.9d70d04723655bcfa04ff5c3b8fdcf0b@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Surely you mean 8.2.1-rc1 ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 03:52:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 03:52:45 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.850bf2bfaf23e1de11ebd1b1db36ae70@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Looks like a regular "Core program gets very large" issue. The Core program got very large in 8.0.1 too (I didn't try earlier versions) but now it gets even more very large. I tried with the versions of GHC before and after the Join points commit since I have them lying around. Already before the Join points commit the Core program grows to be very large quickly (actually, even more so than with HEAD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 05:02:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 05:02:07 -0000 Subject: [GHC] #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 Message-ID: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This currently causes the `vector` test suite to loop forever (see [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]). I've reproduced this with GHC 8.2.1 and HEAD. Unfortunately, it's not easy to isolate down to a file with no dependencies, so for now this requires `vector` and `QuickCheck` to reproduce. First, install them: {{{ $ cabal install vector QuickCheck --allow-newer -w /opt/ghc/8.2.1/bin/ghc }}} Then take this file: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module Main (main) where import qualified Data.Vector.Generic as V import qualified Data.Vector.Unboxed as DVU import Test.QuickCheck import Text.Show.Functions () main :: IO () main = do verboseCheck ((\f (i, b) v -> V.foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) ( DVU.toList v)) :: ((Int, Bool) -> (Int, Bool) -> (Int, Bool)) -> (Int, Bool) -> DVU.Vector (Int, Bool) -> Bool) instance (Arbitrary a, DVU.Unbox a) => Arbitrary (DVU.Vector a) where arbitrary = fmap DVU.fromList arbitrary class TestData a where type Model a unmodel :: Model a -> a instance TestData Bool where type Model Bool = Bool unmodel = id instance TestData Int where type Model Int = Int unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) }}} Then compile it with `/opt/ghc/8.2.1/bin/ghc -O2 Main.hs` (the `-O2` part is important). Observe that running it never terminates. However, the same program //does// terminate when compiled with 8.0.2! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 05:03:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 05:03:50 -0000 Subject: [GHC] #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.c0990e0f9d0775cd31baa6f807f5f958@haskell.org> #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Even stranger, that call to `unmodel` within `main` is required to trigger the infinite loop—removing `unmodel` causes the program to terminate again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 06:14:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 06:14:33 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.2ea3ed90b3b93dfc90c46f57a090c7bc@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: 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): OK, well, don't let me stop you guys from adding CallStack to SomeException :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 06:58:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 06:58:47 -0000 Subject: [GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail Message-ID: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> #13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works fine {{{#!hs {-# Language RankNTypes, TypeOperators, KindSignatures, GADTs, ScopedTypeVariables, PolyKinds #-} import Data.Kind data CodTy :: (k -> Type) -> Type where CodTy :: { runCodTy :: (forall r. (f ty -> r) -> r) } -> CodTy f type f ~> g = forall xx. f xx -> g xx fmap' :: (f ~> f') -> (CodTy f -> CodTy f') fmap' f (CodTy m) = CodTy $ \ c -> m (c . f) }}} but adding {{{#!hs fmap' f (CodTy (m :: _)) = CodTy $ \ c -> m (c . f) }}} makes it fail (also fails without `PolyKinds`) {{{ $ ghci -ignore-dot-ghci tNT2.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tNT2.hs, interpreted ) tNT2.hs:11:22: error: • Found type wildcard ‘_’ standing for ‘(f ty -> r0) -> r0’ Where: ‘r0’ is an ambiguous type variable ‘f’ is a rigid type variable bound by the type signature for: fmap' :: forall k (f :: k -> *) (f' :: k -> *). f ~> f' -> CodTy f -> CodTy f' at tNT2.hs:10:10 ‘ty’ is a rigid type variable bound by a pattern with constructor: CodTy :: forall k (f :: k -> *) (ty :: k). (forall r. (f ty -> r) -> r) -> CodTy f, in an equation for ‘fmap'’ at tNT2.hs:11:10 ‘k’ is a rigid type variable bound by the type signature for: fmap' :: forall k (f :: k -> *) (f' :: k -> *). f ~> f' -> CodTy f -> CodTy f' at tNT2.hs:10:10 To use the inferred type, enable PartialTypeSignatures • In a pattern type signature: _ In the pattern: m :: _ In the pattern: CodTy (m :: _) • Relevant bindings include f :: f ~> f' (bound at tNT2.hs:11:7) fmap' :: f ~> f' -> CodTy f -> CodTy f' (bound at tNT2.hs:11:1) tNT2.hs:11:46: error: • Couldn't match type ‘r0’ with ‘r’ because type variable ‘r’ would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: (f' ty -> r) -> r at tNT2.hs:11:28-51 Expected type: f ty -> r0 Actual type: f ty -> r • In the first argument of ‘m’, namely ‘(c . f)’ In the expression: m (c . f) In the second argument of ‘($)’, namely ‘\ c -> m (c . f)’ • Relevant bindings include c :: f' ty -> r (bound at tNT2.hs:11:38) m :: (f ty -> r0) -> r0 (bound at tNT2.hs:11:17) Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 07:06:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 07:06:00 -0000 Subject: [GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail In-Reply-To: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> References: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> Message-ID: <066.ad97d79189aa64d2598894b5b4c1cdea@haskell.org> #13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): And giving `\c -> m (c . d)` a name (without a type signature, I'm don't have enough bravery to attempt that so early in the morning) doesn't work, I don't know if intended behaviour or not {{{#!hs fmap' :: (f ~> f') -> (CodTy f -> CodTy f') fmap' f (CodTy m) = CodTy a where a c = m (c . f) fmap' f (CodTy m) = let a c = m (f . g) in CodTy a fmap' f (CodTy m) = do let a c = m (f . g) CodTy a }}} Okay never mind I worked it out, this works {{{#!hs fmap' :: forall f f'. (f ~> f') -> (CodTy f -> CodTy f') fmap' f (CodTy (m :: forall r'. (f ty -> r') -> r')) = CodTy a where a :: forall r. (f' ty -> r) -> r a c = m (c . f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 07:54:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 07:54:58 -0000 Subject: [GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail In-Reply-To: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> References: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> Message-ID: <066.cd0ace896d84ac436fc91a10399fee44@haskell.org> #13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider this: {{{ data T where MkT :: (forall a. a->a) -> T f (MkT (g :: Int->Int)) = .. }}} Is this ok? Well yes. The argument of `MkT` has type `forall a. a->a`, but it can be instantiated to the type `Int->Int`, so we can legitimately end up with `g :: Int->Int`. In FC it'd look like {{{ f x = case x of MkT (g2 :: forall a.a->a) -> let g::Int->Int = g2 @ Int in ... }}} Now you want to force the type of the pattern to be `_`. But since GHC only supports predicative polymorphism, `_` must be a monotype. So GHC instantiates `forall a. a->a` to `alpha -> alpha` (for some new unification variable alpha), and proceeds. And that is what you see in the first message "Found type wildcard...". But alas of course, in your example we need `m` to be a polytype, and making it a monotype leads to a subsequent rather obscure error message. Does that help? Is there some way we could improve the user manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 08:32:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 08:32:35 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families Message-ID: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider a problem of injective cons on a type-level list [https://ghc.haskell.org/trac/ghc/ticket/12114]. I made a small workaround by adding an intermediate data type `List1 k`. Here is my code: {{{#!hs {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeFamilies, TypeFamilyDependencies #-} {-# LANGUAGE KindSignatures, DataKinds, PolyKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeApplications #-} module TFTest where import GHC.TypeLits import Data.Proxy -- | Synonym for a type-level snoc (injective!) type (ns :: [k]) +: (n :: k) = GetList1 (SinkFirst (n ': ns)) infixl 5 +: -- | A weird data type used to make `(+:)` operation injective. -- `List k [k]` must have at least two elements. data List1 k = L1Single k | L1Head k [k] -- | Sink first element of a list to the end of the list type family SinkFirst (xs :: [k]) = (ys :: List1 k) | ys -> xs where SinkFirst '[y] = 'L1Single y -- SinkFirst (y ': x ': xs :: [Nat]) -- = ('L1Head x (GetList1Nat (SinkFirst (y ': xs))) :: List1 Nat) SinkFirst (y ': x ': xs :: [k]) = ('L1Head x (GetList1 (SinkFirst (y ': xs))) :: List1 k) type family GetList1 (ts :: List1 k) = (rs :: [k]) | rs -> ts where GetList1 ('L1Single x) = '[x] GetList1 ('L1Head y (x ':xs)) = y ': x ': xs type family GetList1Nat (ts :: List1 Nat) = (rs :: [Nat]) | rs -> ts where GetList1Nat ('L1Single x) = '[x] GetList1Nat ('L1Head y (x ': xs)) = y ': x ': xs type family (++) (as :: [k]) (bs :: [k]) :: [k] where '[] ++ bs = bs (a ': as) ++ bs = a ': (as ++ bs) ff :: Proxy k -> Proxy (as +: k) -> Proxy (k ': bs) -> Proxy (as ++ bs) ff _ _ _ = Proxy yy :: Proxy '[3,7,2] yy = ff (Proxy @5) (Proxy @'[3,7,5]) (Proxy @'[5,2]) }}} This gives me the following error: {{{ ~/TFTest.hs: 47, 21 • Couldn't match kind ‘k’ with ‘Nat’ When matching the kind of ‘7 : xs’ Expected type: Proxy ((3 : (7 : xs)) +: 5) Actual type: Proxy '[3, 7, 5] • In the second argument of ‘ff’, namely ‘(Proxy @'[3, 7, 5])’ In the expression: ff (Proxy @5) (Proxy @'[3, 7, 5]) (Proxy @'[5, 2]) In an equation for ‘yy’: yy = ff (Proxy @5) (Proxy @'[3, 7, 5]) (Proxy @'[5, 2]) }}} However, if I uncomment lines `26-27`, the code works perfectly fine! This behaviour feels like a bug in type checker, though I am not sure. If it is not, please, explain me what happens here? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:34:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:34:13 -0000 Subject: [GHC] #13506: Spurious extra error message due to functional dependencies In-Reply-To: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> References: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> Message-ID: <061.f049d2a5f9b6a20c743050e6ffab1999@haskell.org> #13506: Spurious extra error message due to functional dependencies -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"48daaaf0bba279b6e362ee5c632de69ed31ab65d/ghc" 48daaaf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48daaaf0bba279b6e362ee5c632de69ed31ab65d" Don't report fundep wanted/wanted errors This makes GHC drop derived FunDep errors when they are come from wanted/wanted interactions. Much along the lines of "don't rewrite wanteds with wanteds". See TcRnTypes Note [Dropping derived constraints] and the new code in isDroppableDerivedLoc. Fixes Trac #13506. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:34:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:34:13 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.d1ada3b5ee7611cb5d2a839a7d66ea1d@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 Simon Peyton Jones ): In [changeset:"bac95f9de5bd8d0a647a3a1e4492497603c2fda2/ghc" bac95f9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bac95f9de5bd8d0a647a3a1e4492497603c2fda2" Yet another attempt at inferring the right quantification TcSimplify.decideQuantification is truly a tricky function! Trac #13509 showed that we were being over-eager with defaulting of runtime-rep variables (levity polymorphism), which meant that a program was wrongly rejected, and with a very odd error message (c.f. Trac #13530) I spent an unreasonably long time figuring out how to fix this in a decent way, and ended up with a major refactoring of decideQuantification, with a kock-on effect in simplifyInfer. It is at least a bit more comprehensible now; but I still can't say I like it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:34:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:34:13 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors In-Reply-To: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> References: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> Message-ID: <063.1afc5d8ee779f56402461ebd0f7f6085@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2f9f1f86849ebc18af409c9b3fd809c9cd464021/ghc" 2f9f1f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f9f1f86849ebc18af409c9b3fd809c9cd464021" Add a missing addDeferredBinding I'd forgotten to add deferred bindings for user type errors. Fixes Trac #13487. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:34:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:34:13 -0000 Subject: [GHC] #13509: Perplexing type error with unboxed tuples In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.02662d082dcc93f2e2e2b7868d063f06@haskell.org> #13509: Perplexing type error with unboxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"bac95f9de5bd8d0a647a3a1e4492497603c2fda2/ghc" bac95f9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bac95f9de5bd8d0a647a3a1e4492497603c2fda2" Yet another attempt at inferring the right quantification TcSimplify.decideQuantification is truly a tricky function! Trac #13509 showed that we were being over-eager with defaulting of runtime-rep variables (levity polymorphism), which meant that a program was wrongly rejected, and with a very odd error message (c.f. Trac #13530) I spent an unreasonably long time figuring out how to fix this in a decent way, and ended up with a major refactoring of decideQuantification, with a kock-on effect in simplifyInfer. It is at least a bit more comprehensible now; but I still can't say I like it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:34:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:34:13 -0000 Subject: [GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE In-Reply-To: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> References: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> Message-ID: <064.f97a30d9dac9a2b04fe76aa28c6d3f3d@haskell.org> #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) 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 Simon Peyton Jones ): In [changeset:"65b185d4886b4efa3efe3cc5ecc8dd6e07d89afe/ghc" 65b185d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="65b185d4886b4efa3efe3cc5ecc8dd6e07d89afe" Be less aggressive about fragile-context warrnings In the implementation of WarnSimplifiableClassConstraints, be less aggressive about reporting a problem. We were complaining about a "fragile" case that in fact was not fragile. See Note [Simplifiable given constraints] in TcValidity. This fixes Trac #13526. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:35:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:35:25 -0000 Subject: [GHC] #13506: Spurious extra error message due to functional dependencies In-Reply-To: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> References: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> Message-ID: <061.5bab46618f0d16d674142a24998a77dc@haskell.org> #13506: Spurious extra error message due to functional dependencies -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T13506 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T13506 * status: new => closed * resolution: => fixed Comment: Excellent test case, thank you. Fixed! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:36:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:36:34 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors In-Reply-To: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> References: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> Message-ID: <063.2169c30a33fd8e23643873d6d90166ba@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T13487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T13487 Comment: Thanks for the nice example. Happily, a one-line fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:37:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:37:42 -0000 Subject: [GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE In-Reply-To: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> References: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> Message-ID: <064.6305d2ec520f021b0f9ed5b5969ce037@haskell.org> #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13526 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T13526 Comment: Excellent point. There is a nice easy fix. Could be merged to the branch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:37:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:37:49 -0000 Subject: [GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE In-Reply-To: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> References: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> Message-ID: <064.29cf868f0c881050f195c22c8c8311af@haskell.org> #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13526 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 11:40:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 11:40:37 -0000 Subject: [GHC] #13509: Perplexing type error with unboxed tuples In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.5d96a5b42d09119e2e00ee2265fe9366@haskell.org> #13509: Perplexing type error with unboxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: I think I've fixed this. Things are better. It's a fairly big patch, so I suppose that I could have introduced some new bug (although it validates fine). I'm open-minded about whether to merge it to 8.2. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 12:10:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 12:10:30 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors In-Reply-To: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> References: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> Message-ID: <063.d6ab88f248feee60789cee95ca9991bc@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T13487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by DimaSamoz): Fantastic, thank you very much! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 12:19:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 12:19:02 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.5b11b5d86f1dafec7567892130acc1ae@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Sorry, yes I mean 8.2.1-rc1 ((8.2.0.20170404)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 12:38:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 12:38:17 -0000 Subject: [GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler In-Reply-To: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> References: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> Message-ID: <059.0c523b2dbee3a3fab80ee5f628fec7db@haskell.org> #13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hi, It is too complicated for me to open a proposal. I do not understand the English language well. If this idea interests someone, it can use it and implement it. I did not get much feedback in this request. Thank you to those who have already given theirs.\\ I give up.\\ \\ For reminder, here was my proposal:\\ Write the names of the people who are in the Committee, in the compiler, from Committee No. 1 to the present one, to pay tribute to them. In September of 1987 a meeting was held at the conference on Functional Programming Languages and Computer Architecture in Portland, Oregon, to discuss an unfortunate situation in the functional programming community. It was decided that a committee should be formed to design such a language, providing faster communication of new ideas, a stable foundation for real applications development, and a vehicle through which others would be encouraged to use functional languages.\\ And the Haskell language was born...\\ In September of 2017, Haskell will be 30 years old.\\ This seems like a good year for this proposal.\\ For this you have to rewrite the names found in the Haskell Report 2010, and add the rest of the people of other years. We can also add those who have contributed in the past and present in various way, or write only the names of the people who were part of Commitee No. 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 13:06:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 13:06:42 -0000 Subject: [GHC] #13530: Horrible error message due to TypeInType In-Reply-To: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> References: <046.7f90b8f6757202f3254e50dc0157ad21@haskell.org> Message-ID: <061.5cf31910cc6a44f111d34a125e51701b@haskell.org> #13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this > {{{ > {-# LANGUAGE MagicHash, UnboxedTuples #-} > > module Foo where > > import GHC.Exts > > g :: Int -> (# Int#, a #) > g (I# y) = (# y, undefined #) > > f :: Int -> (# Int#, Int# #) > f x = g x > }}} > With GHC 8 we get > {{{ > Foo.hs:11:7: error: > • Couldn't match a lifted type with an unlifted type > Expected type: (# Int#, Int# #) > Actual type: (# Int#, Int# #) > }}} > What a terrible error message!! It was much better in GHC 7.10: > {{{ > Foo.hs:11:7: > Couldn't match kind ‘*’ with ‘#’ > When matching types > a0 :: * > Int# :: # > Expected type: (# Int#, Int# #) > Actual type: (# Int#, a0 #) > }}} > What's going on? > > The constraint solver sees > {{{ > [W] alpha::TYPE LiftedRep ~ Int#::TYPE IntRep > }}} > So it homogenises the kinds, ''and unifies alpha'' (this did not happen > in GHC 7.10), thus > {{{ > alpha := Int# |> TYPE co > > [W] co :: LiftedRep ~ IntRep > }}} > Of course the new constraint fails. But since we have unified alpha, > when we print out the types are are unifying they both look like `(# > Int#, Int# #)` (there's a suppressed cast in the second component). > > I'm not sure what to do here. New description: Consider this {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Foo where import GHC.Exts g :: Int -> (# Int#, a #) g (I# y) = (# y, undefined #) f :: Int -> (# Int#, Int# #) f x = g x }}} With GHC 8 we get {{{ Foo.hs:11:7: error: • Couldn't match a lifted type with an unlifted type Expected type: (# Int#, Int# #) Actual type: (# Int#, Int# #) }}} What a terrible error message!! It was much better in GHC 7.10: {{{ Foo.hs:11:7: Couldn't match kind ‘*’ with ‘#’ When matching types a0 :: * Int# :: # Expected type: (# Int#, Int# #) Actual type: (# Int#, a0 #) }}} What's going on? The constraint solver sees {{{ [W] alpha::TYPE LiftedRep ~ Int#::TYPE IntRep }}} So it homogenises the kinds, ''and unifies alpha'' (this did not happen in GHC 7.10), thus {{{ alpha := Int# |> TYPE co [W] co :: LiftedRep ~ IntRep }}} Of course the new constraint fails. But since we have unified alpha, when we print out the types are are unifying they both look like `(# Int#, Int# #)` (there's a suppressed cast in the second component). I'm not sure what to do here. (I tripped over this when debugging #13509.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 13:07:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 13:07:54 -0000 Subject: [GHC] #13509: Perplexing type error with unboxed tuples In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.a63fa6214d793164a11aadab1ec024c3@haskell.org> #13509: Perplexing type error with unboxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: this does NOT fix #11530 and #11198. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 13:14:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 13:14:03 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families In-Reply-To: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> References: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> Message-ID: <062.be53cac9f52dff71014a667a48f6f3e3@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, your program typechecks in GHC 8.2.1 and HEAD. I don't know what commit fixed it, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 13:25:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 13:25:38 -0000 Subject: [GHC] #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.af036f94177bb6128d941926378a1299@haskell.org> #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, `vector` isn't needed here. Here's an example that only requires `QuickCheck`: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Main (main) where import Test.QuickCheck import Text.Show.Functions () main :: IO () main = verboseCheck foldlTest type FoldlTest a = (a -> a -> a) -> a -> [a] -> Bool foldlTest :: FoldlTest (Int, Int) foldlTest f (i, b) v = foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) v class TestData a where type Model a unmodel :: Model a -> a instance TestData Int where type Model Int = Int unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) }}} Another observation is that the type `(Int, Int)` is crucial for triggering the infinite loop. If you use, say, `FoldlTest Int` instead of `FoldlTest (Int, Int)`, then it terminates again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 13:54:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 13:54:04 -0000 Subject: [GHC] #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.c6833dbed1e513c602f893cab442106c@haskell.org> #13536: Program which terminated in GHC 8.0.2 loops with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): More progress. Here is a program which //deterministically// exhibits the issue (i.e., it doesn't rely on system-generated pseudorandomness): {{{#!hs {-# LANGUAGE TypeFamilies #-} module Main (main) where import System.Random.TF.Gen (seedTFGen) import Test.QuickCheck (arbitrary) import Test.QuickCheck.Gen (Gen(..)) import Test.QuickCheck.Random (QCGen(..)) import Text.Show.Functions () main :: IO () main = do let tfGen = seedTFGen ( 543863073959529591 , 14453565003432405558 , 3036645681517334938 , 17781306407512891751 ) qcGen = QCGen tfGen (f, (i, b), v) = case arbitrary of MkGen g -> g qcGen 30 print $ foldlTest f (i, b) v type FoldlTest a = (a -> a -> a) -> a -> [a] -> Bool foldlTest :: FoldlTest (Int, Int) foldlTest f (i, b) v = foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) v class TestData a where type Model a unmodel :: Model a -> a instance TestData Int where type Model Int = Int unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) }}} I'd also like to retract my claim that this program is looping forever. I timed this program when compiled with `-O2` on GHC 8.2.1: {{{ 137.01user 0.47system 2:17.43elapsed 100%CPU (0avgtext+0avgdata 7476maxresident)k 0inputs+0outputs (0major+936minor)pagefaults 0swaps }}} As opposed to GHC 8.0.2: {{{ 0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 4768maxresident)k 0inputs+0outputs (0major+289minor)pagefaults 0swaps }}} So there's still a bug, but I don't think it's infinite in nature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 13:54:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 13:54:33 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 (was: Program which terminated in GHC 8.0.2 loops with 8.2.1) In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.c358c573434dc93b094e4fb8e93163cf@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 15:31:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 15:31:55 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.4d1d084b65c58841c8fca5f0fb1f4acc@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a version with no dependencies: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Main where import Control.Monad (ap, liftM, liftM2, liftM3, replicateM) import Data.Int (Int32) main :: IO () main = do let stdGen = StdGen 1523085842 1207612140 qcGen = QCGen stdGen (f, (i, b), v) = case arbitrary of MkGen g -> g qcGen 30 print $ foldlTest f (i, b) v type FoldlTest a = (a -> a -> a) -> a -> [a] -> Bool foldlTest :: FoldlTest (Bool, Bool) foldlTest f (i, b) v = foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) v class TestData a where type Model a unmodel :: Model a -> a instance TestData Bool where type Model Bool = Bool unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) ------------------------------------------------------------------------------- -- random stuff data StdGen = StdGen !Int32 !Int32 stdNext :: StdGen -> (Int, StdGen) stdNext (StdGen s1 s2) = (fromIntegral z', StdGen s1'' s2'') where z' = if z < 1 then z + 2147483562 else z z = s1'' - s2'' k = s1 `quot` 53668 s1' = 40014 * (s1 - k * 53668) - k * 12211 s1'' = if s1' < 0 then s1' + 2147483563 else s1' k' = s2 `quot` 52774 s2' = 40692 * (s2 - k' * 52774) - k' * 3791 s2'' = if s2' < 0 then s2' + 2147483399 else s2' stdRange :: StdGen -> (Int,Int) stdRange _ = (1, 2147483562) stdSplit :: StdGen -> (StdGen, StdGen) stdSplit std@(StdGen s1 s2) = (left, right) where left = StdGen new_s1 t2 right = StdGen t1 new_s2 new_s1 | s1 == 2147483562 = 1 | otherwise = s1 + 1 new_s2 | s2 == 1 = 2147483398 | otherwise = s2 - 1 StdGen t1 t2 = snd (stdNext std) ------------------------------------------------------------------------------- -- QuickCheck newtype QCGen = QCGen StdGen newtype Gen a = MkGen{ unGen :: QCGen -> Int -> a } variant :: Integral n => n -> Gen a -> Gen a variant k (MkGen g) = MkGen (\r n -> g (variantQCGen k r) n) bigNatVariant :: Integer -> StdGen -> StdGen bigNatVariant n g | g `seq` stop n = chip True (fromInteger n) g | otherwise = (bigNatVariant $! chop n) $! chip False (fromInteger n) g {-# INLINE natVariant #-} natVariant :: Integral a => a -> StdGen -> StdGen natVariant n g | g `seq` stop n = chip True (fromIntegral n) g | otherwise = bigNatVariant (toInteger n) g {-# INLINE variantTheGen #-} variantTheGen :: Integral a => a -> StdGen -> StdGen variantTheGen n g | n >= 1 = natVariant (n-1) (boolVariant False g) | n == 0 = natVariant (0 `asTypeOf` n) (boolVariant True g) | otherwise = bigNatVariant (negate (toInteger n)) (boolVariant True g) boolVariant :: Bool -> StdGen -> StdGen boolVariant False = fst . stdSplit boolVariant True = snd . stdSplit variantQCGen :: Integral a => a -> QCGen -> QCGen variantQCGen n (QCGen g) = QCGen (variantTheGen n g) chip :: Bool -> Int -> StdGen -> StdGen chip finished n = boolVariant finished . boolVariant (even n) chop :: Integer -> Integer chop n = n `div` 2 stop :: Integral a => a -> Bool stop n = n <= 1 instance Functor Gen where fmap f (MkGen h) = MkGen (\r n -> f (h r n)) instance Applicative Gen where pure = return (<*>) = ap instance Monad Gen where return x = MkGen (\_ _ -> x) MkGen m >>= k = MkGen (\(QCGen r) n -> let (r1,r2) = case stdSplit r of (g1, g2) -> (QCGen g1, QCGen g2) MkGen m' = k (m r1 n) in m' r2 n ) promote :: Monad m => m (Gen a) -> Gen (m a) promote m = do eval <- delay return (liftM eval m) delay :: Gen (Gen a -> a) delay = MkGen (\r n g -> unGen g r n) listOf :: Gen a -> Gen [a] listOf gen = sized $ \n -> do k <- chooseInt (0,n) vectorOf k gen vectorOf :: Int -> Gen a -> Gen [a] vectorOf = replicateM sized :: (Int -> Gen a) -> Gen a sized f = MkGen (\r n -> let MkGen m = f n in m r n) chooseInt :: (Int, Int) -> Gen Int chooseInt rng = MkGen (\r _ -> let (x,_) = randomIvalIntegral rng r in x) qcGenRange :: QCGen -> (Int, Int) qcGenRange (QCGen g) = stdRange g qcGenNext :: QCGen -> (Int, QCGen) qcGenNext (QCGen g) = case stdNext g of (x, g') -> (x, QCGen g') randomIvalIntegral :: (Integral a) => (a, a) -> QCGen -> (a, QCGen) randomIvalIntegral (l,h) = randomIvalInteger (toInteger l, toInteger h) randomIvalInteger :: (Num a) => (Integer, Integer) -> QCGen -> (a, QCGen) randomIvalInteger (l,h) rng | l > h = randomIvalInteger (h,l) rng | otherwise = case (f 1 0 rng) of (v, rng') -> (fromInteger (l + v `mod` k), rng') where (genlo, genhi) = qcGenRange rng b = fromIntegral genhi - fromIntegral genlo + 1 q = 1000 k = h - l + 1 magtgt = k * q f mag v g | mag >= magtgt = (v, g) | otherwise = v' `seq`f (mag*b) v' g' where (x,g') = qcGenNext g v' = (v * b + (fromIntegral x - fromIntegral genlo)) chooseBool :: (Bool, Bool) -> Gen Bool chooseBool rng = MkGen (\r _ -> let (x,_) = randomRBool rng r in x) randomRBool :: (Bool, Bool) -> QCGen -> (Bool, QCGen) randomRBool (a,b) g = case (randomIvalInteger (bool2Int a, bool2Int b) g) of (x, g') -> (int2Bool x, g') where bool2Int :: Bool -> Integer bool2Int False = 0 bool2Int True = 1 int2Bool :: Int -> Bool int2Bool 0 = False int2Bool _ = True class Arbitrary a where arbitrary :: Gen a instance Arbitrary Bool where arbitrary = chooseBool (False, True) instance Arbitrary a => Arbitrary [a] where arbitrary = listOf arbitrary instance (Arbitrary a, Arbitrary b) => Arbitrary (a, b) where arbitrary = liftM2 (,) arbitrary arbitrary instance (Arbitrary a, Arbitrary b, Arbitrary c) => Arbitrary (a,b,c) where arbitrary = liftM3 (,,) arbitrary arbitrary arbitrary instance (CoArbitrary a, Arbitrary b) => Arbitrary (a -> b) where arbitrary = promote (`coarbitrary` arbitrary) class CoArbitrary a where coarbitrary :: a -> Gen b -> Gen b instance (CoArbitrary a, CoArbitrary b) => CoArbitrary (a,b) where coarbitrary (x,y) = coarbitrary x . coarbitrary y instance CoArbitrary Bool where coarbitrary False = variant (0 :: Int) coarbitrary True = variant (1 :: Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 16:34:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 16:34:10 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.a8f3dfe3ab2f2ad28e2f2018973e2650@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Here is a version without any of the random or quickcheck stuff. (I used the actual `i`, `b`, `v` values from the test and wrote down an arbitrary strict function `f`.) {{{#!hs {-# LANGUAGE TypeFamilies #-} module Main where import Control.Monad (ap, liftM, liftM2, liftM3, replicateM) import Data.Int (Int32) main :: IO () main = do let f :: (Bool, Bool) -> (Bool, Bool) -> (Bool, Bool) f (True, False) (False, False) = (False, True) f _ _ = (True, False) ((i, b), v) = ((False,True),[(False,True),(False,False),(True,True),(True,False),(False,False),(False,True),(True,True),(True,True),(False,True),(True,False),(False,False),(True,True),(True,True),(False,False),(False,False),(False,True),(True,False),(True,False),(True,True),(True,True),(False,True),(True,False),(True,False),(True,True),(False,False),(True,True),(False,False),(True,False),(False,True),(True,True)]) print $ foldlTest f (i, b) v type FoldlTest a = (a -> a -> a) -> a -> [a] -> Bool foldlTest :: FoldlTest (Bool, Bool) foldlTest f (i, b) v = foldl f (i, b) v == foldl (\x -> f (unmodel x)) (i, b) v class TestData a where type Model a unmodel :: Model a -> a instance TestData Bool where type Model Bool = Bool unmodel = id instance (Eq a, Eq b, TestData a, TestData b) => TestData (a,b) where type Model (a,b) = (Model a, Model b) unmodel (a,b) = (unmodel a, unmodel b) }}} Observations so far: * Making the match in `unmodel` lazy (`unmodel ~(a,b) = ...`) makes the program fast again. * Adding an explicit export list `module Main (main) where` also makes the program fast again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 16:49:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 16:49:29 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.47288c403aade7f1ed9d2aecaad1cb92@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Stunning. I'll look. (But by all means keep going yourself.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 16:52:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 16:52:30 -0000 Subject: [GHC] #13539: Options -pgmlclang and -pgmlc overlap Message-ID: <042.e01c07cdbb1c0d713db0b33fff4d39b7@haskell.org> #13539: Options -pgmlclang and -pgmlc overlap -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.2 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: -------------------------------------+------------------------------------- I tried to tell GHC to use `clang` with `-pgmlclang`, and only after some time found out that it won't work, because GHC interprets that as `-pgmlc` `lang` (surprise, `-pgmlc` is also an option). The user manual suggests that `pgmc` (without space) is the recommended syntax. If spaces are in fact allowed, we should change the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 16:58:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 16:58:15 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.370ba22275deeca32da694d6a3f568f6@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well this is quite interesting. The culprit is apparently the new STG CSE pass. It's fast with `-fno-stg-cse` and slow with `-fstg-cse`, and the only change in the STG is {{{#!diff case eta_s5Di of { (,) a_s5Dn [Occ=Once] b_s5Do [Occ=Once] -> - (,) [a_s5Dn b_s5Do]; + eta_s5Di; }; }}} which is the body of {{{#!hs unmodel (a,b) = (unmodel a, unmodel b) }}} It certainly makes sense that STG CSE would do that and that it couldn't be done in Core-level CSE, because the types `Model Bool` and `Bool` are different there; but I don't yet understand why it is ''bad'' in this program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 17:17:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 17:17:26 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.90b83d1008b23564196d70fea8ecd046@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Zooming out a bit: {{{ let { go1_s5D8 [Occ=LoopBreaker] :: [(GHC.Types.Bool, GHC.Types.Bool)] -> (GHC.Types.Bool, GHC.Types.Bool) -> (GHC.Types.Bool, GHC.Types.Bool) [LclId, Arity=2, Str=, Unf=OtherCon []] = sat-only \r [ds_s5Dh eta_s5Di] case ds_s5Dh of { [] -> eta_s5Di; : y_s5Dk [Occ=Once] ys_s5Dl [Occ=Once] -> let { sat_s5Dq [Occ=Once, Dmd=] :: (GHC.Types.Bool, GHC.Types.Bool) [LclId] = \s [] let { sat_s5Dp [Occ=Once] :: (GHC.Types.Bool, GHC.Types.Bool) [LclId] = \u [] case eta_s5Di of { (,) a_s5Dn [Occ=Once] b_s5Do [Occ=Once] -> eta_s5Di; }; } in w_s5CS sat_s5Dp y_s5Dk; } in go1_s5D8 ys_s5Dl sat_s5Dq; }; } in }}} Is it okay for the `sat_s5Dq` thunk to be marked as single-entry? It is passed as the second argument of the recursive call to `go1` but after the CSE `go1`'s second argument `eta_s5Di` actually appears twice (as the scrutinee of the `case`, and then again as the body of the `case`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 17:18:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 17:18:54 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.dd7cfb4ad1f8696238563845b23a644d@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Maybe CSE here should have replaced the pair `(a,b)` by the case binder, not the scrutinee? Would that work in general (in the sense of not making the occurrence analysis incorrect)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 17:43:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 17:43:07 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.78b82c7bafaa0bee74689ec6c1ec32e0@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: nomeata (added) Comment: > The culprit is apparently the new STG CSE pass Ah yes! We very carefully run a final demand-analysis just before tidy- core, precisely to ensure that the used-once info (which can get invalidated) is correct before code gen. But the STG CSE pass is undoing that goodness. Total disaster. I'll think about how best to do this. Copying Joachim who added CSE for STG> -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 17:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 17:59:10 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.287ddb402404b8f262e398e2f5d7dbf3@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If i remember correctly, a `ByteArray#` would have an extra header and a length field, which in turn bring a 2 words overhead, one word more compareing to the `(# int#, addr# #)` solution. Right, this would incur another word of overhead. However, on the majority of machines this is 8-bytes which is quite significant. Looking at GHC itself, just over a third of all string literals are 8 characters or less (6000 our of 17500). For these literals adding another word would increase the fractional overhead from >50% to >67%. I have spoken with GHC users targeting mobile platforms who already suffer from our code size; it's hard to justify such an increase without a very good reason. > But i would argue this overhead can bring a nice solution to ghc's long lasting literal problem, for example, vector package and text package can provide some TH to directly save some byteArray# literal using hexadecimal notation, this save many extra copying during runtime. What is stopping these libraries from providing this mechanism currently using `Addr#` and primitive strings directly? In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 18:16:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 18:16:09 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.2992c7e8c0645f885e13e0963afe5c05@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bredelings): * cc: bredelings (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 18:38:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 18:38:36 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families In-Reply-To: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> References: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> Message-ID: <062.022d773effd5f27a1eb1a8e6324ef7fa@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13135 | Differential Rev(s): Phab:D3426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3426 * related: => #13135 * milestone: => 8.2.1 Comment: It seems that commit 2b64e926a628fb2a3710b0360123ea73331166fe (#13135) fixes this. I've added a regression test for this in Phab:D3426. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 18:56:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 18:56:17 -0000 Subject: [GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE In-Reply-To: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> References: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> Message-ID: <064.3af99e429acf961fd36f05d11da6b226@haskell.org> #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13526 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cocreature): Thank you for looking into this so quickly! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 20:59:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 20:59:14 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.04e048b18a98c2ed43872c56f781ff04@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Duog, I've posted the relevant pieces of your branch to Phabricator as Phab:D3427. Feel free to "commandeer" this Differential using the Actions menu at the bottom on the page. Once you have done so you can update the Diff using `arc diff --update D3427`. Do let me know if I can be of assistance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 20:59:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 20:59:54 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.87ef14416615dbdd5cdda4090956b139@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, I've had a bit of a look. First, if we'd done this: {{{ case eta_s5Di of wild1 { (,) a b -> (,) a b ====> case eta_s5Di of wild1 { (,) a b -> wild1 }}} we'd have been fine. Because `eta_s5Di` points to a single-entry thunk (as comment:9 so accurately points out) the thunk won't be updated. But `wild1` will be bound to the heap-allocated pair returned from evaluating `eta_s5Di`, not to the `eta_s5Di` thunk, so all would be well. In fact it's ''better'' even if `eta_s5Di` is updated, because if we use `eta_s5Di` in the case alternative we have to save it across the eval, whereas if we use `wild1` we just use the returned pair directly. Better all round. So why are we using `eta_s5Di`? Because of this code: {{{ cse_bndr | StgApp trivial_scrut [] <- scrut' = trivial_scrut -- See Note [Trivial case scrutinee] | otherwise = bndr' }}} The reason for this is explained in the Note, but means that we use `eta_s5Di` instead of `wild1`, with exponentially worse cost! This is very bad. '''Short term fix''' (Reid): just say {{{ cse_bndr = bndr' }}} and it'll all work fine. ------------------ '''One side point'''. Binders in STG have occurrence info attached, and `wild1` is marked as dead. If we use it, it'll suddenly become un-dead; it'd make me uneasy to have lying occurrence info. (Apart from anything else, the pretty printer doesn't print a dead binder, which is confusing if it is then mentioned.) Why do we need occurrence info on binders? Search for `isDeadBinder` in `codeGen`. However, I don't think it ever matters for ''case binders'', so we could safely drop occurrence info for them algoteher. ------------------ Back to the main point. Why do we need that special case in `cse_bndr`? Reason: consider {{{ case x of r1 Just a -> case a of r2 Just b -> let v = Just b in Just v }}} We want ultimately to get {{{ case x of r1 Just a -> case a of r2 Just b -> r1 }}} What actually happens is this. Suppose we didn't have the special case, and always used `bndr'` (as in "Short term fix" above). Then * In the `Just a ->` alternative, we'd extend `ce_conAppMap` with {{{ ce_conAppMap = Just a :-> r1 }}} * Now in the `Just b ->` alternative, we further extend it thus {{{ ce_conAppMap = Just a :-> r1 Just b :-> r2 }}} * Now when we see `let v = Just b`, we'll add the substitution `v :-> r2`, and drop the let-binding (good). * But now when we see the `Just v` we'll substitute to get `Just r2`. But alas! There is no entry `Just r2 :-> r1` in the `ce_conAppMap`, only `Just a :-> r`. (Of course, `a` and `r2` are synonymous here.) So that's the problem that `Note [Trivial case scrutinee]` is supposed to fix. With the `cse_bndr` fix, the `ce_conAppMap` looks like {{{ ce_conAppMap = Just a :-> x Just b :-> a }}} And now we'll end up with {{{ case x of r1 Just a -> case a of r2 Just b -> x }}} which does collapse the nested allocation, but at the expense of introducing the exponential performance bug. But it's so unnecesary! All we need do is to use `r1` instad of `x` in the final result and all will be well. The crucial point is this '''we must only add extra references to variables (like `r1` and `r2`) bound to data constructors, not to variables (like `x`, `a`, and `b`) bound to thunks'''. ---------------------- How can we get the best of both worlds? Here's my idea * '''Ensure that the range of `ce_conAppMap` mentions only variables bound to constructors'''; so do NOT do the `cse_bndr` fix above. * Instead, add a `ce_bndrMap` that maps a case-binder to the scrutinee. Thus, in our example {{{ ce_bndrMap = r1 :-> x r2 :-> a }}} * Now, just before looking up in the `ce_conAppMap`, apply the `ce_bndrMap` to the thing you are looking up. So just before looking up `Just r2`, apply the `ce_bndrMap` to get `Just a` and look ''that'' up. Do not do anything else with the result of applying the `ce_bndrMap`... it's just used to transform a key before looking it up in `ce_conAppMap`. Bingo. Now, do we really need THREE maps in `CseEnv`? No: it is easy to combine `ce_renaming` and `ce_subst`, which is what we do in `CSE.hs`. Finally, a bug in the comments. Here: {{{ , ce_subst :: IdEnv OutId -- ^ This substitution contains CSE-specific entries. The domain are -- OutIds, so ce_renaming has to be applied first. -- It has an entry x ↦ y when a let-binding `let x = Con y` is -- removed because `let y = Con z` is in scope. }}} In the second-last line, that `Con y` should be `Con z`. '''Joachim''': would you like to work on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:09:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:09:22 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.391e2215637b26760f98591874b062ef@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If only we had #10613 in debug-mode we'd have nailed this much more easily. It's unsettling that we have no debug-check for signle-entry thunks. c.f. also #10218 which was when this same bug showed up in Core CSE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:10:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:10:03 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.b28070ea9650e869e9e9befbb0bda849@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #10536 for an example where it'd have been great to have this feature! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:10:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:10:54 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families In-Reply-To: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> References: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> Message-ID: <062.a39aff2f661380d88bcfc80c38ba14fe@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13135 | Differential Rev(s): Phab:D3426 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great! Let's land that test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:19:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:19:04 -0000 Subject: [GHC] #13540: Enable -msse2 by default on i386 Message-ID: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> #13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- SSE2 has been around for nearly 15 years now and at this point it is supported nearly universally. Currently we pass `-msse2` to numerically- sensitive testsuite tests since x87 is too imprecise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:19:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:19:10 -0000 Subject: [GHC] #13540: Enable -msse2 by default on i386 In-Reply-To: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> References: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> Message-ID: <061.cfe91f8a97bd3e3bec1df3e9df9453c8@haskell.org> #13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:27:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:27:09 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.116d851eceb0540fa2dc93ed993385f2@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Great analysis, Simon. Should be straight-forward to implement, I hope. My brain is currently somewhere else, but I can have a look over the weekend, unless someone beats me to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:42:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:42:08 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.dd051b900eb2463fa2c9215a8c047944@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints * status: closed => new * resolution: fixed => * owner: nomeata => (none) Comment: Joachim, I think a better fix would be not to attach call-arity info to `JoinIds` at all, rather than to involve the simplifier. Consider this: {{{ let g = \y. h y True in g 3 7 }}} Ignore the fact that `g` will be inlined; I'm just keeping it simple. What will Call Arity say about `h`? It'll say that `h` is definitely called with ''three'' arguments, right? Becuase `g` is called with two arguemts, one is eaten by the `\y`, so `h` gets three. But suppose instead it was {{{ let g = \y. join j v = h y v in case y of True -> j False False -> j True in g 3 7 }}} Now, we ''could'' analyse this by treating `j` like a normal function, and compute its join arity. That's what we do now. But it's simpler and more direct simply to propagate the "apply to 1 arg" info that we apply to the body of `g` directly into the RHS of `j`. Completely ignore the occurrences of `j`, don't compute their join arity. Roughly: {{{ callArityAnal arity int (Let (NonRec join_id rhs) let_body) | Just join_arity <- isJoinId_maybe join_id = ( ae_join_body `lubRes` ae_let_body , Let (NonRec join_id (mkLams join_bndrs join_body') let_body') ) where (join_bndrs, join_body) = collectNBinders join_arity rhs (ae_join_body, join_body') = callArityAnal arity int join_body (ae_let_body, let_body') = callArityAnal arity int let_body }}} Now that is pretty simple! (Something similar for `Rec`.) In effect, we are pushing the evaluation context into the join RHS, just as described in the paper. I agree that this is extra code... the existing code is still needed. But I think it's possible that it might give beter results in the recursive case. And it's more efficient. And it doesn't bogusly compute a call- arity for a join point. Worth considering? I'll re-open for you to consider it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:44:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:44:24 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families In-Reply-To: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> References: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> Message-ID: <062.01c62c1bf533c09c357eff83863019dc@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13135 | Differential Rev(s): Phab:D3426 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e61900c994334c209a9de763993716314abf9f6d/ghc" e61900c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e61900c994334c209a9de763993716314abf9f6d" Add regression test for #13538 Commit 2b64e926a628fb2a3710b0360123ea73331166fe (#13135) ended up fixing #13538 as well. Let's add a regression test so that it stays fixed. Test Plan: make test TEST=T13538 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13538 Differential Revision: https://phabricator.haskell.org/D3426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:44:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:44:24 -0000 Subject: [GHC] #13135: Typechecker "panic! the 'impossible' happened" In-Reply-To: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> References: <046.c4c259dc1e7ded5f44e5ada27002645a@haskell.org> Message-ID: <061.42c1a6443f3d6cb1f60b70c848c1f5bc@haskell.org> #13135: Typechecker "panic! the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T13135 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e61900c994334c209a9de763993716314abf9f6d/ghc" e61900c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e61900c994334c209a9de763993716314abf9f6d" Add regression test for #13538 Commit 2b64e926a628fb2a3710b0360123ea73331166fe (#13135) ended up fixing #13538 as well. Let's add a regression test so that it stays fixed. Test Plan: make test TEST=T13538 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13538 Differential Revision: https://phabricator.haskell.org/D3426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:44:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:44:24 -0000 Subject: [GHC] #13540: Enable -msse2 by default on i386 In-Reply-To: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> References: <046.ce1e12920034c370a059a5719a6cc885@haskell.org> Message-ID: <061.4768c591410c7ec8c68700059475f7eb@haskell.org> #13540: Enable -msse2 by default on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e5e07be2df1a0d6f1cb47e9d301053445020589c/ghc" e5e07be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5e07be2df1a0d6f1cb47e9d301053445020589c" base: Run num009 with -msse2 on i386 x87's transcendental instructions are terribly imprecise and fail this test. Moreover, we really ouch to enable -mse2 on i386 by default as it is nearly universally supported at this point. See #13540. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:44:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:44:24 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.e84b52bd7bedcaff03fc99a367b7b418@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"59c925e88a1dcb98e62c2b5e0adaa299c3b15e44/ghc" 59c925e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="59c925e88a1dcb98e62c2b5e0adaa299c3b15e44" More changes to fix a space leak in the simplifier (#13426) Part of e13419c55 was accidentally lost during a rebase. This commit adds the missing change, along with some more improvements regarding where we do and don't use `seqType`. Also include a comment about where the space leak showed up and a Note explaining the strategy being used here. Test Plan: harbormaster, plus local testing on DynFlags Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3421 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 21:44:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 21:44:39 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.15fa83c6509a21d023bdc7b33f935232@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Worth considering? I'll re-open for you to consider it. Definitely worth considering! With my limited experience with join points, this sounds reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 22:03:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 22:03:58 -0000 Subject: [GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build In-Reply-To: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> References: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> Message-ID: <065.571bec100441b3126a43b618483cbf2d@haskell.org> #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------+-------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: timeout Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3318 Wiki Page: | --------------------------------+-------------------------------------- Changes (by bgamari): * differential: => Phab:D3318 Comment: Indeed I believe Phab:D3318 was intended to fix a similar issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 22:30:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 22:30:28 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.5469631df7881c19f6f7fd62632060e0@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as f636599165a72a29830341049023651c6fbf38c9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 22:30:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 22:30:57 -0000 Subject: [GHC] #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE In-Reply-To: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> References: <049.fde45c09f71e857116de6d2c1e67f9e4@haskell.org> Message-ID: <064.74a3d9cdad1527e1173b17828df530ac@haskell.org> #13526: -Wsimplifiable-class-constraints behaves differently with OVERLAPPING and OVERLAPPABLE -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13526 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as da17a35a80a2075a76163375175f15b3119b9711. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 22:32:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 22:32:21 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families In-Reply-To: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> References: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> Message-ID: <062.c12df86aefb7f732963d73b68b4ad75e@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13135 | Differential Rev(s): Phab:D3426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Regression test merged go `ghc-8.2` as 4f9e73f1529224d42c1d90c7bf8efad3c9e44cd8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 6 23:18:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Apr 2017 23:18:38 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.7cd559ed31ac1e32474ae09529450041@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Before I forget, there's another opportunity here because of the special form of `sat_s5Dp` after CSE, namely optimizing it to {{{ sat_s5Dp = eta_s5Di }}} We already do this at the Core level and I imagine it wouldn't be hard to do here also. I don't know whether this pattern arises frequently in practice. But consider for example {{{#!hs newtype T a = MkT a f (x, y) = (MkT x, y) }}} (Without the `MkT` the Core simplifier can turn this into `f z@(_, _) = z`, which turns into much simpler code.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:10:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:10:02 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker Message-ID: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As pointed out in #4862, the `gold` linker is significantly faster than BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is an unfortunate situation for users as few packagers take the effort to configure their builds to use `gold`. I think we should consider the following, > Introduce a configure flag (to both the source distribution, and the distributed binary distributions), `--enable-gold`. When enabled, `configure` will check for the functioning of `gcc -fuse-ld=gold`. If found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag would throw an error on non-ELF platforms (which are not supported by `gold`). While there is admittedly not a whole lot of precedent for this, the status quo means we are leaving a significant bit of compiler performance on the table in a majority of cases. Given that `stack` uses GHC's official bindists, we should try to improve this situation. * -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:10:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:10:13 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.38b0c25094e523cf6a7efb05b6fc3620@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 bgamari: Old description: > As pointed out in #4862, the `gold` linker is significantly faster than > BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is > an unfortunate situation for users as few packagers take the effort to > configure their builds to use `gold`. > > I think we should consider the following, > > > Introduce a configure flag (to both the source distribution, and the > distributed binary distributions), `--enable-gold`. When enabled, > `configure` will check for the functioning of `gcc -fuse-ld=gold`. If > found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag > would throw an error on non-ELF platforms (which are not supported by > `gold`). > > While there is admittedly not a whole lot of precedent for this, the > status quo means we are leaving a significant bit of compiler performance > on the table in a majority of cases. Given that `stack` uses GHC's > official bindists, we should try to improve this situation. > > * New description: As pointed out in #4862, the `gold` linker is significantly faster than BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is an unfortunate situation for users as few packagers take the effort to configure their builds to use `gold`. I think we should consider the following, > Introduce a configure flag (to both the source distribution, and the distributed binary distributions), `--enable-gold`. When enabled, `configure` will check for the functioning of `gcc -fuse-ld=gold`. If found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag would throw an error on non-ELF platforms (which are not supported by `gold`). While there is admittedly not a whole lot of precedent for this, the status quo means we are leaving a significant bit of compiler performance on the table in a majority of cases. Given that `stack` uses GHC's official bindists, we should try to improve this situation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:11:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:11:59 -0000 Subject: [GHC] #13518: CMM compiles with 8.0.2, fails with git HEAD In-Reply-To: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> References: <044.26a86e6e1e8d15d314e9ba14d4dd5f59@haskell.org> Message-ID: <059.91c24d0aa0d8f1f86d87a4d6518e6da2@haskell.org> #13518: CMM compiles with 8.0.2, fails with git HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > So how does one express a `Word32` in a portable way in CMM? There is no 32-bit integral primitive Haskell type anyways, so the problem never arises. The definition of the Haskell type `Word32` is {{{#!hs data Word32 = W32# Word# }}} where all but the low 32 bits of the `Word#` are expected to be zero. So that's the interface you have to program to, in Cmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:12:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:12:09 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.34f0d130868c9b1470708a3a25eaa997@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 bgamari: Old description: > As pointed out in #4862, the `gold` linker is significantly faster than > BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is > an unfortunate situation for users as few packagers take the effort to > configure their builds to use `gold`. > > I think we should consider the following, > > > Introduce a configure flag (to both the source distribution, and the > distributed binary distributions), `--enable-gold`. When enabled, > `configure` will check for the functioning of `gcc -fuse-ld=gold`. If > found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag > would throw an error on non-ELF platforms (which are not supported by > `gold`). > > While there is admittedly not a whole lot of precedent for this, the > status quo means we are leaving a significant bit of compiler performance > on the table in a majority of cases. Given that `stack` uses GHC's > official bindists, we should try to improve this situation. New description: As pointed out in #4862, the `gold` linker is significantly faster than BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is an unfortunate situation for users as few packagers take the effort to configure their builds to use `gold`. I think we should consider the following, > Introduce a configure flag (to both the source distribution, and the distributed binary distributions), `--enable-gold`. When enabled, `configure` will check for the functioning of `gcc -fuse-ld=gold`. If found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag would throw an error on non-ELF platforms (which are not supported by `gold`). While there is admittedly not a whole lot of precedent for this, the status quo means we are leaving a significant bit of compiler performance on the table in a majority of cases. Given that `stack` uses GHC's official bindists, we should try to improve this situation. In fact, I would even weakly suggest that we might consider enabling `--enable-gold` the default behavior, requiring the user to explicitly pass `--disable-gold` if they want the current behavior. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:12:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:12:23 -0000 Subject: [GHC] #4862: Enable usage of gold linker with GHC In-Reply-To: <042.3442092387d4ef4c250e40df3ea4af8a@haskell.org> References: <042.3442092387d4ef4c250e40df3ea4af8a@haskell.org> Message-ID: <057.3ccae62e40f6d3b54a77683a7a4fa63c@haskell.org> #4862: Enable usage of gold linker with GHC -------------------------------------+------------------------------------- Reporter: ajd | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 7.4.3 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #13541, which describes a proposal for making it easier to use `gold`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:30:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:30:25 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.29ea5e1e48793fcb68e08b384a40f44c@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Another unfortunate aspect of the status quo is that the user may think that passing `LD=gold` to `./configure` will configure the compiler to use `gold`, but they would be wrong. Another approach that may be would be to check whether `LD` is set to `gold` and if so check for a functional `-fuse-ld=gold`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 00:31:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 00:31:53 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.ca1c4c8b365385da2321f647df7c649f@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 bgamari: Old description: > As pointed out in #4862, the `gold` linker is significantly faster than > BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is > an unfortunate situation for users as few packagers take the effort to > configure their builds to use `gold`. > > I think we should consider the following, > > > Introduce a configure flag (to both the source distribution, and the > distributed binary distributions), `--enable-gold`. When enabled, > `configure` will check for the functioning of `gcc -fuse-ld=gold`. If > found to work `-fuse-ld=gold` would be added to GHC's `optl`. The flag > would throw an error on non-ELF platforms (which are not supported by > `gold`). > > While there is admittedly not a whole lot of precedent for this, the > status quo means we are leaving a significant bit of compiler performance > on the table in a majority of cases. Given that `stack` uses GHC's > official bindists, we should try to improve this situation. > > In fact, I would even weakly suggest that we might consider enabling > `--enable-gold` the default behavior, requiring the user to explicitly > pass `--disable-gold` if they want the current behavior. New description: As pointed out in #4862, the `gold` linker is significantly faster than BFD `ld`. Currently we use whatever linker `gcc` uses by default. This is an unfortunate situation for users as few packagers take the effort to configure their builds to use `gold`. I think we should consider the following, > Introduce a configure flag (to both the source distribution, and the distributed binary distributions), `--enable-gold`. When enabled, `configure` will check for the functioning of `gcc -fuse-ld=gold`. If found to work `-fuse-ld=gold` would be added to GHC's `optlc`. The flag would throw an error on non-ELF platforms (which are not supported by `gold`). While there is admittedly not a whole lot of precedent for this, the status quo means we are leaving a significant bit of compiler performance on the table in a majority of cases. Given that `stack` uses GHC's official bindists, we should try to improve this situation. In fact, I would even weakly suggest that we might consider enabling `--enable-gold` the default behavior, requiring the user to explicitly pass `--disable-gold` if they want the current behavior. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 01:12:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 01:12:44 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.c2763db19586332a4fa4086ab38f9436@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > What is stopping these libraries from providing this mechanism currently using Addr# and primitive strings directly? The problem is that there's no way to cast `Addr#` into `ByteArray#` without copy, while unboxed vector(not storable) and text both want `ByteArray#`. > In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. I disagree. If we give string literal a proper compact representation, not only we cab save unnecessary copying during runtime, we can save code size in other ways. Consider if string literal now are `ByteArray#`s, we can use rules to simplify a UTF8 text type like `forall a. fromString (GHC.unpackCString# a) = UTF8 a`, that means we can directly use constructor here instead of several calls. The same applys for unbox vectors using unboxed string literal and hexdecimal notation, which we have to use `fromList` and a real list now(which carrys a much larger overhead). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 01:13:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 01:13:57 -0000 Subject: [GHC] #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build In-Reply-To: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> References: <050.e3cfd2d39c95cff5f3626e61675da9d4@haskell.org> Message-ID: <065.4dc90f21252eb9127ec72913632cff39@haskell.org> #13534: ghc-8.2.0.20170404/testsuite/timeout failed to build --------------------------------+-------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: timeout Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3318 Wiki Page: | --------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I believe this should be fixed by 7cd919f4af0ad05f89391616d940268fb71cb65e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 01:20:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 01:20:05 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.51e65e34a268dd4e44e2dd86d79cf329@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:60 winter]: > > What is stopping these libraries from providing this mechanism currently using Addr# and primitive strings directly? > > The problem is that there's no way to cast `Addr#` into `ByteArray#` without copy, while unboxed vector(not storable) and text both want `ByteArray#`. > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. > > In general primitive strings are, as the name would suggest, primitive. I'm not sure forcing a heap object representation here is necessary nor prudent. > > I disagree. If we give string literal a proper compact representation, not only we can save unnecessary copying during runtime, we can save code size in other ways. > > Consider if string literal now are `ByteArray#`s, we can use rules to simplify a UTF8 text type like `forall a. fromString (GHC.unpackCString# a) = UTF8 a`, that means we can directly use constructor here instead of several calls. The same applys for unbox vectors using unboxed string literal and hexdecimal notation. I agree that these are all great simplifications, but I don't see why changing the representation of primitive strings is necessary to get there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 01:30:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 01:30:43 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.123c6fe4bcf72ddcbc123669845b8c70@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. Although, thinking about this for a tad longer it's not necessarily clear that this is a direction which we'd want to go. Afterall, it would require the introduction of another closure type since the current representation requires that the bytes directly follow the closure header. I suspect this would introduce quite a bit of complexity in the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 01:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 01:36:31 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.66f558dbd0cba7090cdd5da5d37eb3fc@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 angerman): A few things to note: - gold, does ELF only. So this should only be available and enabled if we are targeting elf. - I'd also suggest that this is only enabled by default if gcc is used. If clang is used or gcc /is/ clang, don't enable gold. I still believe that this kind of configuration should be part of the toolchain and not part of ghc though. I'm also a bit confused why gcc would not respect the LD env var. Maybe someone with better knowledge of the gcc toolchain knows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 02:43:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 02:43:14 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.29dcb0d6b5002bbfe63e05afa8e9fd3e@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > Fair enough, but why not just poke a hole in the `ByteArray#` abstraction in that case? Namely, provide a `unsafeMkByteArray# :: Addr# -> Int -> ByteArray#`. > Although, thinking about this for a tad longer it's not necessarily clear that this is a direction which we'd want to go. Afterall, it would require the introduction of another closure type since the current representation requires that the bytes directly follow the closure header. I suspect this would introduce quite a bit of complexity in the RTS. Yes, that is a more expensive design IMO. I read about the notes on unpointed heap object(maybe somewhere in `infoTable.h`), it says that they shouldn't be entered. But i fail to understand how can we provide `unsafeMkByteArray#` in an obvious way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 03:33:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 03:33:58 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.612ac16a8816bfff1d07900304dc1e04@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 thoughtpolice): Gold works perfectly fine with Clang on Linux. Why block that combination? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 04:31:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 04:31:54 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.1b378d8280064766361c2ff00012bddb@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > But i fail to understand how can we provide `unsafeMkByteArray#` in an obvious way. This would essentially amount to making `ByteArray#` a sum internally. You would simply add a closure type which would carry a pointer to the payload instead of the VLA carried by `StgArrBytes` currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 05:49:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 05:49:18 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.ab86d8bc942bbbc27df03b446b8ef386@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 angerman): I might have gone a bit overboard here. I'm not sure if this ticket is related to https://phabricator.haskell.org/D3351, however clang doesn't understand `-fuse-ld` (at least not the one that comes with the android toolchain, not sure if this statement holds universally), and thus forcing that flag results in a non-functioning compiler. I certainly don't want to block anything. I just don't want to have anything forced on me by default, which might run counter to my toolchain configuration. In my view this should be part of the toolchain, and ghc should ensure to pick up the configuration from the toolchain proper instead of doing the decision on its own. I guess a similar case could be made for using lld? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 06:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 06:17:54 -0000 Subject: [GHC] #13538: Weird kind inference problems with closed type families In-Reply-To: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> References: <047.b22f0f1e045aeed1406b955511305b41@haskell.org> Message-ID: <062.5a82a34bca1fb575965a297fdb21605a@haskell.org> #13538: Weird kind inference problems with closed type families -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #13135 | Differential Rev(s): Phab:D3426 Wiki Page: | -------------------------------------+------------------------------------- Comment (by achirkin): Wow, bugs getting fixed before users submit them these days. That's efficient! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 06:24:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 06:24:07 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.ee8409bf80e63ba74f1746f59d7c5042@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): > This would essentially amount to making `ByteArray#` a sum internally. You would simply add a closure type which would carry a pointer to the payload instead of the VLA carried by `StgArrBytes` currently. I'm not an expert on this, so maybe this sounds ridiculous: If we add a new closure type for `ByteArray#`, could it be used in runtime also? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 06:59:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 06:59:22 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.e9dea0733ff0aa94dd1b1fabbbcceb0a@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: I'm re-opening because we have not closed the discussion I opened in comment:19. We discussed it on Tuesday and Reid was going to try forcing the type on the way ''out'' of `SimplCont` rather than on the way ''in''. OK, Reid? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 07:06:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 07:06:55 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.ab0be0bfc2a38fadae40f08ccfdc15e0@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes. It's really {{{ case e of w { p1 -> w; ...; pn -> w } ===> e }}} (Core has a more general version involving strictness on `x`.) I don't know how much it happens in practice. It would not be hard to include this in `StgCse` though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 09:33:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 09:33:17 -0000 Subject: [GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail In-Reply-To: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> References: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> Message-ID: <066.93a7ee1c94beef775626385931ece083@haskell.org> #13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | 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 Iceland_jack): * status: new => closed * resolution: => invalid Comment: Replying to [comment:2 simonpj]: > Now you want to force the type of the pattern to be `_`. But since GHC only supports predicative polymorphism, `_` must be a monotype. So GHC instantiates `forall a. a->a` to `alpha -> alpha` (for some new unification variable alpha), and proceeds. I suspected this was related to impredicativity. As a user I expected transforming the pattern `m` to `(m :: _)` would have no effect since it binds nothing (the compiler ''could'' special-case it, even though it brings no benefits). > Does that help? > > Is there some way we could improve the user manual? Yes it helps. I think the impredicative polymorphism entry is rather good, thanks for the explanation. To be clear, this is also expected? Closing the ticket {{{#!hs -- Works tId :: T -> T tId (MkT g) = MkT g -- Fails tId :: T -> T tId (MkT g) = MkT g' where g' = g }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 10:30:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 10:30:20 -0000 Subject: [GHC] #13542: Solaris build fails with collect2: execv: Arg list too long Message-ID: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> #13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Solaris Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It looks like HEAD build is broken on Solaris and Solaris-derived OSes. It fails with: {{{ gmake --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries /ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o -dyno libraries/ghc-prim/dist- install/build/GHC/Types.dyn_o gcc: error trying to exec '/usr/gcc/4.8/lib/gcc/i386-pc- solaris2.11/4.8.2/collect2': execv: Arg list too long `gcc' failed in phase `Linker'. (Exit code: 1) gmake[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 gmake: *** [all] Error 2 }}} on Solaris 11.2 and with: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries /ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o -dyno libraries/ghc-prim/dist- install/build/GHC/Types.dyn_o gcc: error trying to exec '/opt/local/gcc47/libexec/gcc/i486-sun- solaris2.11/4.7.4/collect2': execv: Arg list too long `gcc' failed in phase `Linker'. (Exit code: 1) libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/Types.o' failed gmake[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 Makefile:122: recipe for target 'all' failed gmake: *** [all] Error 2 }}} on SmartOS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 10:40:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 10:40:04 -0000 Subject: [GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail In-Reply-To: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> References: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> Message-ID: <066.7df9bde318b6d567fbfa471f0ff2f27d@haskell.org> #13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > To be clear, this is also expected? Yes, but for an entirely different reason. The local binding `g' = g` is not generalised, because with `GADTs` on (which you presumably have) we have `MonoLocalBinds` on too. So `g'` is no generalised; and hence it's rejected as an argumen to `MkT`. If you gave `g'` a type signature you'd be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 10:40:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 10:40:32 -0000 Subject: [GHC] #13542: Solaris build fails with collect2: execv: Arg list too long In-Reply-To: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> References: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> Message-ID: <061.a6ff108871ce2d91decd00b93ec3f13d@haskell.org> #13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kgardas): This issue first appear on Feb 19 2017 build on SmartOS builder: http://haskell.inf.elte.hu/builders/smartos-x86_64-head/index.html -- the last working build was from Feb 18 2017. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 12:33:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 12:33:19 -0000 Subject: [GHC] #13543: Improve demand analysis for join points Message-ID: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> #13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 {{{ g :: (Int,Int) -> Int g (p,q) = p+q f :: Int -> Int -> Int f x p = g (join j y = (p,y) in case x of True -> j 3 False -> j 4) }}} If `j` was a vanilla function definition, we'd analyse its body with `evalDmd`, and think that it was lazy in `p`. But for a join point we can do better. We know that `j`'s body (if evaluated at all) will be evaluated with the demand that consumes the entire join-binding, in this case the argument demand from `g`. Whizzo! `g` evaluates both components of its arugment pair, so j is strict in `p`. So, when analysing a join point, we can analyse its body with the demand from the entire join-binding. Another win for join points! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 12:33:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 12:33:28 -0000 Subject: [GHC] #13543: Improve demand analysis for join points In-Reply-To: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> References: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> Message-ID: <061.8ce7f93f863623c1a95439d2f57fd17a@haskell.org> #13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 12:44:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 12:44:05 -0000 Subject: [GHC] #13537: Adding underscore (m :: _) to pattern variable makes it fail In-Reply-To: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> References: <051.b4c1274c812af06c5193497e7c2cd990@haskell.org> Message-ID: <066.967f5a14f6c0a0d629329691f6a93ff9@haskell.org> #13537: Adding underscore (m :: _) to pattern variable makes it fail -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thank you, consider this answered. ---- I was reifying `(forall ty. STy ty -> r) -> r` from [https://github.com/goldfirere/glambda/blob/ex3/src/Language/Glambda/Type.hs#L72 Richard's Glambda] {{{#!hs refineTy :: Ty -> (forall ty. STy ty -> r) -> r refineTy (ty1 `Arr` ty2) k = refineTy ty1 $ \sty1 -> refineTy ty2 $ \sty2 -> k (sty1 `SArr` sty2) refineTy IntTy k = k SIntTy refineTy BoolTy k = k SBoolTy }}} If this were a regular continuation / codensity monad we could rewrite it to {{{#!hs refineTy = \case Arr a b -> liftA2 SArr (refine a) (refine b) IntTy -> pure SIntTy BoolTy -> pure SBoolTy }}} but it seems to be a functor from a ''functor'' category, so I'm trying to figure out where it fits in the hierarchy. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 12:50:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 12:50:49 -0000 Subject: [GHC] #13542: Solaris build fails with collect2: execv: Arg list too long In-Reply-To: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> References: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> Message-ID: <061.5413b664525ae9efd2abf063dcdf34f0@haskell.org> #13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The builder shows that 89168849a781626fc794ae97375da979ac83bf96 succeeded but 98e494afed3c73f88ff1d57a9ca46b1f6ddbd1b9 failed (clicking through to "8: configuring" shows the commit id). The likely culprit in that range is Type-indexed Typeable 8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497 which produces many more top- level bindings, which in conjunction with `-split-objs` means many more object files to be passed to the linker. I guess it hit a limit in Solaris. I wonder whether we can simply use `-split-sections` on Solaris? It's generally preferable to `-split-objs` and won't produce long command lines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 15:19:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 15:19:31 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.640bd0e49fb18b99ef3bb41fb0009120@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To be clear, I don't think there is any need to block any particular combinations. We simply teach configure to check that `-fuse-ld=gold` works. If the compiler doesn't support it then the check fails and we either throw an error or proceed with the status quo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 15:23:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 15:23:52 -0000 Subject: [GHC] #13468: GHC stubbornly produces dead code for empty case with type family In-Reply-To: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> References: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> Message-ID: <060.b6e665291e7f7cabc6cdbb1caf8ea338@haskell.org> #13468: GHC stubbornly produces dead code for empty case with type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f0d98fc6cdde26bf43a04d9f01b6ad2f4c88f0b9/ghc" f0d98fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0d98fc6cdde26bf43a04d9f01b6ad2f4c88f0b9" Do Note [Improving seq] always This patch fixes Trac #13468, and at the same time makes the code simpler and more uniform. In particular, I've eliminated the awkward conflict between the old built-in rule for seq (which elimianted a cast), and the desire to make case scrutinse a data type by doing type-family reduction (which adds a cast). Nice. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 15:44:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 15:44:17 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.30f1fa8fb0d6c212099faa9b609a65e5@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Comment (by rwbarton): I think that is what I've done in the final version of Phab:D3421. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 15:49:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 15:49:58 -0000 Subject: [GHC] #13468: GHC stubbornly produces dead code for empty case with type family In-Reply-To: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> References: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> Message-ID: <060.863be788f94be5c0205121fc0bff14fe@haskell.org> #13468: GHC stubbornly produces dead code for empty case with type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | simplCore/should_compile/T13468 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T13468 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 15:58:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 15:58:33 -0000 Subject: [GHC] #13520: instance Alternative ZipList In-Reply-To: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> References: <051.ade73762bd77e460afc15a70ff0475f0@haskell.org> Message-ID: <066.f365862d011d8fe6c517e83688fa6a51@haskell.org> #13520: instance Alternative ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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): Phab:D3416 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Cale from `#haskell` points out the following: {{{ Iceland_jack: I think it probably ought to be the one which uses Semigroup's (<>) to combine corresponding elements. Iceland_jack: Then you can recover the instance there by using the First semigroup }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:03:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:03:26 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.d9b3ac68aa98a5b64a39afb5483ca296@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Ah yes, I wasn't looking hard enough. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:07:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:07:32 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.abd7ca803fb8256fa3f3b1b042f145a3@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > But it's simpler and more direct simply to propagate the "apply to 1 arg" info that we apply to the body of g directly into the RHS of j. Completely ignore the occurrences of j, don't compute their join arity. I thought about it a bit. This should yield precisely the same analysis result, right? (In particular, when analyzing a join point `j`, then the incoming arity of `j` should always be the incoming arity of the whole `join j = … in …`, plus the arity of `j` itself, so once we are past the lambdas on the RHS of the `j`, we have – as you say – the same informatin. Furthermore, the join point is called once.). So adding this code would (potentially) cut some corners, but it adds complexity to the code without any gain in precision. So unless this there is a compiler performance bottle neck to be fixed, that does not seem to really be a good trade off, does it? (We could omit setting the call arity on join points, or – as now – ignoring it in the simplifier. Doesn’t seem to make a big difference either way.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:21:17 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.2c67661655e018a35fce65eb0d1e09b4@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that's true. I'm not certain about the Rec case though. Conceivably the direct approach might do better? Maybe not, I'm not sure. Doing it directly just seems a bit more ... direct. But I don't feel strongly. A Note at least? Regardless I certainly think it'd be better not to set a call-arity on a join point, instead of messing about in the simplifier (which is really innocent). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:24:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:24:54 -0000 Subject: [GHC] #13544: ghc panic Message-ID: <049.003cc75f06a3e12668c7d236344a70cf@haskell.org> #13544: ghc panic -------------------------------------+------------------------------------- Reporter: shauryab98 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] %_a1El :: t_a1Ek[tau:1] (CHoleCan: %)} }}} while compiling the following code {{{#!hs halveEvens :: [Integer] -> [Integer] halveEvens = map . filter (\c -> c%2 == 0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:27:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:27:28 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.592b12fcfdf65c9cf27f95bfdd444dbc@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > But I don't feel strongly. A Note at least? Me neither. Direct is nice, less code is nice. I’ll add a note, and not set the call arity annotation. (Although it is debatable whether the simplifier is really innocent. The annotation is *true* even on join points; it is the simplifier that is stubbornly (but with good reason) refusing to eta-expand the join point!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:28:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:28:23 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.541d5634a79257a1cdc1aeab98b4705b@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: (none) => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 16:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 16:31:19 -0000 Subject: [GHC] #13544: ghc panic In-Reply-To: <049.003cc75f06a3e12668c7d236344a70cf@haskell.org> References: <049.003cc75f06a3e12668c7d236344a70cf@haskell.org> Message-ID: <064.618e8ddbc5842da9d394553c9a373ea4@haskell.org> #13544: ghc panic -------------------------------------+------------------------------------- Reporter: shauryab98 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Works in HEAD and 8.2.1 RC. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 18:28:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 18:28:42 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.095872e9a1ff6344631f0352fcdad8fd@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 18:43:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 18:43:58 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild Message-ID: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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: -------------------------------------+------------------------------------- `lookupSubBndrOcc` is used in expressions such as `x { y = 5 }` to resolve field labels such as `y`. `lookupExportChild` is used in export lists such as `T(A, x)` to lookup `A` and `x`. They contain very similar logic but it is duplicated in two places which caused #13528. It should be easy to refactor them them to deduplicate the logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 21:16:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 21:16:40 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.4aece6618cca24981ee7c84c990bbc0f@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): [[https://stackoverflow.com/questions/43243322/how-to-link-with-the-gnu- gold-linker-instead-of-ld-in-haskell/43243323#43243323|Apparently]] `lld` is another factor of three faster than `gold`, so I suppose if we want to go this route we should ensure the solution will extend to that case as well. I'd love to hear others opinions on this general direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 21:26:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 21:26:41 -0000 Subject: [GHC] #13546: Kind error with type equality Message-ID: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- This code {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} import Data.Kind data Dict c where Dict :: c => Dict c data T (t :: k) type family UnT (a :: Type) :: k where UnT (T t) = t untt :: Dict (UnT (T "a") ~ "a") untt = Dict tunt :: Dict (T (UnT (T "a")) ~ T "a") tunt = Dict }}} fails with this error: {{{ tunt.hs:17:8: error: • Couldn't match kind ‘k’ with ‘GHC.Types.Symbol’ ‘k’ is a rigid type variable bound by the type signature for: tunt :: forall k. Dict T (UnT (T "a")) ~ T "a" at tunt.hs:16:1-38 When matching types UnT (T "a") :: k "a" :: GHC.Types.Symbol • In the expression: Dict In an equation for ‘tunt’: tunt = Dict • Relevant bindings include tunt :: Dict T (UnT (T "a")) ~ T "a" (bound at tunt.hs:17:1) | 17 | tunt = Dict | }}} Instead I would expect these reductions to take place: {{{ 1. T (UnT (T "a")) ~ T "a" 2. T "a" ~ T "a" 3. constraint satisfied (refl) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 21:34:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 21:34:35 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.98b8e50a6c6f062dde52646839f83d02@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glguy): I'd like to share my usecase for wanting this feature Given the following type: {{{#!haskell -- | Family of N-ary operator types. type family Op n a b where Op 'Z a b = b Op ('S n) a b = a -> Op n a b }}} I'd love to be able to {{{#!haskell coerce :: Coercible a b => Op n a c -> Op n b c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 21:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 21:44:14 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.d9cc154c84c8ea7420e85a1b84996863@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I want this feature too. My use case is this: {{{#!hs data family EffDict (eff :: k) (m :: Type -> Type) }}} this data family represents effect methods for some monad `m`. Its data instances match on `eff` only, never on `m`. For example: {{{#!hs data StateEff s data instance EffDict (StateEff s) m = StateDict { _state :: forall a . (s -> (a,s)) -> m a, _get :: m s, _put :: s -> m () } }}} Define a composition of monad transformers as follows: {{{#!hs newtype TComp t1 t2 m a = TComp (t1 (t2 m) a) }}} Then I want to be able to do this: {{{#!hs coerce :: Dict eff (t1 (t2 m)) -> Dict eff (TComp t1 t2 m) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 7 21:44:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Apr 2017 21:44:36 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.cc30e376054cf95d0b31fc876bf49e97@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 08:21:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 08:21:35 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found Message-ID: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: 10158 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building with `stack build --resolver lts-7.20` and `stack build --resolver lts-8.8`, i.e. with ghc-8.0.1 and ghc-8.0.2 and {{{ [37 of 60] Compiling Document.Phase.Proofs ( src/Document/Phase/Proofs.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): StgCmmEnv: variable not found $dTypeable_aZSM local binds for: $sunionWith_$sunionWithKey $sfromList1 $sfromList3 $sfromList $s$fOrdEither $s$fMonadReaderrReaderT $s$fIsTupleconstrIdentity $s$fIsTupleconstr(,,,,) $s$fIsTupleconstr(,,,) $s$fIsTupleconstr(,,) $s$fIsTupleconstr(,,)2 $s$fIsTupleconstr(,)1 $s$fIsTupleconstr(,) $s$fIsTupleconstr(,)2 $s$fHasMachineP2p $fNFDataEventRefA $fMonoidEventRefA $fGenericEventRefA $wmake_phase4 make_phase1 $wpoly_go10 make_phase2 make_phase3 make_phase5 $fNFDataEventRefA4 $fNFDataEventRefA2 $stypeRep#78 $swithCommand8 $stypeRep#54 $swithCommand5 $stypeRep#11 $swithCommand2 $stypeRep#74 $stypeRep#81 $stypeRep#15 $stypeRep#20 $stypeRep#79 $stypeRep#80 $stypeRep#70 $stypeRep#75 $stypeRep#58 $stypeRep#66 $stypeRep#71 $stypeRep#62 $stypeRep#8 $stypeRep#67 $stypeRep#63 $stypeRep#59 $stypeRep#50 $stypeRep#55 $stypeRep#38 $stypeRep#46 $stypeRep#51 $stypeRep#42 $stypeRep#47 $stypeRep#43 $stypeRep#34 $stypeRep#39 $stypeRep#31 $stypeRep#35 $stypeRep#28 $stypeRep#24 $stypeRep#25 $stypeRep#21 $stypeRep#3 $stypeRep#16 $stypeRep#7 $stypeRep#12 $stypeRep#2 $smakeCell8 $smakeCell7 $smakeCell40 $smakeCell39 $smakeCell36 $smakeCell35 $smakeCell32 $smakeCell31 $smakeCell4 $smakeCell28 $smakeCell27 $smakeCell24 $smakeCell23 $smakeCell3 $smakeCell20 $smakeCell19 $smakeCell16 $smakeCell15 $smakeCell12 $smakeCell11 $wpoly_go5 $wgo5 $sfromList_go5 $wpoly_go2 $sfromList2 $s$fOrd(,) $sfromList_fromList'1 $wpoly_go1 $s$fEqEither $s$fOrdEither_$s$fOrdEither_$cp1Ord $s$fEq(,) $s$fOrd(,)_$s$fOrd(,)_$cp1Ord $s$fMonadRWST $s$fMonadReaderrReaderT1 $s$fMonadReaderT $s$fApplicativeReaderT $s$fMonadReaderT_$s$fMonadReaderT_$cfail $s$fMonadReaderT_$s$fMonadReaderT_$c>> $s$fMonadReaderT_$s$fMonadReaderT_$c>>= $s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad $s$fMonadRWST_$s$fMonadRWST_$cfail $s$fMonadRWST_$s$fMonadRWST_$c>> $s$fMonadRWST_$s$fMonadRWST_$c>>= $s$fMonadRWST_$s$fMonadRWST_$cp1Monad $s$fIsTupleconstr(,,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,,)1 $s$fIsTupleconstr(,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,)_irred2 $s$fIsTupleconstr(,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,)_$dLatexArgFromString $s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc $s$fIsTupleconstr(,,)_irred1 $s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty $s$fIsTupleconstr(,,)1 $s$fIsTupleconstr(,)3 $s$fHasMachineP1p $s$fHasMachineP2p1 $s$fHasMachineP2p2 $s$fHasMachineP2p3 $s$fHasMachineP2p4 $s$fHasMachineP2p5 $s$fHasMachineP2p6 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1 $s$fEq(,)_$dEq1 $s$fEq(,)_$dEq $s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$ $s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap $s$fApplicativeReaderT_$s$fFunctorReaderT $s$fApplicativeRWST $s$fApplicativeReaderT_$dApplicative $s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*> $s$fApplicativeReaderT_$s$fMonadReaderT_$creturn $s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative $s$fApplicativeRWST_$dFunctor $s$fApplicativeRWST_$s$fApplicativeRWST_$c<*> $s$fApplicativeRWST_$s$fApplicativeRWST_$cpure $s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative $fNFDataEventRefA1 $fNFDataEventRefA3 $w$dNFData2 $w$dNFData1 $w$dNFData $fNFDataEventRefA_$crnf $wgo $fMonoidEventRefA_$cmconcat $fMonoidEventRefA_$cmappend $fMonoidEventRefA_$cmempty $fGenericEventRefA_$cto $fGenericEventRefA_$cfrom make_phase4 ruleProxies_rSKY refinement_parser_rSL2 $w$smiddle $w$sgreater $sfilterGt1 $sfilterLt1 $sinsert_$sgo10 $sinsert_$sgo5 $sleadsTo1 $wpoly_go3 $wpoly_go4 $slookup5 $slookup7 $smakeCell2 $smakeCell6 $smakeCell10 $smakeCell14 $smakeCell18 $smakeCell22 $smakeCell26 $smakeCell30 $smakeCell34 $smakeCell38 $wpoly_go6 $wpoly_go7 $wpoly_go8 $sshowStringP1 $strim1 $strim3 $sunions1 $sunless_eta $swithCommand1 $swithCommand4 $swithCommand7 lvl_r2714 lvl1_r2715 go_r2716 $wgo1_r2717 lvl2_r2718 lvl3_r2719 lvl4_r271a lvl5_r271b lvl6_r271c lvl7_r271d lvl8_r271e lvl9_r271f lvl10_r271g lvl11_r271h lvl12_r271i lvl13_r271j lvl14_r271k lvl15_r271l lvl16_r271m lvl17_r271n lvl18_r271o lvl19_r271p lvl20_r271q lvl21_r271r lvl22_r271s lvl23_r271t lvl24_r271u lvl25_r271v lvl26_r271w lvl27_r271x lvl28_r271y lvl29_r271z lvl30_r271A lvl31_r271B lvl32_r271C lvl33_r271D lvl34_r271E lvl35_r271F lvl36_r271G lvl37_r271H lvl38_r271I lvl39_r271J lvl40_r271K lvl49_r2723 lvl50_r2724 lvl51_r2725 lvl52_r2726 lvl53_r2727 lvl54_r2728 lvl55_r2729 lvl56_r272a lvl57_r272b lvl58_r272c lvl59_r272d lvl60_r272e lvl61_r272f lvl62_r272g lvl63_r272h lvl64_r272i lvl65_r272j lvl66_r272k lvl67_r272l lvl68_r272m lvl69_r272n lvl70_r272o lvl71_r272p lvl72_r272q $s$fApplicativeRWST_$c<*>_r272u $s$fApplicativeRWST_$cpure_r272v lvl74_r272w lvl75_r272x lvl76_r272y $s$fMonadRWST_$c>>_r272z $s$fMonadRWST_$cfail_r272A $s$fMonadRWST_$c>>=_r272B lvl77_r272C lvl78_r272D lvl79_r272E lvl80_r272F lvl81_r272G lvl82_r272H $slesser1_r272S lvl88_r272T lvl89_r272U $wcreate_r272V lvl90_r272W m2_r272X $s$fMonadReaderT_$c>>_r272Y $s$fMonadReaderT_$c>>=_r272Z go10_r2730 $wpoly_create_r2731 lvl91_r2732 lvl92_r2733 lvl93_r2734 lvl94_r2735 lvl95_r2736 lvl96_r2737 lvl97_r2738 lvl98_r2739 lvl99_r273a lvl100_r273b lvl101_r273c lvl102_r273d lvl103_r273e lvl104_r273f lvl105_r273g lvl106_r273h lvl107_r273i lvl108_r273j lvl109_r273k lvl110_r273l lvl111_r273m lvl112_r273n lvl113_r273o lvl114_r273p lvl115_r273q lvl116_r273r lvl117_r273s lvl118_r273t lvl119_r273u lvl120_r273v lvl121_r273w lvl122_r273x lvl123_r273y lvl124_r273z $wpoly_create1_r273A lvl125_r273B lvl126_r273C lvl127_r273D lvl128_r273E lvl129_r273F lvl130_r273G lvl131_r273H lvl132_r273I lvl133_r273J lvl134_r273K lvl135_r273L $wlvl_r273M lvl136_r273N $wlvl1_r273O lvl137_r273P $wlvl2_r273Q lvl138_r273R $wlvl3_r273S lvl139_r273T $wlvl4_r273U lvl140_r273V $wlvl5_r273W lvl141_r273X $wlvl6_r273Y lvl142_r273Z lvl143_r2740 lvl144_r2741 lvl145_r2742 lvl146_r2743 lvl147_r2744 lvl148_r2745 lvl149_r2746 lvl150_r2747 lvl151_r2748 lvl152_r2749 lvl153_r274a lvl154_r274b $s$fFunctorReaderT_$cfmap_r274c $s$fFunctorReaderT_$c<$_r274d lvl155_r274e lvl156_r274f $s$fApplicativeReaderT_$c<*>_r274g $s$fMonadReaderT_$creturn_r274h $s$fMonadReaderT_$cfail_r274i lvl157_r274j lvl158_r274k lvl159_r274l lvl160_r274m $d~_r274n lvl161_r274p lvl162_r274q lvl163_r274s lvl164_r274t lvl165_r274v lvl166_r274w lvl167_r274y lvl168_r274z lvl169_r274B lvl170_r274C lvl171_r274E lvl172_r274F lvl173_r274H lvl174_r274I lvl175_r274K lvl176_r274L lvl177_r274N lvl178_r274O lvl179_r274Q lvl180_r274R lvl181_r274T lvl182_r274U lvl183_r274V lvl184_r274W lvl185_r274X lvl186_r274Y lvl187_r274Z lvl188_r2750 lvl189_r2751 lvl190_r2752 lvl191_r2753 lvl192_r2754 lvl193_r2755 lvl194_r2756 lvl195_r2757 lvl196_r2758 lvl197_r2759 lvl198_r275a lvl199_r275b lvl200_r275c lvl201_r275d lvl202_r275e lvl203_r275f lvl204_r275g lvl205_r275h lvl206_r275i lvl207_r275j lvl208_r275k lvl209_r275l lvl210_r275m lvl211_r275n lvl212_r275o lvl213_r275p lvl214_r275q lvl215_r275r lvl216_r275s lvl217_r275t lvl218_r275u lvl219_r275v lvl220_r275w ww1_r275x ww2_r275y lvl221_r275z ww3_r275A lvl222_r275B pre_r275C x_s27MP eta_s27MQ eta1_s27MR ds_s27MS ds1_s27MT ds2_s27MU ds3_s27MV goal_s27MW prxy'_s27MX sat_s27MY 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 Sat Apr 8 08:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 08:28:11 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.b83a153d099ada573dd80a8d692785cf@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by cipher1024: Old description: > When building with `stack build --resolver lts-7.20` and `stack build > --resolver lts-8.8`, i.e. with > > ghc-8.0.1 and > ghc-8.0.2 and > > {{{ > [37 of 60] Compiling Document.Phase.Proofs ( > src/Document/Phase/Proofs.hs, .stack- > work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o ) > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.1 for x86_64-apple-darwin): > StgCmmEnv: variable not found > $dTypeable_aZSM > local binds for: > $sunionWith_$sunionWithKey > $sfromList1 > $sfromList3 > $sfromList > $s$fOrdEither > $s$fMonadReaderrReaderT > $s$fIsTupleconstrIdentity > $s$fIsTupleconstr(,,,,) > $s$fIsTupleconstr(,,,) > $s$fIsTupleconstr(,,) > $s$fIsTupleconstr(,,)2 > $s$fIsTupleconstr(,)1 > $s$fIsTupleconstr(,) > $s$fIsTupleconstr(,)2 > $s$fHasMachineP2p > $fNFDataEventRefA > $fMonoidEventRefA > $fGenericEventRefA > $wmake_phase4 > make_phase1 > $wpoly_go10 > make_phase2 > make_phase3 > make_phase5 > $fNFDataEventRefA4 > $fNFDataEventRefA2 > $stypeRep#78 > $swithCommand8 > $stypeRep#54 > $swithCommand5 > $stypeRep#11 > $swithCommand2 > $stypeRep#74 > $stypeRep#81 > $stypeRep#15 > $stypeRep#20 > $stypeRep#79 > $stypeRep#80 > $stypeRep#70 > $stypeRep#75 > $stypeRep#58 > $stypeRep#66 > $stypeRep#71 > $stypeRep#62 > $stypeRep#8 > $stypeRep#67 > $stypeRep#63 > $stypeRep#59 > $stypeRep#50 > $stypeRep#55 > $stypeRep#38 > $stypeRep#46 > $stypeRep#51 > $stypeRep#42 > $stypeRep#47 > $stypeRep#43 > $stypeRep#34 > $stypeRep#39 > $stypeRep#31 > $stypeRep#35 > $stypeRep#28 > $stypeRep#24 > $stypeRep#25 > $stypeRep#21 > $stypeRep#3 > $stypeRep#16 > $stypeRep#7 > $stypeRep#12 > $stypeRep#2 > $smakeCell8 > $smakeCell7 > $smakeCell40 > $smakeCell39 > $smakeCell36 > $smakeCell35 > $smakeCell32 > $smakeCell31 > $smakeCell4 > $smakeCell28 > $smakeCell27 > $smakeCell24 > $smakeCell23 > $smakeCell3 > $smakeCell20 > $smakeCell19 > $smakeCell16 > $smakeCell15 > $smakeCell12 > $smakeCell11 > $wpoly_go5 > $wgo5 > $sfromList_go5 > $wpoly_go2 > $sfromList2 > $s$fOrd(,) > $sfromList_fromList'1 > $wpoly_go1 > $s$fEqEither > $s$fOrdEither_$s$fOrdEither_$cp1Ord > $s$fEq(,) > $s$fOrd(,)_$s$fOrd(,)_$cp1Ord > $s$fMonadRWST > $s$fMonadReaderrReaderT1 > $s$fMonadReaderT > $s$fApplicativeReaderT > $s$fMonadReaderT_$s$fMonadReaderT_$cfail > $s$fMonadReaderT_$s$fMonadReaderT_$c>> > $s$fMonadReaderT_$s$fMonadReaderT_$c>>= > $s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad > $s$fMonadRWST_$s$fMonadRWST_$cfail > $s$fMonadRWST_$s$fMonadRWST_$c>> > $s$fMonadRWST_$s$fMonadRWST_$c>>= > $s$fMonadRWST_$s$fMonadRWST_$cp1Monad > $s$fIsTupleconstr(,,,,)_$s$fLatexArg[] > $s$fIsTupleconstr(,,,,)1 > $s$fIsTupleconstr(,,,)_$s$fLatexArg[] > $s$fIsTupleconstr(,,,)_irred2 > $s$fIsTupleconstr(,,)_$s$fLatexArg[] > $s$fIsTupleconstr(,,)_$dLatexArgFromString > $s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc > $s$fIsTupleconstr(,,)_irred1 > $s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty > $s$fIsTupleconstr(,,)1 > $s$fIsTupleconstr(,)3 > $s$fHasMachineP1p > $s$fHasMachineP2p1 > $s$fHasMachineP2p2 > $s$fHasMachineP2p3 > $s$fHasMachineP2p4 > $s$fHasMachineP2p5 > $s$fHasMachineP2p6 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1 > $s$fEq(,)_$dEq1 > $s$fEq(,)_$dEq > $s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$ > $s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap > $s$fApplicativeReaderT_$s$fFunctorReaderT > $s$fApplicativeRWST > $s$fApplicativeReaderT_$dApplicative > $s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*> > $s$fApplicativeReaderT_$s$fMonadReaderT_$creturn > $s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative > $s$fApplicativeRWST_$dFunctor > $s$fApplicativeRWST_$s$fApplicativeRWST_$c<*> > $s$fApplicativeRWST_$s$fApplicativeRWST_$cpure > $s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative > $fNFDataEventRefA1 > $fNFDataEventRefA3 > $w$dNFData2 > $w$dNFData1 > $w$dNFData > $fNFDataEventRefA_$crnf > $wgo > $fMonoidEventRefA_$cmconcat > $fMonoidEventRefA_$cmappend > $fMonoidEventRefA_$cmempty > $fGenericEventRefA_$cto > $fGenericEventRefA_$cfrom > make_phase4 > ruleProxies_rSKY > refinement_parser_rSL2 > $w$smiddle > $w$sgreater > $sfilterGt1 > $sfilterLt1 > $sinsert_$sgo10 > $sinsert_$sgo5 > $sleadsTo1 > $wpoly_go3 > $wpoly_go4 > $slookup5 > $slookup7 > $smakeCell2 > $smakeCell6 > $smakeCell10 > $smakeCell14 > $smakeCell18 > $smakeCell22 > $smakeCell26 > $smakeCell30 > $smakeCell34 > $smakeCell38 > $wpoly_go6 > $wpoly_go7 > $wpoly_go8 > $sshowStringP1 > $strim1 > $strim3 > $sunions1 > $sunless_eta > $swithCommand1 > $swithCommand4 > $swithCommand7 > lvl_r2714 > lvl1_r2715 > go_r2716 > $wgo1_r2717 > lvl2_r2718 > lvl3_r2719 > lvl4_r271a > lvl5_r271b > lvl6_r271c > lvl7_r271d > lvl8_r271e > lvl9_r271f > lvl10_r271g > lvl11_r271h > lvl12_r271i > lvl13_r271j > lvl14_r271k > lvl15_r271l > lvl16_r271m > lvl17_r271n > lvl18_r271o > lvl19_r271p > lvl20_r271q > lvl21_r271r > lvl22_r271s > lvl23_r271t > lvl24_r271u > lvl25_r271v > lvl26_r271w > lvl27_r271x > lvl28_r271y > lvl29_r271z > lvl30_r271A > lvl31_r271B > lvl32_r271C > lvl33_r271D > lvl34_r271E > lvl35_r271F > lvl36_r271G > lvl37_r271H > lvl38_r271I > lvl39_r271J > lvl40_r271K > lvl49_r2723 > lvl50_r2724 > lvl51_r2725 > lvl52_r2726 > lvl53_r2727 > lvl54_r2728 > lvl55_r2729 > lvl56_r272a > lvl57_r272b > lvl58_r272c > lvl59_r272d > lvl60_r272e > lvl61_r272f > lvl62_r272g > lvl63_r272h > lvl64_r272i > lvl65_r272j > lvl66_r272k > lvl67_r272l > lvl68_r272m > lvl69_r272n > lvl70_r272o > lvl71_r272p > lvl72_r272q > $s$fApplicativeRWST_$c<*>_r272u > $s$fApplicativeRWST_$cpure_r272v > lvl74_r272w > lvl75_r272x > lvl76_r272y > $s$fMonadRWST_$c>>_r272z > $s$fMonadRWST_$cfail_r272A > $s$fMonadRWST_$c>>=_r272B > lvl77_r272C > lvl78_r272D > lvl79_r272E > lvl80_r272F > lvl81_r272G > lvl82_r272H > $slesser1_r272S > lvl88_r272T > lvl89_r272U > $wcreate_r272V > lvl90_r272W > m2_r272X > $s$fMonadReaderT_$c>>_r272Y > $s$fMonadReaderT_$c>>=_r272Z > go10_r2730 > $wpoly_create_r2731 > lvl91_r2732 > lvl92_r2733 > lvl93_r2734 > lvl94_r2735 > lvl95_r2736 > lvl96_r2737 > lvl97_r2738 > lvl98_r2739 > lvl99_r273a > lvl100_r273b > lvl101_r273c > lvl102_r273d > lvl103_r273e > lvl104_r273f > lvl105_r273g > lvl106_r273h > lvl107_r273i > lvl108_r273j > lvl109_r273k > lvl110_r273l > lvl111_r273m > lvl112_r273n > lvl113_r273o > lvl114_r273p > lvl115_r273q > lvl116_r273r > lvl117_r273s > lvl118_r273t > lvl119_r273u > lvl120_r273v > lvl121_r273w > lvl122_r273x > lvl123_r273y > lvl124_r273z > $wpoly_create1_r273A > lvl125_r273B > lvl126_r273C > lvl127_r273D > lvl128_r273E > lvl129_r273F > lvl130_r273G > lvl131_r273H > lvl132_r273I > lvl133_r273J > lvl134_r273K > lvl135_r273L > $wlvl_r273M > lvl136_r273N > $wlvl1_r273O > lvl137_r273P > $wlvl2_r273Q > lvl138_r273R > $wlvl3_r273S > lvl139_r273T > $wlvl4_r273U > lvl140_r273V > $wlvl5_r273W > lvl141_r273X > $wlvl6_r273Y > lvl142_r273Z > lvl143_r2740 > lvl144_r2741 > lvl145_r2742 > lvl146_r2743 > lvl147_r2744 > lvl148_r2745 > lvl149_r2746 > lvl150_r2747 > lvl151_r2748 > lvl152_r2749 > lvl153_r274a > lvl154_r274b > $s$fFunctorReaderT_$cfmap_r274c > $s$fFunctorReaderT_$c<$_r274d > lvl155_r274e > lvl156_r274f > $s$fApplicativeReaderT_$c<*>_r274g > $s$fMonadReaderT_$creturn_r274h > $s$fMonadReaderT_$cfail_r274i > lvl157_r274j > lvl158_r274k > lvl159_r274l > lvl160_r274m > $d~_r274n > lvl161_r274p > lvl162_r274q > lvl163_r274s > lvl164_r274t > lvl165_r274v > lvl166_r274w > lvl167_r274y > lvl168_r274z > lvl169_r274B > lvl170_r274C > lvl171_r274E > lvl172_r274F > lvl173_r274H > lvl174_r274I > lvl175_r274K > lvl176_r274L > lvl177_r274N > lvl178_r274O > lvl179_r274Q > lvl180_r274R > lvl181_r274T > lvl182_r274U > lvl183_r274V > lvl184_r274W > lvl185_r274X > lvl186_r274Y > lvl187_r274Z > lvl188_r2750 > lvl189_r2751 > lvl190_r2752 > lvl191_r2753 > lvl192_r2754 > lvl193_r2755 > lvl194_r2756 > lvl195_r2757 > lvl196_r2758 > lvl197_r2759 > lvl198_r275a > lvl199_r275b > lvl200_r275c > lvl201_r275d > lvl202_r275e > lvl203_r275f > lvl204_r275g > lvl205_r275h > lvl206_r275i > lvl207_r275j > lvl208_r275k > lvl209_r275l > lvl210_r275m > lvl211_r275n > lvl212_r275o > lvl213_r275p > lvl214_r275q > lvl215_r275r > lvl216_r275s > lvl217_r275t > lvl218_r275u > lvl219_r275v > lvl220_r275w > ww1_r275x > ww2_r275y > lvl221_r275z > ww3_r275A > lvl222_r275B > pre_r275C > x_s27MP > eta_s27MQ > eta1_s27MR > ds_s27MS > ds1_s27MT > ds2_s27MU > ds3_s27MV > goal_s27MW > prxy'_s27MX > sat_s27MY > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} New description: When building with `stack build --resolver lts-7.20` {{{ [37 of 60] Compiling Document.Phase.Proofs ( src/Document/Phase/Proofs.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): StgCmmEnv: variable not found $dTypeable_aZSM local binds for: $sunionWith_$sunionWithKey $sfromList1 $sfromList3 $sfromList $s$fOrdEither $s$fMonadReaderrReaderT $s$fIsTupleconstrIdentity $s$fIsTupleconstr(,,,,) $s$fIsTupleconstr(,,,) $s$fIsTupleconstr(,,) $s$fIsTupleconstr(,,)2 $s$fIsTupleconstr(,)1 $s$fIsTupleconstr(,) $s$fIsTupleconstr(,)2 $s$fHasMachineP2p $fNFDataEventRefA $fMonoidEventRefA $fGenericEventRefA $wmake_phase4 make_phase1 $wpoly_go10 make_phase2 make_phase3 make_phase5 $fNFDataEventRefA4 $fNFDataEventRefA2 $stypeRep#78 $swithCommand8 $stypeRep#54 $swithCommand5 $stypeRep#11 $swithCommand2 $stypeRep#74 $stypeRep#81 $stypeRep#15 $stypeRep#20 $stypeRep#79 $stypeRep#80 $stypeRep#70 $stypeRep#75 $stypeRep#58 $stypeRep#66 $stypeRep#71 $stypeRep#62 $stypeRep#8 $stypeRep#67 $stypeRep#63 $stypeRep#59 $stypeRep#50 $stypeRep#55 $stypeRep#38 $stypeRep#46 $stypeRep#51 $stypeRep#42 $stypeRep#47 $stypeRep#43 $stypeRep#34 $stypeRep#39 $stypeRep#31 $stypeRep#35 $stypeRep#28 $stypeRep#24 $stypeRep#25 $stypeRep#21 $stypeRep#3 $stypeRep#16 $stypeRep#7 $stypeRep#12 $stypeRep#2 $smakeCell8 $smakeCell7 $smakeCell40 $smakeCell39 $smakeCell36 $smakeCell35 $smakeCell32 $smakeCell31 $smakeCell4 $smakeCell28 $smakeCell27 $smakeCell24 $smakeCell23 $smakeCell3 $smakeCell20 $smakeCell19 $smakeCell16 $smakeCell15 $smakeCell12 $smakeCell11 $wpoly_go5 $wgo5 $sfromList_go5 $wpoly_go2 $sfromList2 $s$fOrd(,) $sfromList_fromList'1 $wpoly_go1 $s$fEqEither $s$fOrdEither_$s$fOrdEither_$cp1Ord $s$fEq(,) $s$fOrd(,)_$s$fOrd(,)_$cp1Ord $s$fMonadRWST $s$fMonadReaderrReaderT1 $s$fMonadReaderT $s$fApplicativeReaderT $s$fMonadReaderT_$s$fMonadReaderT_$cfail $s$fMonadReaderT_$s$fMonadReaderT_$c>> $s$fMonadReaderT_$s$fMonadReaderT_$c>>= $s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad $s$fMonadRWST_$s$fMonadRWST_$cfail $s$fMonadRWST_$s$fMonadRWST_$c>> $s$fMonadRWST_$s$fMonadRWST_$c>>= $s$fMonadRWST_$s$fMonadRWST_$cp1Monad $s$fIsTupleconstr(,,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,,)1 $s$fIsTupleconstr(,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,)_irred2 $s$fIsTupleconstr(,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,)_$dLatexArgFromString $s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc $s$fIsTupleconstr(,,)_irred1 $s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty $s$fIsTupleconstr(,,)1 $s$fIsTupleconstr(,)3 $s$fHasMachineP1p $s$fHasMachineP2p1 $s$fHasMachineP2p2 $s$fHasMachineP2p3 $s$fHasMachineP2p4 $s$fHasMachineP2p5 $s$fHasMachineP2p6 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1 $s$fEq(,)_$dEq1 $s$fEq(,)_$dEq $s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$ $s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap $s$fApplicativeReaderT_$s$fFunctorReaderT $s$fApplicativeRWST $s$fApplicativeReaderT_$dApplicative $s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*> $s$fApplicativeReaderT_$s$fMonadReaderT_$creturn $s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative $s$fApplicativeRWST_$dFunctor $s$fApplicativeRWST_$s$fApplicativeRWST_$c<*> $s$fApplicativeRWST_$s$fApplicativeRWST_$cpure $s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative $fNFDataEventRefA1 $fNFDataEventRefA3 $w$dNFData2 $w$dNFData1 $w$dNFData $fNFDataEventRefA_$crnf $wgo $fMonoidEventRefA_$cmconcat $fMonoidEventRefA_$cmappend $fMonoidEventRefA_$cmempty $fGenericEventRefA_$cto $fGenericEventRefA_$cfrom make_phase4 ruleProxies_rSKY refinement_parser_rSL2 $w$smiddle $w$sgreater $sfilterGt1 $sfilterLt1 $sinsert_$sgo10 $sinsert_$sgo5 $sleadsTo1 $wpoly_go3 $wpoly_go4 $slookup5 $slookup7 $smakeCell2 $smakeCell6 $smakeCell10 $smakeCell14 $smakeCell18 $smakeCell22 $smakeCell26 $smakeCell30 $smakeCell34 $smakeCell38 $wpoly_go6 $wpoly_go7 $wpoly_go8 $sshowStringP1 $strim1 $strim3 $sunions1 $sunless_eta $swithCommand1 $swithCommand4 $swithCommand7 lvl_r2714 lvl1_r2715 go_r2716 $wgo1_r2717 lvl2_r2718 lvl3_r2719 lvl4_r271a lvl5_r271b lvl6_r271c lvl7_r271d lvl8_r271e lvl9_r271f lvl10_r271g lvl11_r271h lvl12_r271i lvl13_r271j lvl14_r271k lvl15_r271l lvl16_r271m lvl17_r271n lvl18_r271o lvl19_r271p lvl20_r271q lvl21_r271r lvl22_r271s lvl23_r271t lvl24_r271u lvl25_r271v lvl26_r271w lvl27_r271x lvl28_r271y lvl29_r271z lvl30_r271A lvl31_r271B lvl32_r271C lvl33_r271D lvl34_r271E lvl35_r271F lvl36_r271G lvl37_r271H lvl38_r271I lvl39_r271J lvl40_r271K lvl49_r2723 lvl50_r2724 lvl51_r2725 lvl52_r2726 lvl53_r2727 lvl54_r2728 lvl55_r2729 lvl56_r272a lvl57_r272b lvl58_r272c lvl59_r272d lvl60_r272e lvl61_r272f lvl62_r272g lvl63_r272h lvl64_r272i lvl65_r272j lvl66_r272k lvl67_r272l lvl68_r272m lvl69_r272n lvl70_r272o lvl71_r272p lvl72_r272q $s$fApplicativeRWST_$c<*>_r272u $s$fApplicativeRWST_$cpure_r272v lvl74_r272w lvl75_r272x lvl76_r272y $s$fMonadRWST_$c>>_r272z $s$fMonadRWST_$cfail_r272A $s$fMonadRWST_$c>>=_r272B lvl77_r272C lvl78_r272D lvl79_r272E lvl80_r272F lvl81_r272G lvl82_r272H $slesser1_r272S lvl88_r272T lvl89_r272U $wcreate_r272V lvl90_r272W m2_r272X $s$fMonadReaderT_$c>>_r272Y $s$fMonadReaderT_$c>>=_r272Z go10_r2730 $wpoly_create_r2731 lvl91_r2732 lvl92_r2733 lvl93_r2734 lvl94_r2735 lvl95_r2736 lvl96_r2737 lvl97_r2738 lvl98_r2739 lvl99_r273a lvl100_r273b lvl101_r273c lvl102_r273d lvl103_r273e lvl104_r273f lvl105_r273g lvl106_r273h lvl107_r273i lvl108_r273j lvl109_r273k lvl110_r273l lvl111_r273m lvl112_r273n lvl113_r273o lvl114_r273p lvl115_r273q lvl116_r273r lvl117_r273s lvl118_r273t lvl119_r273u lvl120_r273v lvl121_r273w lvl122_r273x lvl123_r273y lvl124_r273z $wpoly_create1_r273A lvl125_r273B lvl126_r273C lvl127_r273D lvl128_r273E lvl129_r273F lvl130_r273G lvl131_r273H lvl132_r273I lvl133_r273J lvl134_r273K lvl135_r273L $wlvl_r273M lvl136_r273N $wlvl1_r273O lvl137_r273P $wlvl2_r273Q lvl138_r273R $wlvl3_r273S lvl139_r273T $wlvl4_r273U lvl140_r273V $wlvl5_r273W lvl141_r273X $wlvl6_r273Y lvl142_r273Z lvl143_r2740 lvl144_r2741 lvl145_r2742 lvl146_r2743 lvl147_r2744 lvl148_r2745 lvl149_r2746 lvl150_r2747 lvl151_r2748 lvl152_r2749 lvl153_r274a lvl154_r274b $s$fFunctorReaderT_$cfmap_r274c $s$fFunctorReaderT_$c<$_r274d lvl155_r274e lvl156_r274f $s$fApplicativeReaderT_$c<*>_r274g $s$fMonadReaderT_$creturn_r274h $s$fMonadReaderT_$cfail_r274i lvl157_r274j lvl158_r274k lvl159_r274l lvl160_r274m $d~_r274n lvl161_r274p lvl162_r274q lvl163_r274s lvl164_r274t lvl165_r274v lvl166_r274w lvl167_r274y lvl168_r274z lvl169_r274B lvl170_r274C lvl171_r274E lvl172_r274F lvl173_r274H lvl174_r274I lvl175_r274K lvl176_r274L lvl177_r274N lvl178_r274O lvl179_r274Q lvl180_r274R lvl181_r274T lvl182_r274U lvl183_r274V lvl184_r274W lvl185_r274X lvl186_r274Y lvl187_r274Z lvl188_r2750 lvl189_r2751 lvl190_r2752 lvl191_r2753 lvl192_r2754 lvl193_r2755 lvl194_r2756 lvl195_r2757 lvl196_r2758 lvl197_r2759 lvl198_r275a lvl199_r275b lvl200_r275c lvl201_r275d lvl202_r275e lvl203_r275f lvl204_r275g lvl205_r275h lvl206_r275i lvl207_r275j lvl208_r275k lvl209_r275l lvl210_r275m lvl211_r275n lvl212_r275o lvl213_r275p lvl214_r275q lvl215_r275r lvl216_r275s lvl217_r275t lvl218_r275u lvl219_r275v lvl220_r275w ww1_r275x ww2_r275y lvl221_r275z ww3_r275A lvl222_r275B pre_r275C x_s27MP eta_s27MQ eta1_s27MR ds_s27MS ds1_s27MT ds2_s27MU ds3_s27MV goal_s27MW prxy'_s27MX sat_s27MY 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 Sat Apr 8 08:30:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 08:30:56 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.b56b1481bcf0bff694cc282c7a272c6c@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by cipher1024: Old description: > When building with `stack build --resolver lts-7.20` > > {{{ > [37 of 60] Compiling Document.Phase.Proofs ( > src/Document/Phase/Proofs.hs, .stack- > work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o ) > > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.1 for x86_64-apple-darwin): > StgCmmEnv: variable not found > $dTypeable_aZSM > local binds for: > $sunionWith_$sunionWithKey > $sfromList1 > $sfromList3 > $sfromList > $s$fOrdEither > $s$fMonadReaderrReaderT > $s$fIsTupleconstrIdentity > $s$fIsTupleconstr(,,,,) > $s$fIsTupleconstr(,,,) > $s$fIsTupleconstr(,,) > $s$fIsTupleconstr(,,)2 > $s$fIsTupleconstr(,)1 > $s$fIsTupleconstr(,) > $s$fIsTupleconstr(,)2 > $s$fHasMachineP2p > $fNFDataEventRefA > $fMonoidEventRefA > $fGenericEventRefA > $wmake_phase4 > make_phase1 > $wpoly_go10 > make_phase2 > make_phase3 > make_phase5 > $fNFDataEventRefA4 > $fNFDataEventRefA2 > $stypeRep#78 > $swithCommand8 > $stypeRep#54 > $swithCommand5 > $stypeRep#11 > $swithCommand2 > $stypeRep#74 > $stypeRep#81 > $stypeRep#15 > $stypeRep#20 > $stypeRep#79 > $stypeRep#80 > $stypeRep#70 > $stypeRep#75 > $stypeRep#58 > $stypeRep#66 > $stypeRep#71 > $stypeRep#62 > $stypeRep#8 > $stypeRep#67 > $stypeRep#63 > $stypeRep#59 > $stypeRep#50 > $stypeRep#55 > $stypeRep#38 > $stypeRep#46 > $stypeRep#51 > $stypeRep#42 > $stypeRep#47 > $stypeRep#43 > $stypeRep#34 > $stypeRep#39 > $stypeRep#31 > $stypeRep#35 > $stypeRep#28 > $stypeRep#24 > $stypeRep#25 > $stypeRep#21 > $stypeRep#3 > $stypeRep#16 > $stypeRep#7 > $stypeRep#12 > $stypeRep#2 > $smakeCell8 > $smakeCell7 > $smakeCell40 > $smakeCell39 > $smakeCell36 > $smakeCell35 > $smakeCell32 > $smakeCell31 > $smakeCell4 > $smakeCell28 > $smakeCell27 > $smakeCell24 > $smakeCell23 > $smakeCell3 > $smakeCell20 > $smakeCell19 > $smakeCell16 > $smakeCell15 > $smakeCell12 > $smakeCell11 > $wpoly_go5 > $wgo5 > $sfromList_go5 > $wpoly_go2 > $sfromList2 > $s$fOrd(,) > $sfromList_fromList'1 > $wpoly_go1 > $s$fEqEither > $s$fOrdEither_$s$fOrdEither_$cp1Ord > $s$fEq(,) > $s$fOrd(,)_$s$fOrd(,)_$cp1Ord > $s$fMonadRWST > $s$fMonadReaderrReaderT1 > $s$fMonadReaderT > $s$fApplicativeReaderT > $s$fMonadReaderT_$s$fMonadReaderT_$cfail > $s$fMonadReaderT_$s$fMonadReaderT_$c>> > $s$fMonadReaderT_$s$fMonadReaderT_$c>>= > $s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad > $s$fMonadRWST_$s$fMonadRWST_$cfail > $s$fMonadRWST_$s$fMonadRWST_$c>> > $s$fMonadRWST_$s$fMonadRWST_$c>>= > $s$fMonadRWST_$s$fMonadRWST_$cp1Monad > $s$fIsTupleconstr(,,,,)_$s$fLatexArg[] > $s$fIsTupleconstr(,,,,)1 > $s$fIsTupleconstr(,,,)_$s$fLatexArg[] > $s$fIsTupleconstr(,,,)_irred2 > $s$fIsTupleconstr(,,)_$s$fLatexArg[] > $s$fIsTupleconstr(,,)_$dLatexArgFromString > $s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc > $s$fIsTupleconstr(,,)_irred1 > $s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty > $s$fIsTupleconstr(,,)1 > $s$fIsTupleconstr(,)3 > $s$fHasMachineP1p > $s$fHasMachineP2p1 > $s$fHasMachineP2p2 > $s$fHasMachineP2p3 > $s$fHasMachineP2p4 > $s$fHasMachineP2p5 > $s$fHasMachineP2p6 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1 > $s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1 > $s$fEq(,)_$dEq1 > $s$fEq(,)_$dEq > $s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$ > $s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap > $s$fApplicativeReaderT_$s$fFunctorReaderT > $s$fApplicativeRWST > $s$fApplicativeReaderT_$dApplicative > $s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*> > $s$fApplicativeReaderT_$s$fMonadReaderT_$creturn > $s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative > $s$fApplicativeRWST_$dFunctor > $s$fApplicativeRWST_$s$fApplicativeRWST_$c<*> > $s$fApplicativeRWST_$s$fApplicativeRWST_$cpure > $s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative > $fNFDataEventRefA1 > $fNFDataEventRefA3 > $w$dNFData2 > $w$dNFData1 > $w$dNFData > $fNFDataEventRefA_$crnf > $wgo > $fMonoidEventRefA_$cmconcat > $fMonoidEventRefA_$cmappend > $fMonoidEventRefA_$cmempty > $fGenericEventRefA_$cto > $fGenericEventRefA_$cfrom > make_phase4 > ruleProxies_rSKY > refinement_parser_rSL2 > $w$smiddle > $w$sgreater > $sfilterGt1 > $sfilterLt1 > $sinsert_$sgo10 > $sinsert_$sgo5 > $sleadsTo1 > $wpoly_go3 > $wpoly_go4 > $slookup5 > $slookup7 > $smakeCell2 > $smakeCell6 > $smakeCell10 > $smakeCell14 > $smakeCell18 > $smakeCell22 > $smakeCell26 > $smakeCell30 > $smakeCell34 > $smakeCell38 > $wpoly_go6 > $wpoly_go7 > $wpoly_go8 > $sshowStringP1 > $strim1 > $strim3 > $sunions1 > $sunless_eta > $swithCommand1 > $swithCommand4 > $swithCommand7 > lvl_r2714 > lvl1_r2715 > go_r2716 > $wgo1_r2717 > lvl2_r2718 > lvl3_r2719 > lvl4_r271a > lvl5_r271b > lvl6_r271c > lvl7_r271d > lvl8_r271e > lvl9_r271f > lvl10_r271g > lvl11_r271h > lvl12_r271i > lvl13_r271j > lvl14_r271k > lvl15_r271l > lvl16_r271m > lvl17_r271n > lvl18_r271o > lvl19_r271p > lvl20_r271q > lvl21_r271r > lvl22_r271s > lvl23_r271t > lvl24_r271u > lvl25_r271v > lvl26_r271w > lvl27_r271x > lvl28_r271y > lvl29_r271z > lvl30_r271A > lvl31_r271B > lvl32_r271C > lvl33_r271D > lvl34_r271E > lvl35_r271F > lvl36_r271G > lvl37_r271H > lvl38_r271I > lvl39_r271J > lvl40_r271K > lvl49_r2723 > lvl50_r2724 > lvl51_r2725 > lvl52_r2726 > lvl53_r2727 > lvl54_r2728 > lvl55_r2729 > lvl56_r272a > lvl57_r272b > lvl58_r272c > lvl59_r272d > lvl60_r272e > lvl61_r272f > lvl62_r272g > lvl63_r272h > lvl64_r272i > lvl65_r272j > lvl66_r272k > lvl67_r272l > lvl68_r272m > lvl69_r272n > lvl70_r272o > lvl71_r272p > lvl72_r272q > $s$fApplicativeRWST_$c<*>_r272u > $s$fApplicativeRWST_$cpure_r272v > lvl74_r272w > lvl75_r272x > lvl76_r272y > $s$fMonadRWST_$c>>_r272z > $s$fMonadRWST_$cfail_r272A > $s$fMonadRWST_$c>>=_r272B > lvl77_r272C > lvl78_r272D > lvl79_r272E > lvl80_r272F > lvl81_r272G > lvl82_r272H > $slesser1_r272S > lvl88_r272T > lvl89_r272U > $wcreate_r272V > lvl90_r272W > m2_r272X > $s$fMonadReaderT_$c>>_r272Y > $s$fMonadReaderT_$c>>=_r272Z > go10_r2730 > $wpoly_create_r2731 > lvl91_r2732 > lvl92_r2733 > lvl93_r2734 > lvl94_r2735 > lvl95_r2736 > lvl96_r2737 > lvl97_r2738 > lvl98_r2739 > lvl99_r273a > lvl100_r273b > lvl101_r273c > lvl102_r273d > lvl103_r273e > lvl104_r273f > lvl105_r273g > lvl106_r273h > lvl107_r273i > lvl108_r273j > lvl109_r273k > lvl110_r273l > lvl111_r273m > lvl112_r273n > lvl113_r273o > lvl114_r273p > lvl115_r273q > lvl116_r273r > lvl117_r273s > lvl118_r273t > lvl119_r273u > lvl120_r273v > lvl121_r273w > lvl122_r273x > lvl123_r273y > lvl124_r273z > $wpoly_create1_r273A > lvl125_r273B > lvl126_r273C > lvl127_r273D > lvl128_r273E > lvl129_r273F > lvl130_r273G > lvl131_r273H > lvl132_r273I > lvl133_r273J > lvl134_r273K > lvl135_r273L > $wlvl_r273M > lvl136_r273N > $wlvl1_r273O > lvl137_r273P > $wlvl2_r273Q > lvl138_r273R > $wlvl3_r273S > lvl139_r273T > $wlvl4_r273U > lvl140_r273V > $wlvl5_r273W > lvl141_r273X > $wlvl6_r273Y > lvl142_r273Z > lvl143_r2740 > lvl144_r2741 > lvl145_r2742 > lvl146_r2743 > lvl147_r2744 > lvl148_r2745 > lvl149_r2746 > lvl150_r2747 > lvl151_r2748 > lvl152_r2749 > lvl153_r274a > lvl154_r274b > $s$fFunctorReaderT_$cfmap_r274c > $s$fFunctorReaderT_$c<$_r274d > lvl155_r274e > lvl156_r274f > $s$fApplicativeReaderT_$c<*>_r274g > $s$fMonadReaderT_$creturn_r274h > $s$fMonadReaderT_$cfail_r274i > lvl157_r274j > lvl158_r274k > lvl159_r274l > lvl160_r274m > $d~_r274n > lvl161_r274p > lvl162_r274q > lvl163_r274s > lvl164_r274t > lvl165_r274v > lvl166_r274w > lvl167_r274y > lvl168_r274z > lvl169_r274B > lvl170_r274C > lvl171_r274E > lvl172_r274F > lvl173_r274H > lvl174_r274I > lvl175_r274K > lvl176_r274L > lvl177_r274N > lvl178_r274O > lvl179_r274Q > lvl180_r274R > lvl181_r274T > lvl182_r274U > lvl183_r274V > lvl184_r274W > lvl185_r274X > lvl186_r274Y > lvl187_r274Z > lvl188_r2750 > lvl189_r2751 > lvl190_r2752 > lvl191_r2753 > lvl192_r2754 > lvl193_r2755 > lvl194_r2756 > lvl195_r2757 > lvl196_r2758 > lvl197_r2759 > lvl198_r275a > lvl199_r275b > lvl200_r275c > lvl201_r275d > lvl202_r275e > lvl203_r275f > lvl204_r275g > lvl205_r275h > lvl206_r275i > lvl207_r275j > lvl208_r275k > lvl209_r275l > lvl210_r275m > lvl211_r275n > lvl212_r275o > lvl213_r275p > lvl214_r275q > lvl215_r275r > lvl216_r275s > lvl217_r275t > lvl218_r275u > lvl219_r275v > lvl220_r275w > ww1_r275x > ww2_r275y > lvl221_r275z > ww3_r275A > lvl222_r275B > pre_r275C > x_s27MP > eta_s27MQ > eta1_s27MR > ds_s27MS > ds1_s27MT > ds2_s27MU > ds3_s27MV > goal_s27MW > prxy'_s27MX > sat_s27MY > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} New description: When building with `stack build --resolver lts-7.20`and `stack build --resolver lts-8.8`, i.e. with ghc-8.0.1 and ghc-8.0.2. {{{ [37 of 60] Compiling Document.Phase.Proofs ( src/Document/Phase/Proofs.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Document/Phase/Proofs.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): StgCmmEnv: variable not found $dTypeable_aZSM local binds for: $sunionWith_$sunionWithKey $sfromList1 $sfromList3 $sfromList $s$fOrdEither $s$fMonadReaderrReaderT $s$fIsTupleconstrIdentity $s$fIsTupleconstr(,,,,) $s$fIsTupleconstr(,,,) $s$fIsTupleconstr(,,) $s$fIsTupleconstr(,,)2 $s$fIsTupleconstr(,)1 $s$fIsTupleconstr(,) $s$fIsTupleconstr(,)2 $s$fHasMachineP2p $fNFDataEventRefA $fMonoidEventRefA $fGenericEventRefA $wmake_phase4 make_phase1 $wpoly_go10 make_phase2 make_phase3 make_phase5 $fNFDataEventRefA4 $fNFDataEventRefA2 $stypeRep#78 $swithCommand8 $stypeRep#54 $swithCommand5 $stypeRep#11 $swithCommand2 $stypeRep#74 $stypeRep#81 $stypeRep#15 $stypeRep#20 $stypeRep#79 $stypeRep#80 $stypeRep#70 $stypeRep#75 $stypeRep#58 $stypeRep#66 $stypeRep#71 $stypeRep#62 $stypeRep#8 $stypeRep#67 $stypeRep#63 $stypeRep#59 $stypeRep#50 $stypeRep#55 $stypeRep#38 $stypeRep#46 $stypeRep#51 $stypeRep#42 $stypeRep#47 $stypeRep#43 $stypeRep#34 $stypeRep#39 $stypeRep#31 $stypeRep#35 $stypeRep#28 $stypeRep#24 $stypeRep#25 $stypeRep#21 $stypeRep#3 $stypeRep#16 $stypeRep#7 $stypeRep#12 $stypeRep#2 $smakeCell8 $smakeCell7 $smakeCell40 $smakeCell39 $smakeCell36 $smakeCell35 $smakeCell32 $smakeCell31 $smakeCell4 $smakeCell28 $smakeCell27 $smakeCell24 $smakeCell23 $smakeCell3 $smakeCell20 $smakeCell19 $smakeCell16 $smakeCell15 $smakeCell12 $smakeCell11 $wpoly_go5 $wgo5 $sfromList_go5 $wpoly_go2 $sfromList2 $s$fOrd(,) $sfromList_fromList'1 $wpoly_go1 $s$fEqEither $s$fOrdEither_$s$fOrdEither_$cp1Ord $s$fEq(,) $s$fOrd(,)_$s$fOrd(,)_$cp1Ord $s$fMonadRWST $s$fMonadReaderrReaderT1 $s$fMonadReaderT $s$fApplicativeReaderT $s$fMonadReaderT_$s$fMonadReaderT_$cfail $s$fMonadReaderT_$s$fMonadReaderT_$c>> $s$fMonadReaderT_$s$fMonadReaderT_$c>>= $s$fMonadReaderT_$s$fMonadReaderT_$cp1Monad $s$fMonadRWST_$s$fMonadRWST_$cfail $s$fMonadRWST_$s$fMonadRWST_$c>> $s$fMonadRWST_$s$fMonadRWST_$c>>= $s$fMonadRWST_$s$fMonadRWST_$cp1Monad $s$fIsTupleconstr(,,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,,)1 $s$fIsTupleconstr(,,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,,)_irred2 $s$fIsTupleconstr(,,)_$s$fLatexArg[] $s$fIsTupleconstr(,,)_$dLatexArgFromString $s$fIsTupleconstr(,,)_$s$fLatexArgFromStringConc $s$fIsTupleconstr(,,)_irred1 $s$fIsTupleconstr(,,)_$s$fLatexArgNonEmpty $s$fIsTupleconstr(,,)1 $s$fIsTupleconstr(,)3 $s$fHasMachineP1p $s$fHasMachineP2p1 $s$fHasMachineP2p2 $s$fHasMachineP2p3 $s$fHasMachineP2p4 $s$fHasMachineP2p5 $s$fHasMachineP2p6 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp5HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp4HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp3HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp2HasMachineP1 $s$fHasMachineP1p_$s$fHasMachineP1p_$cp1HasMachineP1 $s$fEq(,)_$dEq1 $s$fEq(,)_$dEq $s$fApplicativeReaderT_$s$fFunctorReaderT_$c<$ $s$fApplicativeReaderT_$s$fFunctorReaderT_$cfmap $s$fApplicativeReaderT_$s$fFunctorReaderT $s$fApplicativeRWST $s$fApplicativeReaderT_$dApplicative $s$fApplicativeReaderT_$s$fApplicativeReaderT_$c<*> $s$fApplicativeReaderT_$s$fMonadReaderT_$creturn $s$fApplicativeReaderT_$s$fApplicativeReaderT_$cp1Applicative $s$fApplicativeRWST_$dFunctor $s$fApplicativeRWST_$s$fApplicativeRWST_$c<*> $s$fApplicativeRWST_$s$fApplicativeRWST_$cpure $s$fApplicativeRWST_$s$fApplicativeRWST_$cp1Applicative $fNFDataEventRefA1 $fNFDataEventRefA3 $w$dNFData2 $w$dNFData1 $w$dNFData $fNFDataEventRefA_$crnf $wgo $fMonoidEventRefA_$cmconcat $fMonoidEventRefA_$cmappend $fMonoidEventRefA_$cmempty $fGenericEventRefA_$cto $fGenericEventRefA_$cfrom make_phase4 ruleProxies_rSKY refinement_parser_rSL2 $w$smiddle $w$sgreater $sfilterGt1 $sfilterLt1 $sinsert_$sgo10 $sinsert_$sgo5 $sleadsTo1 $wpoly_go3 $wpoly_go4 $slookup5 $slookup7 $smakeCell2 $smakeCell6 $smakeCell10 $smakeCell14 $smakeCell18 $smakeCell22 $smakeCell26 $smakeCell30 $smakeCell34 $smakeCell38 $wpoly_go6 $wpoly_go7 $wpoly_go8 $sshowStringP1 $strim1 $strim3 $sunions1 $sunless_eta $swithCommand1 $swithCommand4 $swithCommand7 lvl_r2714 lvl1_r2715 go_r2716 $wgo1_r2717 lvl2_r2718 lvl3_r2719 lvl4_r271a lvl5_r271b lvl6_r271c lvl7_r271d lvl8_r271e lvl9_r271f lvl10_r271g lvl11_r271h lvl12_r271i lvl13_r271j lvl14_r271k lvl15_r271l lvl16_r271m lvl17_r271n lvl18_r271o lvl19_r271p lvl20_r271q lvl21_r271r lvl22_r271s lvl23_r271t lvl24_r271u lvl25_r271v lvl26_r271w lvl27_r271x lvl28_r271y lvl29_r271z lvl30_r271A lvl31_r271B lvl32_r271C lvl33_r271D lvl34_r271E lvl35_r271F lvl36_r271G lvl37_r271H lvl38_r271I lvl39_r271J lvl40_r271K lvl49_r2723 lvl50_r2724 lvl51_r2725 lvl52_r2726 lvl53_r2727 lvl54_r2728 lvl55_r2729 lvl56_r272a lvl57_r272b lvl58_r272c lvl59_r272d lvl60_r272e lvl61_r272f lvl62_r272g lvl63_r272h lvl64_r272i lvl65_r272j lvl66_r272k lvl67_r272l lvl68_r272m lvl69_r272n lvl70_r272o lvl71_r272p lvl72_r272q $s$fApplicativeRWST_$c<*>_r272u $s$fApplicativeRWST_$cpure_r272v lvl74_r272w lvl75_r272x lvl76_r272y $s$fMonadRWST_$c>>_r272z $s$fMonadRWST_$cfail_r272A $s$fMonadRWST_$c>>=_r272B lvl77_r272C lvl78_r272D lvl79_r272E lvl80_r272F lvl81_r272G lvl82_r272H $slesser1_r272S lvl88_r272T lvl89_r272U $wcreate_r272V lvl90_r272W m2_r272X $s$fMonadReaderT_$c>>_r272Y $s$fMonadReaderT_$c>>=_r272Z go10_r2730 $wpoly_create_r2731 lvl91_r2732 lvl92_r2733 lvl93_r2734 lvl94_r2735 lvl95_r2736 lvl96_r2737 lvl97_r2738 lvl98_r2739 lvl99_r273a lvl100_r273b lvl101_r273c lvl102_r273d lvl103_r273e lvl104_r273f lvl105_r273g lvl106_r273h lvl107_r273i lvl108_r273j lvl109_r273k lvl110_r273l lvl111_r273m lvl112_r273n lvl113_r273o lvl114_r273p lvl115_r273q lvl116_r273r lvl117_r273s lvl118_r273t lvl119_r273u lvl120_r273v lvl121_r273w lvl122_r273x lvl123_r273y lvl124_r273z $wpoly_create1_r273A lvl125_r273B lvl126_r273C lvl127_r273D lvl128_r273E lvl129_r273F lvl130_r273G lvl131_r273H lvl132_r273I lvl133_r273J lvl134_r273K lvl135_r273L $wlvl_r273M lvl136_r273N $wlvl1_r273O lvl137_r273P $wlvl2_r273Q lvl138_r273R $wlvl3_r273S lvl139_r273T $wlvl4_r273U lvl140_r273V $wlvl5_r273W lvl141_r273X $wlvl6_r273Y lvl142_r273Z lvl143_r2740 lvl144_r2741 lvl145_r2742 lvl146_r2743 lvl147_r2744 lvl148_r2745 lvl149_r2746 lvl150_r2747 lvl151_r2748 lvl152_r2749 lvl153_r274a lvl154_r274b $s$fFunctorReaderT_$cfmap_r274c $s$fFunctorReaderT_$c<$_r274d lvl155_r274e lvl156_r274f $s$fApplicativeReaderT_$c<*>_r274g $s$fMonadReaderT_$creturn_r274h $s$fMonadReaderT_$cfail_r274i lvl157_r274j lvl158_r274k lvl159_r274l lvl160_r274m $d~_r274n lvl161_r274p lvl162_r274q lvl163_r274s lvl164_r274t lvl165_r274v lvl166_r274w lvl167_r274y lvl168_r274z lvl169_r274B lvl170_r274C lvl171_r274E lvl172_r274F lvl173_r274H lvl174_r274I lvl175_r274K lvl176_r274L lvl177_r274N lvl178_r274O lvl179_r274Q lvl180_r274R lvl181_r274T lvl182_r274U lvl183_r274V lvl184_r274W lvl185_r274X lvl186_r274Y lvl187_r274Z lvl188_r2750 lvl189_r2751 lvl190_r2752 lvl191_r2753 lvl192_r2754 lvl193_r2755 lvl194_r2756 lvl195_r2757 lvl196_r2758 lvl197_r2759 lvl198_r275a lvl199_r275b lvl200_r275c lvl201_r275d lvl202_r275e lvl203_r275f lvl204_r275g lvl205_r275h lvl206_r275i lvl207_r275j lvl208_r275k lvl209_r275l lvl210_r275m lvl211_r275n lvl212_r275o lvl213_r275p lvl214_r275q lvl215_r275r lvl216_r275s lvl217_r275t lvl218_r275u lvl219_r275v lvl220_r275w ww1_r275x ww2_r275y lvl221_r275z ww3_r275A lvl222_r275B pre_r275C x_s27MP eta_s27MQ eta1_s27MR ds_s27MS ds1_s27MT ds2_s27MU ds3_s27MV goal_s27MW prxy'_s27MX sat_s27MY 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 Sat Apr 8 09:17:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 09:17:53 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.0439df2bc28cc103fddce1c8add6f9cd@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded Comment: What are you building? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 12:46:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 12:46:24 -0000 Subject: [GHC] #13548: the 'impossible' happened during building PureScript for profiling Message-ID: <048.39dcb690555392fca9572f8893237e43@haskell.org> #13548: the 'impossible' happened during building PureScript for profiling -------------------------------------+------------------------------------- Reporter: hdgarrood | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Repro steps: * `git clone https://github.com/purescript/purescript` * `cd purescript` * `git checkout v0.11.2` * `stack build --profile` The error was: {{{ [ 23 of 145] Compiling Language.PureScript.Constants ( src/Language/PureScript/Constants.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/Language/PureScript/Constants.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): kindPrimRep.go rep_sfuE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package purescript-0.11.2 using: /home/harry/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build lib:purescript exe:purs --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} Sorry that this is pretty much the complete opposite of a minimal reproducing example, but I have no clue how to go about isolating the part that's actually causing the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 12:48:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 12:48:23 -0000 Subject: [GHC] #13548: the 'impossible' happened during building PureScript for profiling In-Reply-To: <048.39dcb690555392fca9572f8893237e43@haskell.org> References: <048.39dcb690555392fca9572f8893237e43@haskell.org> Message-ID: <063.a824a603138fb06241352a1c3683eb95@haskell.org> #13548: the 'impossible' happened during building PureScript for profiling -------------------------------------+------------------------------------- Reporter: hdgarrood | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #13503 Comment: See #13503. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 12:49:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 12:49:42 -0000 Subject: [GHC] #13548: the 'impossible' happened during building PureScript for profiling In-Reply-To: <048.39dcb690555392fca9572f8893237e43@haskell.org> References: <048.39dcb690555392fca9572f8893237e43@haskell.org> Message-ID: <063.3dacef421858d7bf20cd4d8af8e6cec7@haskell.org> #13548: the 'impossible' happened during building PureScript for profiling -------------------------------------+------------------------------------- Reporter: hdgarrood | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hdgarrood): Oops, I guess I should have searched the bug database first. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 15:35:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 15:35:03 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.6c533fcf4cb7f5758d2c8dcf3c06f8d2@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I suspect it's `literate-unitb` from [https://github.com/unitb/literate- unitb/tree/d35ae6190407b7579e785db9dac8ef0b62c729eb here]. I was able to reproduce the panic, but `literate-unitb` is so complicated that I can't minimize the panic down to a single file with no dependencies. cipher1024, might you be able to trim the example down some so that we can help debug this further? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 15:51:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 15:51:04 -0000 Subject: [GHC] #12396: Panic when specializing in another module In-Reply-To: <047.cfbab0d2aaad50ebf39c103bee8948e0@haskell.org> References: <047.cfbab0d2aaad50ebf39c103bee8948e0@haskell.org> Message-ID: <062.83603a8892f3d7a9a8deadd0e9eb9785@haskell.org> #12396: Panic when specializing in another module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: I can't reproduce this on GHC 8.2.1 either, so I'll close this as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 15:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 15:57:00 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.7694f93529d68c20b9605966964c3097@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another useful check would be to build this with GHC HEAD. It's possible that this bug has already been fixed there (e.g., this might be a duplicate of #12944, but it's hard to tell). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 17:34:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 17:34:27 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.7e2688da90336943e4cf0416d883c7fc@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): Good guess! As for trimming it down, I'm not sure how to do it. How do you normally proceed? Is there a better approach to commenting out functions until I find one that breaks the compiler? I'm going to try HEAD. If the fix exists, is there any chance it might get applied to ghc-8.0.1 and ghc-8.0.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 17:41:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 17:41:49 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.909804dba32212789d4fa60e1fb994da@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 cipher1024]: > How do you normally proceed? Is there a better approach to commenting out functions until I find one that breaks the compiler? That's the approach I use, yes :) I did recall that the issue appears when you trim down [https://github.com/unitb/literate- unitb/blob/d35ae6190407b7579e785db9dac8ef0b62c729eb/src/Document/Phase/Proofs.hs Document.Phase.Proofs] to just `liveness`, `stepList`, and `stepList'` (you can replace some subexpressions, such as `withCommand "\\safstep" $ safStep m`, with `undefined` to help eliminate top-level definitions you don't need, like `safStep`). But after that point, the issue was tracking down all of the types imported from other modules and putting them all in one place. That's the point where I gave up, since trying to understand the innards of `HasCell`, `Builder`, `LatexParserA`, etc. proved too much for my feeble brain. > If the fix exists, is there any chance it might get applied to ghc-8.0.1 and ghc-8.0.2? No. GHC 8.2.1 is going to be released soon, so if you help us discover a bug that still needs to be fixed, then it would get merged into 8.2.1 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 18:12:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 18:12:48 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.0e101ec34d57dbf25339cbabcb0c719d@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): Yeah, the parser is fairly complex. Thank you for trying to minimize it yourself. So here's a game plan: 0. minimize the example 1. get / build ghc HEAD 2. try it on example. I have never worked on ghc. What is the simplest way to get ghc HEAD to test my example with it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 18:17:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 18:17:35 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.a0e649649dd3d2a92a94dced158d45f5@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 cipher1024]: > What is the simplest way to get ghc HEAD to test my example with it? If you're on Ubuntu, you can use [https://launchpad.net/~hvr/+archive/ubuntu/ghc this PPA] to install `ghc-8.2.1` or `ghc-head` (they're pretty much the same at this point) quite easily. Otherwise, you can use [http://downloads.haskell.org/~ghc/8.2.1-rc1/ this link] to get binary distributions of GHC 8.2.1-rc1 for Windows, OS X, or Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 19:03:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 19:03:58 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.1ecb37294f484edc972e7a1d72154877@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): Awesome that helps a lot, thank you! I departed from the plan just to see if `ghc-8.2.1` has the bug still. Since most libraries don't support `base-4.10.0.0` it didn't get far enough to tell. Is there is a way to disregard the libraries' upper bound on base? Could that work? Otherwise, I'll just get back to minimizing the example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 19:12:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 19:12:02 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.b948575bc2f421d120976aa0716f0520@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 cipher1024]: > Is there is a way to disregard the libraries' upper bound on base? Could that work? With `cabal`, that's possible with the `--allow-newer` flag. `stack-1.4.0` and later apparently [https://github.com/commercialhaskell/stack/issues/922 also has] an `allow-newer` config option, although I've never tried that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 21:40:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 21:40:43 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts Message-ID: <050.20687161d0113262dd4300045296344b@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently attempted to upgrade `singletons` to use GHC 8.2.1, but was thwarted when GHC's typechecker rejected code that was generated by Template Haskell. I was able to put all of this code in a single module (which I've attached), but sadly, it's 1367 lines long. What's important is that GHC 8.0.1 and 8.0.2 accept this code, but neither 8.2.1-rc1 nor HEAD do. Here is the error message you get, in its full glory: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:1328:59: error: • Couldn't match type ‘c69895866216793215480’ with ‘[a_a337f]’ ‘c69895866216793215480’ is untouchable inside the constraints: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) bound by the type signature for: lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) (r_a33fq :: [[a_a337f]]). (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) => Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) at Bug.hs:(1289,35)-(1294,157) Expected type: Sing t -> Sing t1 -> Sing t2 -> Sing (((Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO @@ t) @@ t1) @@ t2) Actual type: Sing t -> Sing t1 -> Sing t2 -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) • In the second argument of ‘singFun3’, namely ‘sInterleave'’ In the first argument of ‘applySing’, namely ‘((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')’ In the first argument of ‘applySing’, namely ‘((applySing ((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')) ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ • Relevant bindings include sX_6989586621679737266 :: Sing (Let6989586621679737265X_6989586621679737266Sym6 xs0_a33a0 t_a33aL ts_a33aM is_a33aO xs_a33fp r_a33fq) (bound at Bug.hs:1321:41) r_a33iK :: Sing r_a33fq (bound at Bug.hs:1295:57) xs_a33iJ :: Sing xs_a33fp (bound at Bug.hs:1295:48) lambda_a33iH :: Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) (bound at Bug.hs:1295:35) sR :: Sing arg_a33hi (bound at Bug.hs:1287:45) sXs :: Sing arg_a33hh (bound at Bug.hs:1287:41) sInterleave' :: forall (arg_a33he :: TyFun [a_a337f] c69895866216793215480 -> *) (arg_a33hf :: [a_a337f]) (arg_a33hg :: [c69895866216793215480]). Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33he) arg_a33hf) arg_a33hg) (bound at Bug.hs:1166:29) lambda_a33ha :: Sing t_a33aL -> Sing ts_a33aM -> Sing is_a33aO -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) arg_a33h1) (bound at Bug.hs:1153:23) sTs :: Sing n_a1kQd (bound at Bug.hs:1143:34) sT :: Sing n_a1kQc (bound at Bug.hs:1143:31) lambda_a33gY :: Sing xs0_a33a0 -> Sing (Apply PermutationsSym0 t_a33gX) (bound at Bug.hs:1127:11) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 1328 | sInterleave')) | ^^^^^^^^^^^^ Bug.hs:1328:59: error: • Could not deduce: Let6989586621679736980Interleave' xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 ~ Let6989586621679736980Interleave' xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 from the context: t_a33gX ~ xs0_a33a0 bound by the type signature for: lambda_a33gY :: forall (xs0_a33a0 :: [a_a337f]). t_a33gX ~ xs0_a33a0 => Sing xs0_a33a0 -> Sing (Apply PermutationsSym0 t_a33gX) at Bug.hs:(1122,11)-(1126,67) or from: arg_a33h0 ~ (n_a1kQc : n_a1kQd) bound by a pattern with constructor: SCons :: forall a_11 (z_a1kQb :: [a_11]) (n_a1kQc :: a_11) (n_a1kQd :: [a_11]). z_a1kQb ~ (n_a1kQc : n_a1kQd) => Sing n_a1kQc -> Sing n_a1kQd -> Sing z_a1kQb, in an equation for ‘sPerms’ at Bug.hs:1143:25-36 or from: (arg_a33h0 ~ Apply (Apply (:$) t_a33aL) ts_a33aM, arg_a33h1 ~ is_a33aO) bound by the type signature for: lambda_a33ha :: forall (t_a33aL :: a_a337f) (ts_a33aM :: [a_a337f]) (is_a33aO :: [a_a337f]). (arg_a33h0 ~ Apply (Apply (:$) t_a33aL) ts_a33aM, arg_a33h1 ~ is_a33aO) => Sing t_a33aL -> Sing ts_a33aM -> Sing is_a33aO -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) arg_a33h1) at Bug.hs:(1145,23)-(1152,117) or from: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) bound by the type signature for: lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) (r_a33fq :: [[a_a337f]]). (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) => Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) at Bug.hs:(1289,35)-(1294,157) Expected type: Sing t -> Sing t1 -> Sing t2 -> Sing (((Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO @@ t) @@ t1) @@ t2) Actual type: Sing t -> Sing t1 -> Sing t2 -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) The type variable ‘c69895866216793215480’ is ambiguous Use -fprint-explicit-kinds to see the kind arguments • In the second argument of ‘singFun3’, namely ‘sInterleave'’ In the first argument of ‘applySing’, namely ‘((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')’ In the first argument of ‘applySing’, namely ‘((applySing ((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')) ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ • Relevant bindings include sX_6989586621679737266 :: Sing (Let6989586621679737265X_6989586621679737266Sym6 xs0_a33a0 t_a33aL ts_a33aM is_a33aO xs_a33fp r_a33fq) (bound at Bug.hs:1321:41) r_a33iK :: Sing r_a33fq (bound at Bug.hs:1295:57) xs_a33iJ :: Sing xs_a33fp (bound at Bug.hs:1295:48) lambda_a33iH :: Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) (bound at Bug.hs:1295:35) sR :: Sing arg_a33hi (bound at Bug.hs:1287:45) sXs :: Sing arg_a33hh (bound at Bug.hs:1287:41) sInterleave' :: forall (arg_a33he :: TyFun [a_a337f] c69895866216793215480 -> *) (arg_a33hf :: [a_a337f]) (arg_a33hg :: [c69895866216793215480]). Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33he) arg_a33hf) arg_a33hg) (bound at Bug.hs:1166:29) lambda_a33ha :: Sing t_a33aL -> Sing ts_a33aM -> Sing is_a33aO -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) arg_a33h1) (bound at Bug.hs:1153:23) sTs :: Sing n_a1kQd (bound at Bug.hs:1143:34) sT :: Sing n_a1kQc (bound at Bug.hs:1143:31) lambda_a33gY :: Sing xs0_a33a0 -> Sing (Apply PermutationsSym0 t_a33gX) (bound at Bug.hs:1127:11) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 1328 | sInterleave')) | ^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 21:40:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 21:40:54 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.9d93a561a12993119b0ed917396539d5@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 21:45:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 21:45:17 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.0f8ba31071d777baef94761a3c6a58de@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > I recently attempted to upgrade `singletons` to use GHC 8.2.1, but was > thwarted when GHC's typechecker rejected code that was generated by > Template Haskell. I was able to put all of this code in a single module > (which I've attached), but sadly, it's 1367 lines long. What's important > is that GHC 8.0.1 and 8.0.2 accept this code, but neither 8.2.1-rc1 nor > HEAD do. Here is the error message you get, in its full glory: > > {{{ > $ /opt/ghc/8.2.1/bin/ghci Bug.hs > GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Bug ( Bug.hs, interpreted ) > > Bug.hs:1328:59: error: > • Couldn't match type ‘c69895866216793215480’ with ‘[a_a337f]’ > ‘c69895866216793215480’ is untouchable > inside the constraints: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ > r_a33fq) > bound by the type signature for: > lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) > (r_a33fq :: [[a_a337f]]). > (arg_a33hh ~ xs_a33fp, arg_a33hi ~ > r_a33fq) => > Sing xs_a33fp > -> Sing r_a33fq > -> Sing > (Apply > (Apply > (Let6989586621679736980InterleaveSym4 > xs0_a33a0 t_a33aL > ts_a33aM is_a33aO) > arg_a33hh) > arg_a33hi) > at Bug.hs:(1289,35)-(1294,157) > Expected type: Sing t > -> Sing t1 > -> Sing t2 > -> Sing > (((Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM is_a33aO > @@ t) > @@ t1) > @@ t2) > Actual type: Sing t > -> Sing t1 > -> Sing t2 > -> Sing > (Apply > (Apply > (Apply > (Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO) > t) > t1) > t2) > • In the second argument of ‘singFun3’, namely ‘sInterleave'’ > In the first argument of ‘applySing’, namely > ‘((singFun3 > (Proxy :: > Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 > t_a33aL ts_a33aM is_a33aO))) > sInterleave')’ > In the first argument of ‘applySing’, namely > ‘((applySing > ((singFun3 > (Proxy :: > Proxy (Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) > sInterleave')) > ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ > • Relevant bindings include > sX_6989586621679737266 :: Sing > (Let6989586621679737265X_6989586621679737266Sym6 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO xs_a33fp r_a33fq) > (bound at Bug.hs:1321:41) > r_a33iK :: Sing r_a33fq (bound at Bug.hs:1295:57) > xs_a33iJ :: Sing xs_a33fp (bound at Bug.hs:1295:48) > lambda_a33iH :: Sing xs_a33fp > -> Sing r_a33fq > -> Sing > (Apply > (Apply > (Let6989586621679736980InterleaveSym4 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO) > arg_a33hh) > arg_a33hi) > (bound at Bug.hs:1295:35) > sR :: Sing arg_a33hi (bound at Bug.hs:1287:45) > sXs :: Sing arg_a33hh (bound at Bug.hs:1287:41) > sInterleave' :: forall (arg_a33he :: TyFun > [a_a337f] > c69895866216793215480 > -> *) (arg_a33hf :: > [a_a337f]) (arg_a33hg :: [c69895866216793215480]). > Sing arg_a33he > -> Sing arg_a33hf > -> Sing arg_a33hg > -> Sing > (Apply > (Apply > (Apply > (Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO) > arg_a33he) > arg_a33hf) > arg_a33hg) > (bound at Bug.hs:1166:29) > lambda_a33ha :: Sing t_a33aL > -> Sing ts_a33aM > -> Sing is_a33aO > -> Sing > (Apply > (Apply (Let6989586621679736931PermsSym1 > xs0_a33a0) arg_a33h0) > arg_a33h1) > (bound at Bug.hs:1153:23) > sTs :: Sing n_a1kQd (bound at Bug.hs:1143:34) > sT :: Sing n_a1kQc (bound at Bug.hs:1143:31) > lambda_a33gY :: Sing xs0_a33a0 > -> Sing (Apply PermutationsSym0 t_a33gX) > (bound at Bug.hs:1127:11) > (Some bindings suppressed; use -fmax-relevant-binds=N or -fno- > max-relevant-binds) > | > 1328 | > sInterleave')) > | > ^^^^^^^^^^^^ > > Bug.hs:1328:59: error: > • Could not deduce: Let6989586621679736980Interleave' > xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 > ~ > Let6989586621679736980Interleave' > xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 > from the context: t_a33gX ~ xs0_a33a0 > bound by the type signature for: > lambda_a33gY :: forall (xs0_a33a0 :: [a_a337f]). > t_a33gX ~ xs0_a33a0 => > Sing xs0_a33a0 -> Sing (Apply > PermutationsSym0 t_a33gX) > at Bug.hs:(1122,11)-(1126,67) > or from: arg_a33h0 ~ (n_a1kQc : n_a1kQd) > bound by a pattern with constructor: > SCons :: forall a_11 (z_a1kQb :: [a_11]) (n_a1kQc :: > a_11) (n_a1kQd :: [a_11]). > z_a1kQb ~ (n_a1kQc : n_a1kQd) => > Sing n_a1kQc -> Sing n_a1kQd -> Sing z_a1kQb, > in an equation for ‘sPerms’ > at Bug.hs:1143:25-36 > or from: (arg_a33h0 ~ Apply (Apply (:$) t_a33aL) ts_a33aM, > arg_a33h1 ~ is_a33aO) > bound by the type signature for: > lambda_a33ha :: forall (t_a33aL :: a_a337f) (ts_a33aM > :: [a_a337f]) (is_a33aO :: [a_a337f]). > (arg_a33h0 ~ Apply (Apply (:$) > t_a33aL) ts_a33aM, > arg_a33h1 ~ is_a33aO) => > Sing t_a33aL > -> Sing ts_a33aM > -> Sing is_a33aO > -> Sing > (Apply > (Apply > (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) > arg_a33h1) > at Bug.hs:(1145,23)-(1152,117) > or from: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) > bound by the type signature for: > lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) > (r_a33fq :: [[a_a337f]]). > (arg_a33hh ~ xs_a33fp, arg_a33hi ~ > r_a33fq) => > Sing xs_a33fp > -> Sing r_a33fq > -> Sing > (Apply > (Apply > (Let6989586621679736980InterleaveSym4 > xs0_a33a0 t_a33aL > ts_a33aM is_a33aO) > arg_a33hh) > arg_a33hi) > at Bug.hs:(1289,35)-(1294,157) > Expected type: Sing t > -> Sing t1 > -> Sing t2 > -> Sing > (((Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM is_a33aO > @@ t) > @@ t1) > @@ t2) > Actual type: Sing t > -> Sing t1 > -> Sing t2 > -> Sing > (Apply > (Apply > (Apply > (Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO) > t) > t1) > t2) > The type variable ‘c69895866216793215480’ is ambiguous > Use -fprint-explicit-kinds to see the kind arguments > • In the second argument of ‘singFun3’, namely ‘sInterleave'’ > In the first argument of ‘applySing’, namely > ‘((singFun3 > (Proxy :: > Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 > t_a33aL ts_a33aM is_a33aO))) > sInterleave')’ > In the first argument of ‘applySing’, namely > ‘((applySing > ((singFun3 > (Proxy :: > Proxy (Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) > sInterleave')) > ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ > • Relevant bindings include > sX_6989586621679737266 :: Sing > (Let6989586621679737265X_6989586621679737266Sym6 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO xs_a33fp r_a33fq) > (bound at Bug.hs:1321:41) > r_a33iK :: Sing r_a33fq (bound at Bug.hs:1295:57) > xs_a33iJ :: Sing xs_a33fp (bound at Bug.hs:1295:48) > lambda_a33iH :: Sing xs_a33fp > -> Sing r_a33fq > -> Sing > (Apply > (Apply > (Let6989586621679736980InterleaveSym4 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO) > arg_a33hh) > arg_a33hi) > (bound at Bug.hs:1295:35) > sR :: Sing arg_a33hi (bound at Bug.hs:1287:45) > sXs :: Sing arg_a33hh (bound at Bug.hs:1287:41) > sInterleave' :: forall (arg_a33he :: TyFun > [a_a337f] > c69895866216793215480 > -> *) (arg_a33hf :: > [a_a337f]) (arg_a33hg :: [c69895866216793215480]). > Sing arg_a33he > -> Sing arg_a33hf > -> Sing arg_a33hg > -> Sing > (Apply > (Apply > (Apply > (Let6989586621679736980Interleave'Sym4 > xs0_a33a0 t_a33aL ts_a33aM > is_a33aO) > arg_a33he) > arg_a33hf) > arg_a33hg) > (bound at Bug.hs:1166:29) > lambda_a33ha :: Sing t_a33aL > -> Sing ts_a33aM > -> Sing is_a33aO > -> Sing > (Apply > (Apply (Let6989586621679736931PermsSym1 > xs0_a33a0) arg_a33h0) > arg_a33h1) > (bound at Bug.hs:1153:23) > sTs :: Sing n_a1kQd (bound at Bug.hs:1143:34) > sT :: Sing n_a1kQc (bound at Bug.hs:1143:31) > lambda_a33gY :: Sing xs0_a33a0 > -> Sing (Apply PermutationsSym0 t_a33gX) > (bound at Bug.hs:1127:11) > (Some bindings suppressed; use -fmax-relevant-binds=N or -fno- > max-relevant-binds) > | > 1328 | > sInterleave')) > | > ^^^^^^^^^^^^ > }}} New description: I recently attempted to upgrade `singletons` to use GHC 8.2.1, but was thwarted when GHC's typechecker rejected code that was generated by Template Haskell. I was able to put all of this code in a single module (which I've attached), but sadly, it's 1367 lines long. What's important is that GHC 8.0.1 and 8.0.2 accept this code, but neither 8.2.1-rc1 nor HEAD do. Here is the error message you get, in its full glory: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -fprint-explicit-kinds GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:1328:59: error: • Couldn't match type ‘c69895866216793215480’ with ‘[a_a337f]’ ‘c69895866216793215480’ is untouchable inside the constraints: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) bound by the type signature for: lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) (r_a33fq :: [[a_a337f]]). (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) => Sing [a_a337f] xs_a33fp -> Sing [[a_a337f]] r_a33fq -> Sing [[a_a337f]] (Apply [[a_a337f]] [[a_a337f]] (Apply [a_a337f] (TyFun [[a_a337f]] [[a_a337f]] -> *) (Let6989586621679736980InterleaveSym4 [a_a337f] [a_a337f] a_a337f xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) at Bug.hs:(1289,35)-(1294,157) Expected type: Sing (TyFun [a_a337f] [a_a337f] -> *) t -> Sing [a_a337f] t1 -> Sing [[a_a337f]] t2 -> Sing ([a_a337f], [[a_a337f]]) ((@@) [[a_a337f]] ([a_a337f], [[a_a337f]]) ((@@) [a_a337f] ([[a_a337f]] ~> ([a_a337f], [[a_a337f]])) ((@@) (TyFun [a_a337f] [a_a337f] -> *) ([a_a337f] ~> ([[a_a337f]] ~> ([a_a337f], [[a_a337f]]))) (Let6989586621679736980Interleave'Sym4 [a_a337f] [a_a337f] a_a337f [a_a337f] xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) Actual type: Sing (TyFun [a_a337f] c69895866216793215480 -> *) t -> Sing [a_a337f] t1 -> Sing [c69895866216793215480] t2 -> Sing ([a_a337f], [c69895866216793215480]) (Apply [c69895866216793215480] ([a_a337f], [c69895866216793215480]) (Apply [a_a337f] ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480])) (Apply (TyFun [a_a337f] c69895866216793215480 -> *) ([a_a337f] ~> ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480]))) (Let6989586621679736980Interleave'Sym4 [a_a337f] [a_a337f] a_a337f c69895866216793215480 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) • In the second argument of ‘singFun3’, namely ‘sInterleave'’ In the first argument of ‘applySing’, namely ‘((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')’ In the first argument of ‘applySing’, namely ‘((applySing ((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')) ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ • Relevant bindings include sX_6989586621679737266 :: Sing ([a_a337f], [[a_a337f]]) (Let6989586621679737265X_6989586621679737266Sym6 [a_a337f] [a_a337f] a_a337f xs0_a33a0 t_a33aL ts_a33aM is_a33aO xs_a33fp r_a33fq) (bound at Bug.hs:1321:41) r_a33iK :: Sing [[a_a337f]] r_a33fq (bound at Bug.hs:1295:57) xs_a33iJ :: Sing [a_a337f] xs_a33fp (bound at Bug.hs:1295:48) lambda_a33iH :: Sing [a_a337f] xs_a33fp -> Sing [[a_a337f]] r_a33fq -> Sing [[a_a337f]] (Apply [[a_a337f]] [[a_a337f]] (Apply [a_a337f] (TyFun [[a_a337f]] [[a_a337f]] -> *) (Let6989586621679736980InterleaveSym4 [a_a337f] [a_a337f] a_a337f xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) (bound at Bug.hs:1295:35) sR :: Sing [[a_a337f]] arg_a33hi (bound at Bug.hs:1287:45) sXs :: Sing [a_a337f] arg_a33hh (bound at Bug.hs:1287:41) sInterleave' :: forall (arg_a33he :: TyFun [a_a337f] c69895866216793215480 -> *) (arg_a33hf :: [a_a337f]) (arg_a33hg :: [c69895866216793215480]). Sing (TyFun [a_a337f] c69895866216793215480 -> *) arg_a33he -> Sing [a_a337f] arg_a33hf -> Sing [c69895866216793215480] arg_a33hg -> Sing ([a_a337f], [c69895866216793215480]) (Apply [c69895866216793215480] ([a_a337f], [c69895866216793215480]) (Apply [a_a337f] ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480])) (Apply (TyFun [a_a337f] c69895866216793215480 -> *) ([a_a337f] ~> ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480]))) (Let6989586621679736980Interleave'Sym4 [a_a337f] [a_a337f] a_a337f c69895866216793215480 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33he) arg_a33hf) arg_a33hg) (bound at Bug.hs:1166:29) lambda_a33ha :: Sing a_a337f t_a33aL -> Sing [a_a337f] ts_a33aM -> Sing [a_a337f] is_a33aO -> Sing [[a_a337f]] (Apply [a_a337f] [[a_a337f]] (Apply [a_a337f] ([a_a337f] ~> [[a_a337f]]) (Let6989586621679736931PermsSym1 a_a337f xs0_a33a0) arg_a33h0) arg_a33h1) (bound at Bug.hs:1153:23) sTs :: Sing [a_a337f] n_a1kQd (bound at Bug.hs:1143:34) sT :: Sing a_a337f n_a1kQc (bound at Bug.hs:1143:31) lambda_a33gY :: Sing [a_a337f] xs0_a33a0 -> Sing [[a_a337f]] (Apply [a_a337f] [[a_a337f]] (PermutationsSym0 a_a337f) t_a33gX) (bound at Bug.hs:1127:11) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 1328 | sInterleave')) | ^^^^^^^^^^^^ Bug.hs:1328:59: error: • Could not deduce: (Let6989586621679736980Interleave' [a_a337f] [a_a337f] a_a337f c69895866216793215480 xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 :: ([a_a337f], [c69895866216793215480])) ~~ (Let6989586621679736980Interleave' [a_a337f] [a_a337f] a_a337f [a_a337f] xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 :: ([a_a337f], [c69895866216793215480])) from the context: t_a33gX ~ xs0_a33a0 bound by the type signature for: lambda_a33gY :: forall (xs0_a33a0 :: [a_a337f]). t_a33gX ~ xs0_a33a0 => Sing [a_a337f] xs0_a33a0 -> Sing [[a_a337f]] (Apply [a_a337f] [[a_a337f]] (PermutationsSym0 a_a337f) t_a33gX) at Bug.hs:(1122,11)-(1126,67) or from: arg_a33h0 ~ (':) a_a337f n_a1kQc n_a1kQd bound by a pattern with constructor: SCons :: forall a_11 (z_a1kQb :: [a_11]) (n_a1kQc :: a_11) (n_a1kQd :: [a_11]). z_a1kQb ~ (':) a_11 n_a1kQc n_a1kQd => Sing a_11 n_a1kQc -> Sing [a_11] n_a1kQd -> Sing [a_11] z_a1kQb, in an equation for ‘sPerms’ at Bug.hs:1143:25-36 or from: (arg_a33h0 ~ Apply [a_a337f] [a_a337f] (Apply a_a337f (TyFun [a_a337f] [a_a337f] -> *) ((:$) a_a337f) t_a33aL) ts_a33aM, arg_a33h1 ~ is_a33aO) bound by the type signature for: lambda_a33ha :: forall (t_a33aL :: a_a337f) (ts_a33aM :: [a_a337f]) (is_a33aO :: [a_a337f]). (arg_a33h0 ~ Apply [a_a337f] [a_a337f] (Apply a_a337f (TyFun [a_a337f] [a_a337f] -> *) ((:$) a_a337f) t_a33aL) ts_a33aM, arg_a33h1 ~ is_a33aO) => Sing a_a337f t_a33aL -> Sing [a_a337f] ts_a33aM -> Sing [a_a337f] is_a33aO -> Sing [[a_a337f]] (Apply [a_a337f] [[a_a337f]] (Apply [a_a337f] ([a_a337f] ~> [[a_a337f]]) (Let6989586621679736931PermsSym1 a_a337f xs0_a33a0) arg_a33h0) arg_a33h1) at Bug.hs:(1145,23)-(1152,117) or from: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) bound by the type signature for: lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) (r_a33fq :: [[a_a337f]]). (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) => Sing [a_a337f] xs_a33fp -> Sing [[a_a337f]] r_a33fq -> Sing [[a_a337f]] (Apply [[a_a337f]] [[a_a337f]] (Apply [a_a337f] (TyFun [[a_a337f]] [[a_a337f]] -> *) (Let6989586621679736980InterleaveSym4 [a_a337f] [a_a337f] a_a337f xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) at Bug.hs:(1289,35)-(1294,157) Expected type: Sing (TyFun [a_a337f] [a_a337f] -> *) t -> Sing [a_a337f] t1 -> Sing [[a_a337f]] t2 -> Sing ([a_a337f], [[a_a337f]]) ((@@) [[a_a337f]] ([a_a337f], [[a_a337f]]) ((@@) [a_a337f] ([[a_a337f]] ~> ([a_a337f], [[a_a337f]])) ((@@) (TyFun [a_a337f] [a_a337f] -> *) ([a_a337f] ~> ([[a_a337f]] ~> ([a_a337f], [[a_a337f]]))) (Let6989586621679736980Interleave'Sym4 [a_a337f] [a_a337f] a_a337f [a_a337f] xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) Actual type: Sing (TyFun [a_a337f] c69895866216793215480 -> *) t -> Sing [a_a337f] t1 -> Sing [c69895866216793215480] t2 -> Sing ([a_a337f], [c69895866216793215480]) (Apply [c69895866216793215480] ([a_a337f], [c69895866216793215480]) (Apply [a_a337f] ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480])) (Apply (TyFun [a_a337f] c69895866216793215480 -> *) ([a_a337f] ~> ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480]))) (Let6989586621679736980Interleave'Sym4 [a_a337f] [a_a337f] a_a337f c69895866216793215480 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) The type variable ‘c69895866216793215480’ is ambiguous • In the second argument of ‘singFun3’, namely ‘sInterleave'’ In the first argument of ‘applySing’, namely ‘((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')’ In the first argument of ‘applySing’, namely ‘((applySing ((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')) ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ • Relevant bindings include sX_6989586621679737266 :: Sing ([a_a337f], [[a_a337f]]) (Let6989586621679737265X_6989586621679737266Sym6 [a_a337f] [a_a337f] a_a337f xs0_a33a0 t_a33aL ts_a33aM is_a33aO xs_a33fp r_a33fq) (bound at Bug.hs:1321:41) r_a33iK :: Sing [[a_a337f]] r_a33fq (bound at Bug.hs:1295:57) xs_a33iJ :: Sing [a_a337f] xs_a33fp (bound at Bug.hs:1295:48) lambda_a33iH :: Sing [a_a337f] xs_a33fp -> Sing [[a_a337f]] r_a33fq -> Sing [[a_a337f]] (Apply [[a_a337f]] [[a_a337f]] (Apply [a_a337f] (TyFun [[a_a337f]] [[a_a337f]] -> *) (Let6989586621679736980InterleaveSym4 [a_a337f] [a_a337f] a_a337f xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) (bound at Bug.hs:1295:35) sR :: Sing [[a_a337f]] arg_a33hi (bound at Bug.hs:1287:45) sXs :: Sing [a_a337f] arg_a33hh (bound at Bug.hs:1287:41) sInterleave' :: forall (arg_a33he :: TyFun [a_a337f] c69895866216793215480 -> *) (arg_a33hf :: [a_a337f]) (arg_a33hg :: [c69895866216793215480]). Sing (TyFun [a_a337f] c69895866216793215480 -> *) arg_a33he -> Sing [a_a337f] arg_a33hf -> Sing [c69895866216793215480] arg_a33hg -> Sing ([a_a337f], [c69895866216793215480]) (Apply [c69895866216793215480] ([a_a337f], [c69895866216793215480]) (Apply [a_a337f] ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480])) (Apply (TyFun [a_a337f] c69895866216793215480 -> *) ([a_a337f] ~> ([c69895866216793215480] ~> ([a_a337f], [c69895866216793215480]))) (Let6989586621679736980Interleave'Sym4 [a_a337f] [a_a337f] a_a337f c69895866216793215480 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33he) arg_a33hf) arg_a33hg) (bound at Bug.hs:1166:29) lambda_a33ha :: Sing a_a337f t_a33aL -> Sing [a_a337f] ts_a33aM -> Sing [a_a337f] is_a33aO -> Sing [[a_a337f]] (Apply [a_a337f] [[a_a337f]] (Apply [a_a337f] ([a_a337f] ~> [[a_a337f]]) (Let6989586621679736931PermsSym1 a_a337f xs0_a33a0) arg_a33h0) arg_a33h1) (bound at Bug.hs:1153:23) sTs :: Sing [a_a337f] n_a1kQd (bound at Bug.hs:1143:34) sT :: Sing a_a337f n_a1kQc (bound at Bug.hs:1143:31) lambda_a33gY :: Sing [a_a337f] xs0_a33a0 -> Sing [[a_a337f]] (Apply [a_a337f] [[a_a337f]] (PermutationsSym0 a_a337f) t_a33gX) (bound at Bug.hs:1127:11) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 1328 | sInterleave')) | ^^^^^^^^^^^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 22:28:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 22:28:34 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.4cf27db8df5c0c0967fa2735a3c44b8d@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Commit 109a2429493c2a2d5481b67f5b0c1086a959813e caused this regression. Richard, might you have an idea of what's going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 22:42:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 22:42:45 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.ca0a36feaf3bced5355d74dd82135bc9@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 22:48:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 22:48:16 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 Message-ID: <050.34bdc46a060de8db94b04c524467a210@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13199 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The pretty-printed code which `-ddump-splices` has regressed since 8.0. If you compile this code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| type family Foo a b type instance Foo (Maybe a) b = Either (Maybe a) (Maybe b) data family Bar a b data instance Bar (Maybe a) b = BarMaybe (Maybe a) (Maybe b) |]) }}} with GHC 8.0.2, you get this: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(11,6): Splicing declarations [d| type family Foo_a13C a_a13G b_a13H data family Bar_a13B a_a13E b_a13F data instance Bar_a13B (Maybe a_a13I) b_a13J = BarMaybe_a13D (Maybe a_a13I) (Maybe b_a13J) type instance Foo_a13C (Maybe a_a13K) b_a13L = Either (Maybe a_a13K) (Maybe b_a13L) |] ======> type family Foo_a3O6 a_a3O9 b_a3Oa type instance Foo_a3O6 (Maybe a_a3Ob) b_a3Oc = Either (Maybe a_a3Ob) (Maybe b_a3Oc) data family Bar_a3O7 a_a3Od b_a3Oe data instance Bar_a3O7 (Maybe a_a3Of) b_a3Og = BarMaybe_a3O8 (Maybe a_a3Of) (Maybe b_a3Og) }}} Looks good. But in GHC 8.2.1, the output of `-ddump-splices` lacks many sets of parentheses which are necessary for correctness! {{{ GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(11,6): Splicing declarations [d| type family Foo_a1ty a_a1tC b_a1tD data family Bar_a1tx a_a1tA b_a1tB type instance Foo_a1ty (Maybe a_a1tG) b_a1tH = Either (Maybe a_a1tG) (Maybe b_a1tH) data instance Bar_a1tx (Maybe a_a1tE) b_a1tF = BarMaybe_a1tz (Maybe a_a1tE) (Maybe b_a1tF) |] ======> type family Foo_a4ia a_a4id b_a4ie type instance Foo_a4ia Maybe a_a4if b_a4ig = Either (Maybe a_a4if) (Maybe b_a4ig) data family Bar_a4ib a_a4ih b_a4ii data instance Bar_a4ib Maybe a_a4ij b_a4ik = BarMaybe_a4ic Maybe a_a4ij Maybe b_a4ik }}} This pops up both in the arguments to `type instance Foo ...` and `data instance Bar ...`, as well as the arguments to the data constructor `BarMaybe`. cc'ing alanz, since I suspect this is related to #13199. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 22:56:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 22:56:17 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.a94633054653dbad62f1a5d3c9c5af39@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cipher1024): * Attachment "Archive.zip" added. Isolated example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 8 23:01:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Apr 2017 23:01:10 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.5a3cad769f8612836eb1225f16565667@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): I just uploaded a restricted example. It is still 300 lines long. Is it helpful? I'll keep working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 00:03:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 00:03:39 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.41145dd457b4b66f01157c92217f9822@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Proofs2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 00:04:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 00:04:03 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.f01f300e9597ba21d7b6eaa0d532f9af@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thank you so much, cipher1024! That was tremendously helpful. I've attached a version with no dependencies. Sadly, it gives the same panic on GHC 8.2.1 and HEAD. However, it does //not// panic on GHC 7.10.3–I'll see which commit caused this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 01:16:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 01:16:47 -0000 Subject: [GHC] #13551: Support DEPRECATED and WARNING pragmas on Template Haskell Message-ID: <046.8214fb888c851366791de7713707655e@haskell.org> #13551: Support DEPRECATED and WARNING pragmas on Template Haskell -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm writing TH function from some JSON spec to Haskell data structures. Some fields are marked as deprecated in the spec, therefore I want to mark the accessors to those fields with DEPRECATED pragma, but as far as I can see, TH does not support this. I'm aware that module level DEPRECATED pragma is impossible in TH, but I still want to be able to tag top-level attributes as DEPRECATED. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 03:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 03:12:32 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.963c2c6ccffeca7279a7d75220e0027d@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonmar (added) Comment: Commit 8ecf6d8f7dfee9e5b1844cd196f83f00f3b6b879 (ApplicativeDo transformation) caused this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 04:15:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 04:15:39 -0000 Subject: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread In-Reply-To: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> References: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> Message-ID: <057.90295d05158ebba3318c6d9a6b4e484a@haskell.org> #5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): I'm getting this error too, in a different program (on some runs only), with GHC 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 05:11:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 05:11:31 -0000 Subject: [GHC] #13468: GHC stubbornly produces dead code for empty case with type family In-Reply-To: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> References: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> Message-ID: <060.bc2f6135575ed84464f448e4373f1708@haskell.org> #13468: GHC stubbornly produces dead code for empty case with type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | simplCore/should_compile/T13468 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 07:31:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 07:31:29 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.0e74e15f27e31cba6a88d740ca45a499@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): That's interesting. The LatexParser implements both Arrow and Applicative and I use the special Arrow notation. I wonder if the problem comes from the interplay between the arrow notation and the do notation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 08:34:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 08:34:21 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.1e1e34932b19e08cab0a701d2d5b3f1b@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 08:51:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 08:51:53 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.280432115ec87ba5008603925bce7e2c@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I just had a user reach out to me with this error being caused by an open type family that couldn't be reduced in a local setting, but which could be reduced elsewhere in the program where the extra type instance information was available. The irony here is the 'inaccessible' code was matching on a `Refl` to prove the existence of this type instance existed to the local context. Without this being reduced to a merely overly-enthusiastic warning that he can opt out of there is no way to fix the problem at present. A concrete example of code this currently cripples is the use of `Data.Constraint.Nat`. http://hackage.haskell.org/package/constraints-0.9.1/docs/Data-Constraint- Nat.html The user can't use the machinery provided therein to prove in a local context that, say `Gcd 3 6` is `3`. {{{#!hs {-# LANGUAGE GADTs, TypeApplications, DataKinds #-} import Data.Constraint import Data.Constraint.Nat import Data.Proxy import Data.Type.Equality import GHC.TypeLits foo = case sameNat (Proxy @3) (Proxy @(Gcd 3 6)) \\ gcdNat @3 @6 of Just Refl -> () }}} The `Refl` match there is being rejected as "Inaccessible code" despite the fact that if it was allowed to compile, it'd darn well get accessed! (This happens even if we weaken the closed type families in that module to open type families.) There isn't anything special about `Gcd` here. The same issue arises trying to write "userspace" proof terms about the (+) provided by GHC.TypeLits as if it were an uninterpreted function. This may be a case of this being a closely related error where GHC is being too eager to claim code inaccessible when it can't reduce a type family further in a local context, but its made into a crippling problem rather than a useless warning when combined with this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 08:56:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 08:56:01 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.277bc4221eb911bad15405731cf85ad9@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Note, {{{#!hs foo :: forall n m. (KnownNat n, KnownNat m) => Proxy n -> Proxy m -> Maybe (Dict (Divides n m)) foo = case sameNat (Proxy @n) (Proxy @(Gcd n m)) \\ gcdNat @n @m of Just Refl -> ... }}} works just fine. I'm guessing GHC is more willing to claim the case is inaccessible because there aren't any type variables in it, despite the fact that `Gcd` is a type family and the local context might not know all of the instances elsewhere in the program that could be used to construct such a (:~:). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 09:18:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 09:18:58 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 In-Reply-To: <050.34bdc46a060de8db94b04c524467a210@haskell.org> References: <050.34bdc46a060de8db94b04c524467a210@haskell.org> Message-ID: <065.9e170f2385d806019a34b1b2414f73cb@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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: #13199 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 10:53:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 10:53:54 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.3c10455e18ae1fd08719ed146c5df050@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I've built ghc-prof and found out GHC is most stressed in 'ErrUtils.getCaretDiagnostic' where source file is read from disk and then chunked by newlines. lexemeToString generates a lot of heap traffic as it decodes whole file into String. This example is enough to take more that 100M of stack: {{{#!hs {-# LANGUAGE PackageImports #-} module Main (main) where import qualified StringBuffer as SB main = do b <- SB.hGetStringBuffer "a.c" let s = SB.lexemeToString b (SB.len b) print (length $ lines s) }}} {{{ $ ghc --make a.hs -o a -package=ghc -debug -rtsopts $ ./a +RTS -K100M a: Stack space overflow: current size 33624 bytes. a: Use `+RTS -Ksize -RTS' to increase it. }}} Looks like there is 2 bugs here: - '''lexemeToString''' takes a lot of stack to decode StringBuffer into String - '''getCaretDiagnostic ''' could use more efficient mechanism to split file into lines before converting everything to String. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 12:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 12:31:27 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.c32c121e892655215f22f82559952606@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've no clue what's going on in that mess of code. Who would ever write such a thing? :) But I figured this out: if we force `do_kind_gen` on line 208 to be `True` always, the module compiles. I've now got to run, but my hunch is that the calculation of when types are closed is a bit off. Thanks for making an easy repro case and bisecting. That's invaluable! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 13:00:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 13:00:21 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.938ff133e5361c78db28d8cc2ff36442@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Rufflewind (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 13:32:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 13:32:56 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 In-Reply-To: <050.34bdc46a060de8db94b04c524467a210@haskell.org> References: <050.34bdc46a060de8db94b04c524467a210@haskell.org> Message-ID: <065.e6f210ced7fe54a1f5976516046a5782@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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: #13199 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Following the method in #13199 (output edited for clarity) {{{#!haskell *Bug Language.Haskell.TH> putStrLn $([d| type instance Foo (Maybe a) b = Either (Maybe a) (Maybe b) |] >>= stringE . show) [TySynInstD Bug.Foo (TySynEqn [AppT (ConT GHC.Base.Maybe) (VarT a_6989586621679027317) ,VarT b_6989586621679027318] (AppT (AppT (ConT Data.Either.Either) (AppT (ConT GHC.Base.Maybe) (VarT a_6989586621679027317) ) ) (AppT (ConT GHC.Base.Maybe) (VarT b_6989586621679027318)) ) ) ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 14:53:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 14:53:19 -0000 Subject: [GHC] #13552: Enum Float/Double does not match Haskell Report Message-ID: <043.39224a51148de8cb2d163535f2bb7bfa@haskell.org> #13552: Enum Float/Double does not match Haskell Report -------------------------------------+------------------------------------- Reporter: Luke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Section 6.3.4 of the report says that the `Enum` instance for `Float` and `Double` should define the `enumFromThen*` functions such that `enumFromThen e1 e2` is the list `[e1, e1 + i, e1 + 2i, ...]` where `i = e2 - e1`. The actual implementation in base is that of successive additions (which is approximately the same thing for some types). Successive additions causes issues with floating point rounding. Changing the definition to something like {{{#!hs enumFromThen_ e1 e2 = let i = e2 - e1 in map (\n -> e1 + n * i) [0..] }}} significantly improves the accuracy of floating point ranges, as well as **matching what the report says**. {{{ Prelude> last $ take 101 $ [0,0.1..] :: Float 10.000028 Prelude> last $ take 101 $ enumFromThen_ 0 0.1 :: Float 10.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 14:56:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 14:56:44 -0000 Subject: [GHC] #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs Message-ID: <050.5d31f2d5b2c6551b4fa57618c68943dd@haskell.org> #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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'm not exactly sure if this is the fault of `cpphs` or GHC, but I'll report this issue to GHC Trac for now, since (ostensibly) the only thing that has changed in this equation is the GHC version. Take this file: {{{#!hs {-# LANGUAGE CPP #-} module Bug where foo :: Int #if __GLASGOW_HASKELL__ >= 800 foo = 42 #else foo = "wrong type" #endif }}} Now let's compile it using `cpphs-1.20.4` as a preprocessor. With GHC 8.0, everything works out fine: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs -pgmP cpphs -optP --cpp Warning: Can't find file "/opt/ghc/8.0.2/lib/ghc-8.0.2/include/ghcversion.h" in directories Asked for by: Bug.hs at line 1 col 1 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) }}} But with GHC 8.2.1, things go awry: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs -pgmP cpphs -optP --cpp Warning: Can't find file "/opt/ghc/8.2.1/lib/ghc-8.2.0.20170403/include/ghcversion.h" in directories Asked for by: Bug.hs at line 1 col 1 [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:7: error: • Couldn't match expected type ‘Int’ with actual type ‘[Char]’ • In the expression: "wrong type" In an equation for ‘foo’: foo = "wrong type" | 8 | foo = "wrong type" | ^^^^^^^^^^^^ }}} This bug causes several libraries on Hackage which use `cpphs` as a preprocessor to fail when built with GHC 8.2.1, including `Agda`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 15:00:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 15:00:58 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.420ffa205c10b1ee0fc6ff1c45d2dc3d@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Slightly more context. '''utf8DecodeString''' overflows stack: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/utils/Encoding.hs#l118 {{{#!hs utf8DecodeString :: Ptr Word8 -> Int -> IO [Char] utf8DecodeString ptr len = unpack ptr where !end = ptr `plusPtr` len unpack p | p >= end = return [] | otherwise = case utf8DecodeChar# (unPtr p) of (# c#, nBytes# #) -> do chs <- unpack (p `plusPtr#` nBytes#) -- deep recursion return (C# c# : chs) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 15:08:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 15:08:29 -0000 Subject: [GHC] #12793: Performs unaligned access on SPARC64 In-Reply-To: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> References: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> Message-ID: <060.a4d86896a1adbcf45848cc10c3fd62c9@haskell.org> #12793: Performs unaligned access on SPARC64 ----------------------------------------+---------------------------------- Reporter: jrtc27 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: sparc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2661 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by slyfox): * status: patch => closed * resolution: => fixed Comment: That was merged a while ago. Resolving. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 16:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 16:12:32 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.68c59dc8607a77f1e2113163727c8579@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 16:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 16:18:47 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code Message-ID: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- Currently, it is very difficult to use the MySQL/MariaDB client library with Haskell. One must use bound threads, which comes at a performance penalty. The reason is that the underlying library requires a certain initialization function to be called on each OS thread before any other functions are called. Similarly, it is difficult to optimally use libcurl with GHC. The best- performing way to use libcurl is to have one multi handle per thread and to use `curl_multi_socket_action` to respond to events. This is currently not possible from Haskell, at least not easily. (There are other issues with using libcurl from Haskell; most notably libcurl’s event support makes heavy use of callbacks, which are slow, to tell the application which file descriptors to wait for. But that is a separate issue.) Setting milestone to 8.4.1 because I don’t think that this is difficult. This is a feature requ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 16:23:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 16:23:45 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.b130167b6a27c9999b3a85d88035bbb1@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 16:47:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 16:47:04 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.1459eff3a16eb102f5ff6a7cb7974e84@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) 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 Rufflewind): Strange that `utfDecodeString` returns `IO` but doesn’t call any `IO` functions besides `return`. As for `getCaretDiagnostic`, could perhaps revive this diff? https://phabricator.haskell.org/D2875 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 17:15:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 17:15:45 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.4a66b8565acdee74702032c0675fdf8c@haskell.org> #8816: Make SPARC registerised again. ------------------------------------+------------------------------ Reporter: kgardas | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Test Case: Blocked By: 8847 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------ Comment (by slyfox): To try NCG locally you don't even need to patch autoconf. That did the trick for me: {{{ $ ./configure --target=sparc-unknown-linux-gnu --disable-unregisterised $ make }}} Unfortunately NCG for sparc needs a few more fixes. 64-bit subtract inplementation: {{{ rts_dist_HC rts/dist/build/StgStartup.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170408 for sparc-unknown-linux): iselExpr64(sparc) I64[_c2::P32 + 64] - %MO_UU_Conv_W32_W64((Hp + 4) - I32[_c3::I32]) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/nativeGen/SPARC/CodeGen/Gen64.hs:196:6 in ghc:SPARC.CodeGen.Gen64 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Something fun in register allocator WRT PIC register: {{{ HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Types.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170408 for sparc-unknown-linux): SPARC.CodeGen.Base.getRegisterReg: global is in memory PicBaseReg Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/nativeGen/SPARC/CodeGen/Base.hs:103:21 in ghc:SPARC.CodeGen.Base }}} '''-fPIC''' is not really supported by NCG: {{{ rts_dist_HC rts/dist/build/Compact.thr_l_dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170408 for sparc-unknown-linux): MachCodeGen: sparc genSwitch PIC not finished CallStack (from HasCallStack): error, called at compiler/nativeGen/SPARC/CodeGen.hs:316:11 in ghc:SPARC.CodeGen }}} prof build is also broken in an interesting way: {{{ HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/Types.p_o /tmp/ghc26402_0/ghc_3.s: Assembler messages: /tmp/ghc26402_0/ghc_3.s:107:0: error: Error: can't resolve `iat6_str' {.rodata.str.iat6_str section} - `ghczmprim_GHCziTypes_HEqzusc_info' {.rodata.str.iat7_str section} | 107 | .long iat6_str-(ghczmprim_GHCziTypes_HEqzusc_info)+0 | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 17:18:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 17:18:31 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.464859c8edda0d99423fe7df22a5c2b9@haskell.org> #8816: Make SPARC registerised again. ------------------------------------+------------------------------ Reporter: kgardas | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Test Case: Blocked By: 8847 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------ Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 18:28:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 18:28:50 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.172b9637989747b50aee306060318e3b@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): I find it a bit confusing because the commit dates back to 2015 while literate-unitb worked with ghc-8.0.1 up until november 2016. I don't know when it stopped working but nobody built it in the last couple of months. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 18:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 18:41:27 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.e717e2b55072dd8e74604be8ddbd859a@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:16 cipher1024]: > I find it a bit confusing because the commit dates back to 2015 while literate-unitb worked with ghc-8.0.1 up until november 2016. I'm not sure what you mean by this, especially since the version of `Proofs2.hs` that I attached also panics with GHC 8.0.1. But moreover, it's important to note that you can't divide up GHC's commit history into discrete chunks corresponding to each GHC version. We operate by selectively merging commits from HEAD into release branches. So even though the `ApplicativeDo` patch was first committed back in 2015, it didn't actually appear in a major release (8.0) until much later, since we waited until we had made a couple of point releases for GHC 7.10 before putting new, breaking changes (including `ApplicativeDo`) in a major 8.0 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 19:01:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 19:01:12 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.9359a639fe6bf6119694eb190ef87590@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): Ok, I messed up. I was wrong. I thought it was building with ghc-8.0.1 but I think I was just using stack's lts-7 which normally uses ghc-8.0.1 but I didn't notice that I was specifying ghc-7.10.3. It's clearer now. I was assuming that there might be different releases of ghc-8.0.1 but, after realizing my mistaking, I'm thinking you probably have a single commit corresponding to each release. Am I correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 19:04:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 19:04:05 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.05f08a70414991ef0ae4358b3c979516@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:18 cipher1024]: > I was assuming that there might be different releases of ghc-8.0.1 but, after realizing my mistaking, I'm thinking you probably have a single commit corresponding to each release. Am I correct? Correct. Once we make a release, it's frozen. For instance, here's the commit corresponding to the GHC 8.0.1 release: http://git.haskell.org/ghc.git/commit/4986837f8168cacf95c24fecc84d7b36c47f3c11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 19:16:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 19:16:10 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 In-Reply-To: <050.34bdc46a060de8db94b04c524467a210@haskell.org> References: <050.34bdc46a060de8db94b04c524467a210@haskell.org> Message-ID: <065.c58fc3aef299ee9c92494b7b2b334272@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz 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: #13199 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"5282bb1772ba3f1dc999a177965e543822f342a0/ghc" 5282bb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5282bb1772ba3f1dc999a177965e543822f342a0" Parenthesize type/data families correctly for -ddump-splices Fix a regression in the pretty-printed code for -ddump-splices, which regressed since 8.0. Closes trac issue #13550 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 19:25:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 19:25:52 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 In-Reply-To: <050.34bdc46a060de8db94b04c524467a210@haskell.org> References: <050.34bdc46a060de8db94b04c524467a210@haskell.org> Message-ID: <065.0e4f72cf0f56cbfa3f37dde50aa1479d@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 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: #13199 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 19:44:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 19:44:06 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 In-Reply-To: <050.34bdc46a060de8db94b04c524467a210@haskell.org> References: <050.34bdc46a060de8db94b04c524467a210@haskell.org> Message-ID: <065.1ff0661edaa0cf255cb50df6a839d9b8@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 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: #13199 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge Comment: Awesome, thanks for the prompt fix, alanz! We should try to merge this into 8.2, if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 19:59:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 19:59:35 -0000 Subject: [GHC] #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs In-Reply-To: <050.5d31f2d5b2c6551b4fa57618c68943dd@haskell.org> References: <050.5d31f2d5b2c6551b4fa57618c68943dd@haskell.org> Message-ID: <065.870e80fbf0d742a2a9ba08e849ffe4b6@haskell.org> #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => upstream Comment: As it turns out, this is more of `cpphs`'s fault than GHC's. The commit which started all this is 351dea4a7c07f4e845eac6c2e895f6f41524b40c: {{{ From 351dea4a7c07f4e845eac6c2e895f6f41524b40c Mon Sep 17 00:00:00 2001 From: Herbert Valerio Riedel Date: Thu, 31 Dec 2015 16:58:28 +0100 Subject: [PATCH] Drop redundant `-D__GLASGOW_HASKELL__=...` flag In 3549c952b535803270872adaf87262f2df0295a4 a `include/ghcversions.h` include file was introduced which defines `__GLASGOW_HASKELL__` as well. So there's no need to define it twice. }}} So in theory, `cpphs-1.20.4` should just be reading `__GLASGOW_HASKELL__` from `include/ghcversions.h`. But I overlooked the warning that `cpphs-1.20.4` was emitting: {{{ Warning: Can't find file "/opt/ghc/8.2.1/lib/ghc-8.2.0.20170403/include/ghcversion.h" in directories }}} That's not good. In GHC 8.0.2, even though `cpphs` couldn't find `include/ghcversions.h`, it was able to find `__GLASGOW_HASKELL__` anyway by dumb luck, as `DriverPipeline` also (re-)defined it. But after 351dea4a7c07f4e845eac6c2e895f6f41524b40c, that is no longer the case, so if `cpphs` can't find `include/ghcversions.h`, we're hosed. This `cpphs` issue was reported upstream as https://github.com/malcolmwallace/cpphs/issues/11 a while back. There is a patch [https://raw.githubusercontent.com/jmitchell/cpphs-blackbox/master /avoid-using-findfile_-ghc-7_4-doesn_t-include-it_.dpatch here] which you can apply to the `cpphs` repo to fix the issue (I've confirmed that applying the patch makes GHC 8.2 work with `cpphs-1.20.4` again). So now we wait for a new release of `cpphs` with this fix... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 21:27:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 21:27:31 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.072a64ed473f70fdc56451be1ee1991a@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I bet `-dcore-lint` gives a much more helpful error message. Can you try that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 21:38:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 21:38:14 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.4c19850b8515ab398b38613a768d5a54@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Proofs2.core-lint" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 21:39:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 21:39:15 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.740221c4d59784f662ce2373b8b0d20a@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sure thing. Here's the relevant bit of Core Lint error from the file I've attached: {{{ [1 of 1] Compiling Document.Phase.Proofs2 ( Proofs2.hs, Proofs2.o ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the expression: ds_d7Cx @ (RawProgressProp, RuleProxy) @ (RawProgressProp, Proxy a_a6xa) @ VoidInference (ds_d7Cx @ (RawProgressProp, RuleProxy) @ ((RuleProxy, ()), RawProgressProp) @ (RawProgressProp, Proxy a_a6xa) (ds_d7Cw @ (RawProgressProp, RuleProxy) @ ((RuleProxy, ()), RawProgressProp) (\ (ds_d7CJ :: (RawProgressProp, RuleProxy)) -> case ds_d7CJ of { (goal_a58Y, prxy_a58Z) -> ((prxy_a58Z, ()), goal_a58Y) })) (ds_d7Cx @ ((RuleProxy, ()), RawProgressProp) @ (Cell1 Proxy RuleParser, RawProgressProp) @ (RawProgressProp, Proxy a_a6xa) (first @ (LatexParserT M) $fArrowLatexParserT @ (RuleProxy, ()) @ (Cell1 Proxy RuleParser) @ RawProgressProp (ds_d7Cx @ (RuleProxy, ()) @ RuleProxy @ (Cell1 Proxy RuleParser) (ds_d7Cw @ (RuleProxy, ()) @ RuleProxy (\ (ds_d7CH :: (RuleProxy, ())) -> case ds_d7CH of { (ds_d7CG, _ [Occ=Dead]) -> ds_d7CG })) (arr @ (LatexParserT M) $fArrowLatexParserT @ RuleProxy @ (Cell1 Proxy RuleParser) (view @ RuleProxy @ ((->) RuleProxy) @ (Cell1 Proxy RuleParser) ($fMonadReaderr(->) @ RuleProxy) (cell @ RuleProxy @ (Cell1 Proxy RuleParser) $fHasCellRuleProxyCell1 @ (Const (Cell1 Proxy RuleParser)) ($fFunctorConst @ (Cell1 Proxy RuleParser))))))) (ds_d7Cw @ (Cell1 Proxy RuleParser, RawProgressProp) @ (RawProgressProp, Proxy a_a6xa) (\ (ds_d7CZ :: (Cell1 Proxy RuleParser, RawProgressProp)) -> case ds_d7CZ of { (ds_d7CM, ds_d7CK) -> case ds_d7CM of { Cell @ a_a6xa _ [Occ=Dead] _ [Occ=Dead] prxy'_a590 -> (ds_d7CK, prxy'_a590) } })))) (ds_d7Cx @ (RawProgressProp, Proxy a_a6xa) @ ((RawProgressProp, Proxy a_a6xa), ()) @ VoidInference (ds_d7Cw @ (RawProgressProp, Proxy a_a6xa) @ ((RawProgressProp, Proxy a_a6xa), ()) (\ (ds_d7CD :: (RawProgressProp, Proxy a_a6xa)) -> (ds_d7CD, ()))) (ds_d7Cx @ ((RawProgressProp, Proxy a_a6xa), ()) @ (RawProgressProp, Inst1 Proxy RuleParser a_a6xa) @ VoidInference (ds_d7Cw @ ((RawProgressProp, Proxy a_a6xa), ()) @ (RawProgressProp, Inst1 Proxy RuleParser a_a6xa) (\ (ds_d7CC :: ((RawProgressProp, Proxy a_a6xa), ())) -> case ds_d7CC of { (ds_d7CB, _ [Occ=Dead]) -> case ds_d7CB of { (goal_a58Y, prxy'_a590) -> (goal_a58Y, Inst @ Proxy @ RuleParser @ a_a6xa $dTypeable_a6xl irred_a6xm prxy'_a590) } })) (stepList @ a_a6xa m_a58W))) @ a_a6xa is out of scope }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 22:44:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 22:44:28 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.39b0473f23b1f421914fd3a233b1d907@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I’ll add a note, and not set the call arity annotation. > > (Although it is debatable whether the simplifier is really innocent. The annotation is *true* even on join points; it is the simplifier that is stubbornly (but with good reason) refusing to eta-expand the join point!) I have a patch that does this, but I don’t like it. The Call Arity analysis uses the `idCallArity` fields internally as well (in particular `callArityRecEnv` reads it), and if I don’t set the Call Arity annotation, then things can go wrong. Some refactoring of the analysis could avoid this, of course, but given that the call arity annotation is not *wrong* on join points, I do not see the advantage of special-casing join-points here. Also zapping the call arity information in the simplifier is the right thing to do in any case. So the current state of affair seems fine with me. I did add a Note, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 22:44:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 22:44:44 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.4c518334aa1f7e3e92b5e5fb6cea363d@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"87377f74eec1567af741737b4b9034d06e3f0698/ghc" 87377f74/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="87377f74eec1567af741737b4b9034d06e3f0698" Add a Note [Call Arity and Join Points] as discussed in #13479. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 22:44:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 22:44:57 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.354c3605f55a2d07129cb4c70233301b@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 23:30:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 23:30:42 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds Message-ID: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `lol-0.6.0.0` from Hackage currently fails to build with GHC 8.2.1 because of this regression. Here is a minimized example: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MonoLocalBinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Crypto.Lol.Types.FiniteField (GF(..)) where import Data.Functor.Identity (Identity(..)) data T a type Polynomial a = T a newtype GF fp d = GF (Polynomial fp) type CRTInfo r = (Int -> r, r) type Tagged s b = TaggedT s Identity b newtype TaggedT s m b = TagT { untagT :: m b } class Reflects a i where value :: Tagged a i class CRTrans mon r where crtInfo :: Reflects m Int => TaggedT m mon (CRTInfo r) instance CRTrans Maybe (GF fp d) where crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) crtInfo = undefined }}} This typechecks OK with GHC 8.0.2, but with 8.2.1, it complains: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Crypto.Lol.Types.FiniteField ( Bug.hs, interpreted ) Bug.hs:25:14: error: • Couldn't match type ‘k0’ with ‘k2’ because type variable ‘k2’ would escape its scope This (rigid, skolem) type variable is bound by the type signature for: crtInfo :: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) at Bug.hs:25:14-79 Expected type: TaggedT m Maybe (CRTInfo (GF fp d)) Actual type: TaggedT m Maybe (CRTInfo (GF fp d)) • When checking that instance signature for ‘crtInfo’ is more general than its signature in the class Instance sig: forall (m :: k0). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) Class sig: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) In the instance declaration for ‘CRTrans Maybe (GF fp d)’ | 25 | crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:25:14: error: • Could not deduce (Reflects m Int) from the context: Reflects m Int bound by the type signature for: crtInfo :: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) at Bug.hs:25:14-79 The type variable ‘k0’ is ambiguous • When checking that instance signature for ‘crtInfo’ is more general than its signature in the class Instance sig: forall (m :: k0). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) Class sig: forall k2 (m :: k2). Reflects m Int => TaggedT m Maybe (CRTInfo (GF fp d)) In the instance declaration for ‘CRTrans Maybe (GF fp d)’ | 25 | crtInfo :: forall m . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notably, both `PolyKinds` and `MonoLocalBinds` are required to trigger this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 9 23:51:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Apr 2017 23:51:15 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.20ba9b5e253b8f8ffea0e89446e36eac@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3437 Comment: Ok, did it, and also added a test case for the problem we fixed. I put it up at Phab:D3437. I did not implement what’s suggested in comment:15. Can you open a new ticket for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 01:10:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 01:10:48 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.c71d37da6f65baed308ef8edca64d236@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: Commit 109a2429493c2a2d5481b67f5b0c1086a959813e caused this. Is this perhaps related to #13549? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 02:40:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 02:40:20 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.14d20fb8d347cd08e1fd2a191e0b9c3c@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with GHC here. The problem is that `UnT` takes `k` as a parameter. It does ''not'' look at the kind at which its argument is used and return something of that kind. So, in the type of `tunt`, the first `T` is applied at an unknown kind, which is also the return kind of `UnT`. Of course, you want this to be `Symbol`, but GHC doesn't know this. Adding a kind signature fixes the problem: {{{#!hs tunt :: Dict (T (UnT (T "a") :: Symbol) ~ T "a") tunt = Dict }}} Please close the ticket if you agree with my analysis. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 02:42:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 02:42:40 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.214e9f88a3e42f590eb0d9c4dfb32e04@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It's possible you want this behavior, though, which avoids the need for the kind signature: {{{#!hs type family UnTKind (a :: Type) :: Type where UnTKind (T (_ :: k)) = k type family UnT (a :: Type) :: UnTKind a where UnT (T t) = t tunt :: Dict (T (UnT (T "a")) ~ T "a") tunt = Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 03:45:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 03:45:25 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.4978d58516352b630ea4d15e2edfcf23@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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 goldfire): This smells very much like a dup of #13549, which I've not had more time to examine. Perhaps tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 07:05:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 07:05:15 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.a0411ab0eb84f6768b84b6dd987e55a6@haskell.org> #8816: Make SPARC registerised again. ------------------------------------+------------------------------ Reporter: kgardas | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Test Case: Blocked By: 8847 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------ Comment (by kgardas): Hi Sergei, I've just attached {{{git diff}}} in my sparc registerised build tree. It's really old, so probably bit rotted more or less but perhaps you may find it at least a little bit helpful. If I remember correctly, this was able to get GHC running and the majority of failures were caused by bug in show of double type -- hence my attempt to test this in bindisttest/HelloWorld.lhs. The issue was in register mapping while traversing calls from Haskell to C and back in showPrec function IIRC. Otherwise it kind of worked at least somehow. I'll not have time to resurrect my attempts on SPARC for a few upcoming months at least but would be glad if you can have a look at it. I'm surprised you are using sparc linux. I've thought Linux is not well supported on SPARC. My reference hence was always Solaris, but due to recent Oracle movements w.r.t. this OS I'm moving away from it to OpenBSD land... Thanks! Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 07:06:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 07:06:02 -0000 Subject: [GHC] #8816: Make SPARC registerised again. In-Reply-To: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> References: <046.8f4303f65c2a90c038068e79195aaef6@haskell.org> Message-ID: <061.af2ac1b8f67f1c726d5c453a075b3e11@haskell.org> #8816: Make SPARC registerised again. ------------------------------------+------------------------------ Reporter: kgardas | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: None/Unknown | Test Case: Blocked By: 8847 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+------------------------------ Changes (by kgardas): * Attachment "sparc-reg.diff" added. outdated SPARC NCG hacking diff -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 07:45:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 07:45:21 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.8a475cd974c112ea26fe16fd7c48a247@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonmar): @simonpj is that the correct ticket number? I don't see anything related in #10536 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 09:08:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 09:08:07 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.1dd84fbf412e91580cb76e23f67b46ee@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I did not realize that `k` is a parameter, now the error is clear to me. However, than the definition of `UnT` should be rejected, no? {{{#!hs type family UnT (a :: Type) :: k where UnT (T (t :: k')) = t }}} `UnT` has kind `forall k. Type -> k`, but in the clause `UnT (T t) = t` it returns something of the kind `k'`. There's no guarantee that `k ~ k'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 09:28:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 09:28:13 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.6883566c8225ade8d79eb786d969ade6@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 09:29:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 09:29:34 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.2ba448d3c3940f478fb5f9ec964434ff@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 09:32:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 09:32:05 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.4a9d0733165513f915e69ea18870d9c0@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sorry: corrected to #13536 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 10:43:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 10:43:14 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.9f9d72d5e7cf407505b05a5d88b0a5af@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here is a much smaller test case. Still a big mess of applicative do and arrows, neither of which I am familiar with, alas. {{{ {-# LANGUAGE Arrows #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} module Document.Phase.Proofs2 (step) where import Control.Applicative import Control.Arrow import Control.Category import Control.Monad import Data.Functor.Compose import Data.Maybe import Data.Proxy import Data.Typeable import GHC.Exts (Constraint) import Prelude hiding (id,(.)) data Inference rule data MachineP3 data RawProgressProp data Cell1 (f :: * -> *) (constr :: * -> Constraint) = forall a. (constr a, Typeable a) => Cell (f a) data Inst1 f constr a = (Typeable a,constr a) => Inst (f a) newtype RuleProxy = RuleProxy { _ruleProxyCell :: Cell1 Proxy RuleParser } type VoidInference = Cell1 (Compose Inference Proxy) RuleParser class Monad m => MonadReader r m | m -> r where instance MonadReader r ((->) r) where class RuleParser rule where type Lens' s a = Lens s s a a type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t type Getting r s a = (a -> Const r a) -> s -> Const r s class HasCell s a | s -> a where instance HasCell RuleProxy (Cell1 (Proxy :: * -> *) RuleParser) where data LatexParserA a g = LatexParserA instance Category LatexParserA where instance Arrow LatexParserA where ----------------------------- stepList :: MachineP3 -> LatexParserA (RawProgressProp,Inst1 Proxy RuleParser rule) VoidInference stepList m = error "urk" step :: MachineP3 -> LatexParserA (RawProgressProp,RuleProxy) VoidInference step m = insideOneEnvOf ["step","flatstep"] $ proc (goal,prxy) -> do Cell prxy' <- arr (view xcell) -< prxy stepList m -< (goal,Inst prxy') view :: MonadReader s m => Getting a s a -> m a view l = error "urk" insideOneEnvOf :: [String] -> LatexParserA a b -> LatexParserA a b insideOneEnvOf = error "urk" xcell :: HasCell s a => Lens' s a xcell = error "urk" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 10:45:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 10:45:45 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.0225250f139b05ed09aaeb9ab5abadc3@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: Resolution: | ApplicativeDo, Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ApplicativeDo, Arrows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 10:48:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 10:48:52 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.65e2df259cf8d961cb2a65d62369b9b8@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: ApplicativeDo, Arrows => Arrows Comment: Actually, it's nothing to do with applicative-do (that extension is not used). Is anyone familiar with arrows who can debug this? It fails with GHC 7.10 as well, so I'm not sure it ever worked... Maybe someone can cut it down still further... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 10:53:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 10:53:29 -0000 Subject: [GHC] #13547: ghc: panic! StgCmmEnv: variable not found In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.8cb71c42a57d921a953433ea94242865@haskell.org> #13547: ghc: panic! StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 10:54:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 10:54:00 -0000 Subject: [GHC] #13547: Lint error in arrows program (was: ghc: panic! StgCmmEnv: variable not found) In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.f90edfe8d78d9454eba91dfd86d9a8c9@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 11:29:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 11:29:49 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.a1d59376c2db5842057f561f4a0205bd@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:24 simonpj]: > It fails with GHC 7.10 as well, so I'm not sure it ever worked... What do you mean? It works fine with GHC 7.10.3: {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs -fforce-recomp [1 of 1] Compiling Document.Phase.Proofs2 ( Bug.hs, Bug.o ) Bug.hs:60:10: Warning: No explicit implementation for ‘id’ and ‘.’ In the instance declaration for ‘Category LatexParserA’ Bug.hs:61:10: Warning: No explicit implementation for ‘arr’ and ‘first’ In the instance declaration for ‘Arrow LatexParserA’ }}} Aside from some warnings, of course, which are due to minimizing the program down so much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 11:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 11:39:33 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.5fa9e841f2865479eb0c0acdad3322d2@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 11:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 11:42:15 -0000 Subject: [GHC] #13556: "Building and using Win32 DLLs" is dead link Message-ID: <045.bb76af5245641b224ed545542caa1235@haskell.org> #13556: "Building and using Win32 DLLs" is dead link -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.2 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: -------------------------------------+------------------------------------- https://wiki.haskell.org/GHC/Using_the_FFI Here the link "Building and using Win32 DLLs" is dead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 11:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 11:42:34 -0000 Subject: [GHC] #13556: "Building and using Win32 DLLs" is dead link In-Reply-To: <045.bb76af5245641b224ed545542caa1235@haskell.org> References: <045.bb76af5245641b224ed545542caa1235@haskell.org> Message-ID: <060.bbbe17e6e468dbd51d35e09be219d1dc@haskell.org> #13556: "Building and using Win32 DLLs" is dead link -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.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: | https://wiki.haskell.org/GHC/Using_the_FFI| -------------------------------------+------------------------------------- Changes (by varosi): * wikipage: => https://wiki.haskell.org/GHC/Using_the_FFI -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 11:43:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 11:43:29 -0000 Subject: [GHC] #13556: "Building and using Win32 DLLs" is dead link In-Reply-To: <045.bb76af5245641b224ed545542caa1235@haskell.org> References: <045.bb76af5245641b224ed545542caa1235@haskell.org> Message-ID: <060.bd6134c37ee06d7f81ee4c62e712eedd@haskell.org> #13556: "Building and using Win32 DLLs" is dead link -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.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: | https://wiki.haskell.org/GHC/Using_the_FFI| -------------------------------------+------------------------------------- Comment (by varosi): This link on the same page is dead, too "GHC user's manual section 8.2.1.1" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 11:44:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 11:44:33 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.67d85c31a5250e5fc80a6796da29905a@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): > Aside from some warnings, of course, which are due to minimizing the program down so much. With ghc-7.10.3, compiling with `-dcore-lint` I get a similar `Core Lint errors`. I have trimmed down the example further (see below). It seems to be a product of the interplay between existential types and arrow notation. The problem seems to come up because an existential type variable becomes free as a result of the following statement: {{{ Cell prxy' <- id -< prxy }}} After staring at it for a minute or so, I find that I cannot desugar the arrow notation in `step`. The obvious candidate is: {{{ step = id >>> arr (\(Cell prxy) -> prxy) >>> stepList }}} but the internal function `(\(Cell prxy) -> prxy)` cannot be given a type because of the existential type of `Cell`. Could this be related to the bug? ---- {{{ {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE Arrows #-} module Document.Phase.Proofs2 (step) where import Control.Arrow import Control.Category import Data.Proxy import Prelude hiding (id,(.)) data Cell1 = forall a. Cell (Proxy a) data LatexParserA a g = LatexParserA instance Category LatexParserA where instance Arrow LatexParserA where ----------------------------- stepList :: LatexParserA (Proxy rule) r stepList = error "urk" step :: LatexParserA Cell1 r step = proc prxy -> do Cell prxy' <- id -< prxy stepList -< prxy' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 12:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 12:14:16 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.0464a82cbc28109f3741e42d0b85b4ae@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Not quite. `UnT` really has kind `pi k. Type -> k`, because the `k` can be used in pattern-matching. The behavior of `UnT` is to reduce only when the (invisibly) provided `k` matches the kind of the argument of `T`. Unlike when defining ordinary functions, polymorphism in type families is ''not'' parametric. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 12:58:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 12:58:01 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.3bb006afb0871dda6420a131e68f2053@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Ok, so if I write {{{#!hs type family UnT (a :: Type) :: k where UnT (T (t :: k')) = t }}} the `k ~ k'` proof for the RHS is provided by the LHS. Can I write a LHS that will match on `t :: k'` for all kinds `k'` and try to unify `k ~ k'` only on the RHS? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:01:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:01:39 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.c1a759b4291ec1b2c32397e368a6d989@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:29:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:29:09 -0000 Subject: [GHC] #13556: "Building and using Win32 DLLs" is dead link In-Reply-To: <045.bb76af5245641b224ed545542caa1235@haskell.org> References: <045.bb76af5245641b224ed545542caa1235@haskell.org> Message-ID: <060.e511598690faa062651e3add36ff45f0@haskell.org> #13556: "Building and using Win32 DLLs" is dead link -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://wiki.haskell.org/GHC/Using_the_FFI| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Thanks. I've updated the links in https://wiki.haskell.org/index.php?title=GHC/Using_the_FFI&diff=61714&oldid=60411. Moreover, I've pointed them to the 8.0.2 users' guide in particular, so they shouldn't bitrot so easily in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:31:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:31:51 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case Message-ID: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ f :: [Char] f = [x | x <- ['a', 'b'], y <- (undefined:undefined:undefined:[]), z <- [1,2,3,4], r <- [True,False,True,False,True]] f' :: [Char] f' = [x | x <- ['a', 'b'], y <- (undefined:undefined:undefined:[]), z <- [1,2,3,4], r <- [True, False, True, False, True], s <- [_, _, _, _, _, _]] main :: IO () main = do print f print f' }}} When the code is compiled with the function {{{f}}} the result is the following:\\ {{{ "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" }}} If we add in {{{f}}} the code {{{s <- [_, _, _, _, _, _]}}} to become the function {{{f'}}} and then compile the program, the following error is displayed.\\ {{{ test11.hs:5:131: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:134: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:137: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:140: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:143: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:146: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) }}} I think that here the wildcard pattern _ is justified and does not have to give this error and must be used as undefined.\\ So this error makes no sense here.\\ I propose to make a correction in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:33:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:33:05 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.de7112398a31f858c2ec0fa5d521ce14@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've figured this out. The new behavior is correct; the old behavior was a bug. This is all to do with "let should not be generalized". With `TypeInType`, I extended that notion to the type level, saying that `MonoLocalBinds` implies that we should ''not'' perform kind generalization on type signatures that capture outer scoped type variables. This is the right behavior for precisely the same reasons it is at the term level: with local equalities on kinds and kind families, it's impossible to know how to generalize reliably. In GHC 8.0, the check for in-scope type variables was subtly wrong and missed unified `SigTv`s. The new check is correct, as far as I can tell. What's annoying here for users is that this a regression from 7.10, where `MonoLocalBinds` did not affect kind generalization. The good news is that the fix -- add a kind signature -- is fully backward-compatible. So, we could do either 1. Advertise this as a user-facing change (a bug-fix, really) and tell users to add kind signatures, or 2. Avoid the new logic with `-XNoTypeInType`. I prefer (1) because it's simpler, but not strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:34:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:34:28 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.7d8b1950b2708c0cb60db33b1a7c43a8@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType => Comment: I believe this is a dup of #13555, which is a tractable example. So let's work on that ticket first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:35:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:35:21 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.99707431bfc3fd3179f64a23d5039d54@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, when you say "add a kind signature", where in the above program should you add a kind signature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 13:59:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 13:59:56 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.7c6693fb102bfa497754a4210e9b0ffe@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 int-index]: > Ok, so if I write > > {{{#!hs > type family UnT (a :: Type) :: k where > UnT (T (t :: k')) = t > }}} > > the `k ~ k'` proof for the RHS is provided by the LHS. Roughly, yes. That instance (with kinds written explicitly) becomes `UnT k' (T k' t) = t`. So the pattern-matcher needs both kinds to be the same. > > Can I write a LHS that will match on `t :: k'` for all kinds `k'` and try to unify `k ~ k'` only on the RHS? I'm not sure what you mean here. Perhaps you're describing the type-family equivalent of the difference between {{{ instance C a a }}} and {{{ instance (a ~ b) => C a b }}} The former requires the two types to be the same, while the latter matches any types and then emits a constraint saying they're equal. If I understand your question correctly, then: no. Type families don't support that right now. Perhaps in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:13:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:13:04 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.2421a1fcfa2d673ff0d4f579865faf8d@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"b55f310d06b8d3988d40aaccc0ff13601ee52b84/ghc" b55f310d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b55f310d06b8d3988d40aaccc0ff13601ee52b84" StgCse: Do not re-use trivial case scrutinees as they might be marked as one-shot, and suddenly we’d evaluate them multiple times. This came up in #13536 (test cases included). The solution was layed out by SPJ in ticket:13536#comment:12. Differential Revision: https://phabricator.haskell.org/D3437 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:18:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:18:33 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.801fc3a67786cdbd4c6f945896beb378@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:21:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:21:27 -0000 Subject: [GHC] #13558: Inconsistency in `CoreUtils.exprIsOk` Message-ID: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> #13558: Inconsistency in `CoreUtils.exprIsOk` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 {{{ f1 = \x y -> let t = case x of True -> let v = Just y in (v, v) False -> (Nothing, Nothing) in \w -> t f2 = \x y -> let t = case x of True -> (Just y, Just y) False -> (Nothing, Nothing) in \w -> t }}} We give `f1` arity 1, but `f2` gets arity 2. That's bizarre, because all we've done is turn a `let` into a function application. Reason: in `CoreUtils.exprIsOk`, we recursively apply `go` in the `App` case, but we fail unconditionally in the `Let` case. That is simply inconsistent, and it bit me when trying something else. Incidentally `exprIsOk` is badly named. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:21:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:21:43 -0000 Subject: [GHC] #13558: Inconsistency in CoreUtils.exprIsOk (was: Inconsistency in `CoreUtils.exprIsOk`) In-Reply-To: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> References: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> Message-ID: <061.a57739ff11b6b637ef5d53e94a15408a@haskell.org> #13558: Inconsistency in CoreUtils.exprIsOk -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:24:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:24:37 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.66ffe199cb8d00e4ef35eb77cef90a94@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => merge Comment: But we should merge some fix here, surely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:26:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:26:19 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.b5d0235efe33b8bf741f505273785f38@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ah, probably, yes. Thanks for paying attention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:34:24 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.29e922af61371c0e8960ddc7e0972e50@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I suppose you mean in the instance signature: {{{#!hs instance CRTrans Maybe (GF fp d) where crtInfo :: forall (m :: k) . (Reflects m Int) => TaggedT m Maybe (CRTInfo (GF fp d)) crtInfo = undefined }}} i.e., changing `forall m` to `forall (m :: k)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 14:35:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 14:35:26 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.9680b29e816a6cf9ab4f33b99eb76972@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Also, does b55f310d06b8d3988d40aaccc0ff13601ee52b84 fix the program in comment:6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:02:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:02:13 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.f095008a45637699be60c54bfd7d571f@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): With my fix the program in comment:6 runs instantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:02:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:02:40 -0000 Subject: [GHC] #13546: Kind error with type equality In-Reply-To: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> References: <048.f52faa9b6e4bca4e1e275a23e7f1361e@haskell.org> Message-ID: <063.3e3f1d687424a11435c2f288f1eeed8d@haskell.org> #13546: Kind error with type equality -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | 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 int-index): Yes, the difference between `C a a` and `a~b => C a b` is what I meant. Thank you for explanations, very helpful! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:07:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:07:06 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.374c5e6b82c5092644f3f19808ab3886@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > With my fix the program in comment:6 runs instantly. So please let's add it as a regression test! (To HEAD at least.) Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:11:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:11:47 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.f2e6ab2ac3e6149f4c88e57a5e846f63@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd be happy with (1): let's add a user-manual section about kind generalisation, including saying when it does ''not'' happen. Who will do that; Richard? Also, is it enough to say {{{ crtInfo :: forall (m :: k) . (Reflects m Int) => ...blah... }}} or do we need {{{ crtInfo :: forall k (m :: k) . (Reflects m Int) => ...blah... }}} I think the former is ok, but is there a rule in the user manual that makes that clear? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:12:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:12:05 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.22fc55eadb2fb87697a70523983dce50@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T13536 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * testcase: => T13536 Comment: > So please let's add it as a regression test! (To HEAD at least.) Thanks. How do we robustly test whether a program is “fast”? I already did add a regression test that checks for the particular problem much more targetedly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:15:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:15:23 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.1392bad3613329b33d24a476ff871a08@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T13536 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Look at `perf/should_run` for examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:22:50 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.bd616efa73063854e4ffdf2b67999b0c@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T13536 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"ddc05912565aedd6ef46236906fa06cdb3e5e06c/ghc" ddc05912/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ddc05912565aedd6ef46236906fa06cdb3e5e06c" Add a second regression test for #13536 which counts allocations instead of observing recomputation directly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:24:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:24:09 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.c82df4316d69adc2bf5b33389451b5ae@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T13536 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Allright. I doubt it will pull its weight (allocation tests tend to slowly nudge out of the window, then require manual adjustment of the numbers), given that the existing test is more precise anyways, but here it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:30:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:30:17 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case In-Reply-To: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> References: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> Message-ID: <059.0516b07e39500a63f17f8a6963a40ead@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Here's a simplified version {{{ f' = [True | s <- [_, _]] }}} Here `_` is not a wildcard pattern, as you say. It's an underscore in an expression, which GHC treats as a wildcard ''expression''. See [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #typed-holes Typed Holes] in the user manual. I think this is correct behaviour. Re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:32:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:32:59 -0000 Subject: [GHC] #13552: Enum Float/Double does not match Haskell Report In-Reply-To: <043.39224a51148de8cb2d163535f2bb7bfa@haskell.org> References: <043.39224a51148de8cb2d163535f2bb7bfa@haskell.org> Message-ID: <058.5e645b11457c1782fc82cd51a3aa2521@haskell.org> #13552: Enum Float/Double does not match Haskell Report -------------------------------------+------------------------------------- Reporter: Luke | Owner: (none) Type: bug | 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 simonpj): Looks good to me. Would someone care to look at the library code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 15:55:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 15:55:19 -0000 Subject: [GHC] #12004: Windows unexpected failures In-Reply-To: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> References: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> Message-ID: <060.15d17c7f93a1e811092f040145abb219@haskell.org> #12004: Windows unexpected failures -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: None of these currently fail on HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 16:38:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 16:38:45 -0000 Subject: [GHC] #5466: Documentation for Chan could be better In-Reply-To: <046.e46c035a91971e631614cfca8496f79e@haskell.org> References: <046.e46c035a91971e631614cfca8496f79e@haskell.org> Message-ID: <061.ab81b174b44b8630ce6f9c9ae6548d19@haskell.org> #5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.2.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: | -------------------------------------+------------------------------------- Comment (by osa1): https://phabricator.haskell.org/D3439 maybe doesn't close this ticket but it's an improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 16:41:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 16:41:30 -0000 Subject: [GHC] #4154: Deadlock in Chan module In-Reply-To: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> References: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> Message-ID: <066.760f2aae257046cdc6019fe30db9dfb2@haskell.org> #4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.0.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | 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): It's been 7 years since `isEmptyChan` and `unGetChan` was deprecated (first release with deprecation seems to be 7.0). Should we delete them now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 16:48:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 16:48:16 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.6058ec6aacb725ab53b57bc058ac6c5d@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 16:59:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 16:59:07 -0000 Subject: [GHC] #13559: Remove LLVM/-fPIC check in DynFlags Message-ID: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> #13559: Remove LLVM/-fPIC check in DynFlags -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | 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 the LLVM backend was first implemented the implementation did not support `-fPIC` or `-dynamic`. Support for this was added in 60873542e8edf0ee593fde2b6544770d8036728f, which merely added the appropriate `-relocation-model` flag to the `opt` command line when compiling with `-fPIC`. However, the error message in `DynFlags.makeDynFlagsConsistent` remains for all but a select few platforms, {{{#!hs | hscTarget dflags == HscLlvm && not ((arch == ArchX86_64) && (os == OSLinux || os == OSDarwin || os == OSFreeBSD)) && not ((isARM arch) && (os == OSLinux)) && (gopt Opt_PIC dflags || WayDyn `elem` ways dflags) = if cGhcWithNativeCodeGen == "YES" then let dflags' = dflags { hscTarget = HscAsm } warn = "Using native code generator rather than LLVM, as LLVM is incompatible with -fPIC and -dynamic on this platform" in loop dflags' warn else throwGhcException $ CmdLineError "Can't use -fPIC or -dynamic on this platform" }}} Is this still necessary? If so, why? If not, we should remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 17:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 17:37:24 -0000 Subject: [GHC] #5466: Documentation for Chan could be better In-Reply-To: <046.e46c035a91971e631614cfca8496f79e@haskell.org> References: <046.e46c035a91971e631614cfca8496f79e@haskell.org> Message-ID: <061.04e37e17b1e37402b79333bb7c8d06a3@haskell.org> #5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.2.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: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"42ef0845d0d2a7cc524e7048502f651d66f6a543/ghc" 42ef0845/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42ef0845d0d2a7cc524e7048502f651d66f6a543" Improve `readChan` documentation: - Mention that the read end is an `MVar`, so fairness guarantees are inherited. - Mention that it can throw `BlockedIndefinitelyOnMVar` exception. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #5466 Differential Revision: https://phabricator.haskell.org/D3439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 17:42:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 17:42:52 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives In-Reply-To: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> References: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> Message-ID: <061.2e48ae870b2d78b9ba11396b492b4c9e@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: This ticket was intended to summarize the conversation we had last week during the GHC call. However, it sounds as though I failed to accurately capture the proposal and I've since paged all of this out. I'll go ahead and close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 17:56:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 17:56:54 -0000 Subject: [GHC] #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file Message-ID: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 GHC 8.2.1-rc1 binary distribution for Windows has the absolute path to `gcc` from the build environment in its `settings` file, {{{ ... ("C compiler command", "C:/msys64/home/drydock/bin- dist-8.2.0.20170404-MINGW64_NT-6.3/ghc/inplace/mingw/bin/gcc.exe"), ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 18:01:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 18:01:02 -0000 Subject: [GHC] #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file In-Reply-To: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> References: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> Message-ID: <061.25dc82be8f57071dfccd6238c21d32e6@haskell.org> #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is a regression due to 48385cb2fc295eb8af9188cbe140142c1807d5a7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 20:49:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 20:49:26 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.6c1ba43a0cc23c28793b068b9115828a@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Exceptions/StackTraces | -------------------------------------+------------------------------------- Changes (by bgamari): * wikipage: => Exceptions/StackTraces -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:00:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:00:01 -0000 Subject: [GHC] #13561: Remove unsafe Chan combinators Message-ID: <046.9b8c966d23c3a50c08be628b9e43df65@haskell.org> #13561: Remove unsafe Chan combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4154 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Namely `isEmptyChan` and `unGetChan`. See #4154. Let's delete them for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:00:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:00:26 -0000 Subject: [GHC] #4154: Deadlock in Chan module In-Reply-To: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> References: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> Message-ID: <066.b9cc8d1b5159bd9151a0c20f8adebd50@haskell.org> #4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | 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: 7.0.1 => 8.4.1 Old description: > The following program: > > {{{ > module Main where > > import Control.Concurrent > > main :: IO () > main = do > todo <- newChan > forkIO $ readChan todo > putStrLn "Before isEmptyChan" > b <- isEmptyChan todo > putStrLn "After isEmptyChan" > writeChan todo () > }}} > > Gives the output: > > {{{ > $ ghc --make Main.hs -threaded && ./Main.exe > Before isEmptyChan > Main.exe: thread blocked indefinitely in an MVar operation > }}} > > I think that's a bug. Note that if the {{{putStrLn}}} statements are > removed then it works, but I think that's because the printing introduces > a delay that lets the other thread run. New description: The following program: {{{#!hs module Main where import Control.Concurrent main :: IO () main = do todo <- newChan forkIO $ readChan todo putStrLn "Before isEmptyChan" b <- isEmptyChan todo putStrLn "After isEmptyChan" writeChan todo () }}} Gives the output: {{{ $ ghc --make Main.hs -threaded && ./Main.exe Before isEmptyChan Main.exe: thread blocked indefinitely in an MVar operation }}} I think that's a bug. Note that if the {{{putStrLn}}} statements are removed then it works, but I think that's because the printing introduces a delay that lets the other thread run. -- Comment: Indeed, let's delete them for 8.4. I've opened #13561 to make sure we don't forget this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:06:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:06:27 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.e3660dab08f59279ba9a9bc68c05c1b0@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | 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 Mon Apr 10 21:17:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:17:42 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.9cc0fb584180303edd4270f88cdde7a3@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It certainly sounds wrong for GHC to reject a branch as inaccessible (i.e. definitely cannot be executed) when it actually ''can'' be executed. Can you make an example that doesn't depend on relatively sophisticated package? I tried {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies, TypeApplications #-} module T11066 where import Data.Typeable type family F a foo:: Typeable (F Bool) => () foo = case eqT @Int @(F Bool) of Just Refl -> () _ -> () }}} thinking that GHC might claim that `F Bool ~ Int` is inaccesible; but it's accepted just fine. You do not say which version of the compiler you are using. A milder version of the problem is if the branch really is inaccessible, but you want to accept it anyway for some reason -- e.g. it's produced by `deriving`. But that is not what you are bothered about here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:20:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:20:16 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.7f378c36104d18909145fc601a71aca0@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks like a good diagnosis, thank you. Both problems are surely fixiable if someone cares to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:25:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:25:17 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.ef540ebc3d49f4989bed48067496d630@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (removed) * cc: Henrik.Nilsson@…, Ross, Paterson, (added) Comment: Thanks for boiling it down so much futher. I have only the vaguest idea about how arrow-desugaring works, but I think it's very likely that it won't work at all if there are existentials involved. Would an arrow expert care to give an opinion? Henrik? Ross? If so, we should reject it in a civilised way, not crash. Generally, arrows are sorely in need of love. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:26:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:26:52 -0000 Subject: [GHC] #13552: Enum Float/Double does not match Haskell Report In-Reply-To: <043.39224a51148de8cb2d163535f2bb7bfa@haskell.org> References: <043.39224a51148de8cb2d163535f2bb7bfa@haskell.org> Message-ID: <058.65d301b37f818e4b924126a73e3e6045@haskell.org> #13552: Enum Float/Double does not match Haskell Report -------------------------------------+------------------------------------- Reporter: Luke | Owner: (none) Type: bug | 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 bgamari): I'm rather confused, `GHC.Real.numericFrom` and friends (which the `Float` `Enum` instances use) claim that, {{{#!hs -- These 'numeric' enumerations come straight from the Report }}} Was the report changed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:28:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:28:05 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.b4b1edf820d869f45345e34ffc69eae0@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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 simonpj): Sounds plausible.. are you volunteering Matthew? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 21:31:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 21:31:31 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.038359157cf98b7d40546120e5e17ddf@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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 mpickering): * owner: (none) => mpickering Comment: Yes, and other refactorings around RnEnv. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 23:15:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 23:15:06 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.2ed683630f408f2636a3f5075be1ec0b@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Thanks Ben, I've just posted a diff moments before I saw this. I have abandoned your D3427 in favour of D3441. I see that you have removed my bash scripts. I'll remove them from D3441, let me know if you'd like me to make them available elsewhere. My github fork will not be a very reliable place to get them as it's likely to get rebased a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 23:31:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 23:31:53 -0000 Subject: [GHC] #13509: Perplexing type error with unboxed tuples In-Reply-To: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> References: <046.bbff5b6e4dafaa931a0ff9bb53f1dc6f@haskell.org> Message-ID: <061.c4365489feacf4617de9bf2e734a2e4e@haskell.org> #13509: Perplexing type error with unboxed tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 859dc65369e8a9722514046246dd32b683c8b4a9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 23:33:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 23:33:02 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.bf8f018ed8eff24f93eb2e61f053ad9b@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T13371 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This was merged in a920404fb12fb52a59e4f728cce4d662a418c5f8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 10 23:55:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Apr 2017 23:55:04 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.2a5b5d1352390c429fe86e8f2e8960ad@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) 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 bgamari): The issue with `utf8DecodeString` is that we need to decode all `len` characters before we can return; we cannot do the decoding lazily as the list is demanded since the `Ptr Word8` may be freed. Phab:D3442 adds such a variant.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 00:13:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 00:13:38 -0000 Subject: [GHC] #13542: Solaris build fails with collect2: execv: Arg list too long In-Reply-To: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> References: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> Message-ID: <061.5326a39bdfd26a1681189ac499c63e3d@haskell.org> #13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I suspect we can use `split-sections`; I tried bringing up a SmartOS VM to test this but unfortunately it fought back (the USB image is inexplicably unbootable). Someone else with access to this operating system will need to look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 00:14:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 00:14:34 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.90746145202351fffa3b732947bedb8a@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If we add a new closure type for `ByteArray#`, could it be used in runtime also? I'm not sure I follow the suggestion here. What do you mean by "used in the runtime"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 00:34:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 00:34:48 -0000 Subject: [GHC] #4154: Deadlock in Chan module In-Reply-To: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> References: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> Message-ID: <066.53f2e6a7c72c4d99ebd857c8db9da266@haskell.org> #4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | 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 mitar): What about my proposal: The only case where I have been using `isEmptyChan` was in my version of non-blocking `readChan`, returning Maybe. Is it possible to define instead of `isEmptyChan` some non-blocking version of `readChan` with `tryTakeMVar` and `tryPutMVar`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 01:37:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 01:37:46 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.afe61c8e2af8c3a9e2c8d228f03e8046@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cipher1024): What kind of attention do you think Arrows need? I haven't contributed to GHC before but if I can help with arrows I'd love to. In this particular situation, beside needing a more civilized error message, maybe we need a generalization of `ArrowChoice` for existential types so that we can make this design work: {{{ class Arrow arr => ArrowExist arr where existentially :: (forall a. constr a => arr (f a) b) -> arr (Cell1 f constr) b }}} with {{{ data Cell1 f (constr :: * -> Constraint) = forall a. (constr a, Typeable a) => Cell (f a) -- from https://hackage.haskell.org/package/existential }}} It might be overkill though. Looking back, maybe I'm overusing existential types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 02:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 02:22:19 -0000 Subject: [GHC] #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 In-Reply-To: <050.34bdc46a060de8db94b04c524467a210@haskell.org> References: <050.34bdc46a060de8db94b04c524467a210@haskell.org> Message-ID: <065.79c71daeaa4a31dcd2dcbc7fb7d22b0c@haskell.org> #13550: -ddump-splices doesn't parenthesize type/data families correctly in 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | 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: #13199 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` in #13550. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 02:23:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 02:23:28 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.c539f3b82e78d8a9841f2f826cd2d066@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T13536 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: comment:19 merged to `ghc-8.2` as 687e79fdf3d192cdc16bccb8b28eaec60ebb8abb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 02:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 02:34:54 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.ff02310374fa9aa115edc0ce9ec977b3@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): cipher1024, is my understanding of arrows correct in that the arrow notation you use in `step` would desugar down to something like this? {{{#!hs step :: LatexParserA Cell1 r step = arr (\prxy -> prxy) >>> id >>> arr (\(Cell prxy') -> prxy') >>> stepList }}} If so, the Core Lint error is somewhat understandable, as trying to typecheck that code simply won't work: {{{ Bug.hs:25:61: error: • Couldn't match type ‘rule0’ with ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Cell :: forall a. Proxy a -> Cell1, in a lambda abstraction at Bug.hs:25:46-55 Expected type: Proxy rule0 Actual type: Proxy a • In the expression: prxy' In the first argument of ‘arr’, namely ‘(\ (Cell prxy') -> prxy')’ In the first argument of ‘(>>>)’, namely ‘arr (\ (Cell prxy') -> prxy')’ • Relevant bindings include prxy' :: Proxy a (bound at Bug.hs:25:51) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 02:36:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 02:36:15 -0000 Subject: [GHC] #4154: Deadlock in Chan module In-Reply-To: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> References: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> Message-ID: <066.d55700c08373d7e05f3aa4cca8d301fa@haskell.org> #4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:9 mitar]: > What about my proposal: > > The only case where I have been using `isEmptyChan` was in my version of non-blocking `readChan`, returning Maybe. Is it possible to define instead of `isEmptyChan` some non-blocking version of `readChan` with `tryTakeMVar` and `tryPutMVar`? Out of curiosity, why not move to STM if you need these sorts of operations? I think the proposal is fine (assuming it's possible to implement safely; I am not familiar with the implementation of `Chan`). Do you want to put together a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 02:50:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 02:50:25 -0000 Subject: [GHC] #8025: -fno-code and Template Haskell are incompatible In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.28aa7e3858dcdd1aabf5ef5eacf26812@haskell.org> #8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): duog, if you could push the test scripts (or perhaps just the original patches) to a GitHub branch and include a link in the Diff description that would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 06:01:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 06:01:19 -0000 Subject: [GHC] #13542: Solaris build fails with collect2: execv: Arg list too long In-Reply-To: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> References: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> Message-ID: <061.6ae5a6c18e0abf9dbab75a86339ea79a@haskell.org> #13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kgardas): Just going thorough search of split-sections and SplitSection in the tree and general feeling about it is that the feature is supported only when GNU linker is used. This is unfortunately not the case on Solaris as Solaris gcc is using Solaris own linker: {{{ $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/lto- wrapper Target: i386-pc-solaris2.11 Configured with: /builds/hudson/workspace/nightly- update/build/i386/components/gcc48/gcc-4.8.2/configure CC=/usr/gcc/4.7/bin/gcc CXX=/usr/gcc/4.7/bin/g++ --prefix=/usr/gcc/4.8 --mandir=/usr/gcc/4.8/share/man --bindir=/usr/gcc/4.8/bin --libdir=/usr/gcc/4.8/lib --sbindir=/usr/gcc/4.8/sbin --infodir=/usr/gcc/4.8/share/info --libexecdir=/usr/gcc/4.8/lib --enable- languages=c,c++,fortran,objc --enable-shared --with-gmp- include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr --without- gnu-ld --with-ld=/usr/bin/ld --with-gnu-as --with-as=/usr/gnu/bin/as CFLAGS='-g -O2 -mtune=opteron -march=opteron' CXXFLAGS='-g -O2 -mtune=opteron -march=opteron' Thread model: posix gcc version 4.8.2 (GCC) }}} anyway, I'll give it a try and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 06:32:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 06:32:12 -0000 Subject: [GHC] #4154: Deadlock in Chan module In-Reply-To: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> References: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> Message-ID: <066.0fb1e4456b516afc4ab4e61cd913acde@haskell.org> #4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | 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 mitar): Not sure if I am able to do so either. :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 06:43:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 06:43:59 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.ae77d0c32a9aea80b83d5a065dab8a4e@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:66 bgamari]: > > If we add a new closure type for `ByteArray#`, could it be used in runtime also? > > I'm not sure I follow the suggestion here. What do you mean by "used in the runtime"? I mean can we change 'ByteArray#' 's representation into just length and content (removing the header)? I think that's not possible due to GC expect to see an uniform heap object representation, but i'm not sure there's no other way to make it work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:36:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:36:43 -0000 Subject: [GHC] #10582: Tiny bug in lexer around lexing banana brackets In-Reply-To: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> References: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> Message-ID: <062.19241202940f8366c10a36c14db24621@haskell.org> #10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T10582 Blocked By: 10583 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Arrows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:37:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:37:40 -0000 Subject: [GHC] #8505: Arrows example error In-Reply-To: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> References: <045.4a3e76cb1e6689edca76590e96afe352@haskell.org> Message-ID: <060.b5fa62d26fef4c307118b2c12115388c@haskell.org> #8505: Arrows example error -------------------------------------+------------------------------------- Reporter: pdfrod | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Arrows 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 simonpj): * keywords: => Arrows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:38:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:38:06 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.89e642271cf9b6d291c1a7b044035b68@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What kind of attention do you think Arrows need? I haven't contributed to GHC before but if I can help with arrows I'd love to Great! Check out [wiki:ArrowNotation]! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:39:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:39:26 -0000 Subject: [GHC] #7071: Refactoring arrows In-Reply-To: <046.c140bb566befc36cb79d89ecd2e1ddc5@haskell.org> References: <046.c140bb566befc36cb79d89ecd2e1ddc5@haskell.org> Message-ID: <061.181b06379e5347201d52c479b31e76f2@haskell.org> #7071: Refactoring arrows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Arrows 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: => Arrows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:40:15 -0000 Subject: [GHC] #5022: Core Lint error from polymorphic definitions inside arrow rec In-Reply-To: <053.9328f15b8439b9314d959ca6a63fc3c1@haskell.org> References: <053.9328f15b8439b9314d959ca6a63fc3c1@haskell.org> Message-ID: <068.83e28739302533bd51012d0087ddfa92@haskell.org> #5022: Core Lint error from polymorphic definitions inside arrow rec -----------------------------------+-------------------------------------- Reporter: serpentologist | Owner: ross Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.0.2 Resolution: fixed | Keywords: Arrows Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: arrows/T5022 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by simonpj): * keywords: infinite loop => Arrows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:40:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:40:30 -0000 Subject: [GHC] #5609: Type checking arrow notation in the presence of deferred constraints In-Reply-To: <046.67cacc702b2514fca6fbefb46506c412@haskell.org> References: <046.67cacc702b2514fca6fbefb46506c412@haskell.org> Message-ID: <061.20dfdd95a875f9dbcba22de86048df9a@haskell.org> #5609: Type checking arrow notation in the presence of deferred constraints -------------------------------------+------------------------------------- Reporter: dreixel | Owner: ross Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (Type | Version: 7.3 checker) | Resolution: fixed | Keywords: Arrows 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: => Arrows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 07:41:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 07:41:40 -0000 Subject: [GHC] #13547: Lint error in arrows program In-Reply-To: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> References: <049.0dfaf44680c98fe11eaef98359c2683d@haskell.org> Message-ID: <064.dcc99d0fcbf5525d824215e83ebe98c8@haskell.org> #13547: Lint error in arrows program -------------------------------------+------------------------------------- Reporter: cipher1024 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Arrows Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: 10158 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If so, the Core Lint error is somewhat understandable Yes, but if existentials are not valid in arrow notation, the typechecker should reject the program cleanly, rather than producing invalid Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 09:41:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 09:41:02 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.be051f688f0a1fac3cda95d379acb9ac@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I've checked the original big project with GHC 8.2.1-rc1 and based on non- scientific benchmarks, the problem is gone. BTW, the program also runs ~10% faster vs GHC 8.0.1, but I can't rule out it's caused by new versions of other packages, not just GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 09:55:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 09:55:01 -0000 Subject: [GHC] #4154: Deadlock in Chan module In-Reply-To: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> References: <051.0d3ab90ad06bb1efb3e03513e82edae2@haskell.org> Message-ID: <066.c982b07a21924b75601011523b1b7f81@haskell.org> #4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | 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): > Is it possible to define instead of isEmptyChan some non-blocking version of > readChan with tryTakeMVar and tryPutMVar? I think this can't work. A `readChan` is actually two `takeMVar`s. Implementation of `tryReadChan` has to use `tryTakeMVar`s, otherwise you can't avoid being blocked in some cases. So these two MVars that need to be taken to be able to read something off a chan need to be taken with `tryReadChan`. First `tryTakeMVar` would only succeed if the queue is empty. The trouble is in the case where the chan has enough stuff but currently some other thread is busy actually reading the contents (and updating the read-end) you'd get a `Nothing`, even though if you actually do `readChan` you'd get blocked for a very short amount of time because chan has enough contents. So this implementation would return `Nothing` in some cases when there is enough contents in the chan. Now suppose that you use `tryReadMVar` to read the read-end. Suppose that right after you read the read-end another thread does `readChan`, and takes the read-end MVar. Now there's a race condition between your thread and the other thread. The loser needs to re-take the read-end. Furthermore, if your thread was the only thread you can't update the read-end, because you didn't take it (remember that in this scenario we use `tryReadMVar` instead of `tryTakeMVar`). So neither `tryTakeMVar` nor `tryReadMVar` gives you a race-free implementation of `tryReadChan`. I hope this makes sense. (Another problem with both implementations is that you have no guarantees that you'll be able to read the contents. For example if chan has enough contents but a million threads are running `readChan` in parallel you may not be able to read anything with `tryReadChan`) `MVar`-based implementation is cute but has this limitation. (it also doesn't scale as number of writers and readers increase) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:25:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:25:24 -0000 Subject: [GHC] #13562: Avoid redundant MOVes in generated code Message-ID: <048.ea886325cb5e48fa8cfefd856efdb1f6@haskell.org> #13562: Avoid redundant MOVes in generated code --------------------------------------+--------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I stumbled upon this generated code: Everything is fine, a heap check like many others. {{{#!hs c2ro: Hp = Hp + 16; if (Hp > I64[BaseReg + 856]) goto c2rt; else goto c2rs; c2rt: I64[BaseReg + 904] = 16; I64[Sp - 48] = block_c2rp_info; I64[Sp - 40] = _s2pI::I64; I64[Sp - 32] = _s2pJ::I64; I64[Sp - 24] = _s2pK::I64; I64[Sp - 16] = _s2pN::I64; I64[Sp - 8] = _s2pO::I64; Sp = Sp - 48; call stg_gc_noregs() returns to c2rp, args: 8, res: 8, upd: 8; c2rp: _s2pI::I64 = I64[Sp + 8]; _s2pJ::I64 = I64[Sp + 16]; _s2pK::I64 = I64[Sp + 24]; _s2pN::I64 = I64[Sp + 32]; _s2pO::I64 = I64[Sp + 40]; Sp = Sp + 48; goto c2ro; c2rs: }}} Compiled to assembler: {{{#!asm _c2ro: addq $16,%r12 ; Heap check as usual cmpq 856(%r13),%r12 ja _c2rt _c2rs: ... _c2rt: movq $16,904(%r13) movq $block_c2rp_info,-48(%rbp) movq %r14,-40(%rbp) ; copy out sequence: move live variables movq %rsi,-32(%rbp) ; to stack movq %rax,-24(%rbp) movq %rbx,-16(%rbp) movq %rdi,-8(%rbp) addq $-48,%rbp jmp stg_gc_noregs ... .align 8 .quad 1989 .quad 32 block_c2rp_info: _c2rp: movq 8(%rbp),%rax ; we returned from gc land, now copy live variables back in movq 16(%rbp),%rbx movq 24(%rbp),%rcx movq 32(%rbp),%rdx movq 40(%rbp),%rsi addq $48,%rbp _n2st: ; Oh dear! We are moving our freshly moved register again for no obvious reason! movq %rsi,%rdi movq %rbx,%rsi movq %rdx,%rbx movq %rax,%r14 movq %rcx,%rax jmp _c2ro }}} What is happening here that GHC isn't able to directly assign the correct registers? Also the label `_n2st` suggest it is inserted at a later stage than the generated cmm code (Every other label is named contigously). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:25:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:25:44 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code Message-ID: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> #13563: Avoid redundant MOVes in generated code --------------------------------------+--------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I stumbled upon this generated code: Everything is fine, a heap check like many others. {{{#!hs c2ro: Hp = Hp + 16; if (Hp > I64[BaseReg + 856]) goto c2rt; else goto c2rs; c2rt: I64[BaseReg + 904] = 16; I64[Sp - 48] = block_c2rp_info; I64[Sp - 40] = _s2pI::I64; I64[Sp - 32] = _s2pJ::I64; I64[Sp - 24] = _s2pK::I64; I64[Sp - 16] = _s2pN::I64; I64[Sp - 8] = _s2pO::I64; Sp = Sp - 48; call stg_gc_noregs() returns to c2rp, args: 8, res: 8, upd: 8; c2rp: _s2pI::I64 = I64[Sp + 8]; _s2pJ::I64 = I64[Sp + 16]; _s2pK::I64 = I64[Sp + 24]; _s2pN::I64 = I64[Sp + 32]; _s2pO::I64 = I64[Sp + 40]; Sp = Sp + 48; goto c2ro; c2rs: }}} Compiled to assembler: {{{#!asm _c2ro: addq $16,%r12 ; Heap check as usual cmpq 856(%r13),%r12 ja _c2rt _c2rs: ... _c2rt: movq $16,904(%r13) movq $block_c2rp_info,-48(%rbp) movq %r14,-40(%rbp) ; copy out sequence: move live variables movq %rsi,-32(%rbp) ; to stack movq %rax,-24(%rbp) movq %rbx,-16(%rbp) movq %rdi,-8(%rbp) addq $-48,%rbp jmp stg_gc_noregs ... .align 8 .quad 1989 .quad 32 block_c2rp_info: _c2rp: movq 8(%rbp),%rax ; we returned from gc land, now copy live variables back in movq 16(%rbp),%rbx movq 24(%rbp),%rcx movq 32(%rbp),%rdx movq 40(%rbp),%rsi addq $48,%rbp _n2st: ; Oh dear! We are moving our freshly moved register again for no obvious reason! movq %rsi,%rdi movq %rbx,%rsi movq %rdx,%rbx movq %rax,%r14 movq %rcx,%rax jmp _c2ro }}} What is happening here that GHC isn't able to directly assign the correct registers? Also the label `_n2st` suggest it is inserted at a later stage than the generated cmm code (Every other label is named contigously). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:28:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:28:01 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code In-Reply-To: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> References: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> Message-ID: <063.9fbbd4350716b3eef1b9b6331e1eb512@haskell.org> #13563: Avoid redundant MOVes in generated code ---------------------------------+-------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by alexbiehl): I would upload the source file which triggers this behaviour but trac gives me an error when trying to upload an attachment. Please take a look here for `line.hs` https://gist.github.com/alexbiehl/a23238ddd0173e05b49a114c55105462 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:30:03 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code In-Reply-To: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> References: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> Message-ID: <063.ad75bf02de62d75fe8efcc363156e84c@haskell.org> #13563: Avoid redundant MOVes in generated code -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alexbiehl): * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:31:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:31:12 -0000 Subject: [GHC] #13562: Avoid redundant MOVes in generated code In-Reply-To: <048.ea886325cb5e48fa8cfefd856efdb1f6@haskell.org> References: <048.ea886325cb5e48fa8cfefd856efdb1f6@haskell.org> Message-ID: <063.b8d7fafab9ff39b92c4608c2901d2111@haskell.org> #13562: Avoid redundant MOVes in generated code ---------------------------------+-------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by alexbiehl): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:35:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:35:20 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code In-Reply-To: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> References: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> Message-ID: <063.7208eaa65e5b54a8e20c7b2255a0f0c0@haskell.org> #13563: Avoid redundant MOVes in generated code -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Is there another reference to `_n2st`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:38:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:38:12 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code In-Reply-To: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> References: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> Message-ID: <063.43b97d80b49d2fb774b19c63caab40fc@haskell.org> #13563: Avoid redundant MOVes in generated code -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): No, there is none. I can upload the whole cmm to the gist above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:39:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:39:56 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code In-Reply-To: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> References: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> Message-ID: <063.8ecaa43c8dbaa28ab9ec40b7cc1b12f4@haskell.org> #13563: Avoid redundant MOVes in generated code -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Better, can you include complete steps to reproduce? I don't see your snippet anywhere in the Cmm output with ghc-8.0.1 (I suppose it could depend on the exact ghc version, but doesn't seem too likely). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 11:41:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 11:41:34 -0000 Subject: [GHC] #13563: Avoid redundant MOVes in generated code In-Reply-To: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> References: <048.0d25d59a4046d4fef4ce0866923a1040@haskell.org> Message-ID: <063.db1faed5171d1d8a7525b7383da4467e@haskell.org> #13563: Avoid redundant MOVes in generated code -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I invoke ghc like this: `ghc line.hs -O -ddump-opt-cmm -fforce-recomp` ``` $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:13:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:13:05 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? Message-ID: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- I made GHC display the live data size before and after each pass and while compiling DynFlags, the live data size increased by almost 50% during the CoreTidy pass, even though the Core program size hardly changed: {{{ ... Result size of Simplifier = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Simplifier [DynFlags]: 19.69 221248736: finished in 5337.48 milliseconds, allocated 4416.624 megabytes *** Demand analysis [DynFlags]: 19.69 221248152: Result size of Demand analysis = {terms: 104,494, types: 264,683, coercions: 15,760, joins: 58/680} !!! Demand analysis [DynFlags]: 20.77 248604416: finished in 1349.45 milliseconds, allocated 2298.950 megabytes *** CoreTidy [DynFlags]: 20.77 248603432: Result size of Tidy Core = {terms: 104,440, types: 264,565, coercions: 15,700, joins: 58/679} !!! CoreTidy [DynFlags]: 21.43 342594336: finished in 1124.37 milliseconds, allocated 736.209 megabytes }}} I find the amount of this increase surprising considering what CoreTidy does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:13:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:13:13 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.73e289344cf95f003de015b0cb77ae66@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: (none) => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:14:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:14:45 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.05ffaacbaaf187912654b2dd3efd9724@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8048 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:14:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:14:52 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.93ffab782e1c35e5cb8718ffb5ca42dc@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen 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: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:15:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:15:03 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.4e59519a8bd99c19dc6f0bd64e489a05@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:16:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:16:01 -0000 Subject: [GHC] #9159: cmm case, binary search instead of jump table In-Reply-To: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> References: <048.5a9ba4411f8b6d8080451c778ed229cd@haskell.org> Message-ID: <063.256c5fb82231b2636884eabac5e38c49@haskell.org> #9159: cmm case, binary search instead of jump table -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10137 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:16:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:16:17 -0000 Subject: [GHC] #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF In-Reply-To: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> References: <044.0e2202ad2c3488eaeaa4c8d16ea90c28@haskell.org> Message-ID: <059.21202bc11a6baa6bffa3a63f087c9d4b@haskell.org> #8905: Function arguments are always spilled/reloaded if scrutinee is already in WHNF -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:16:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:16:23 -0000 Subject: [GHC] #8903: Add dead store elimination In-Reply-To: <044.457360c65e33571e0a4f71ea81733822@haskell.org> References: <044.457360c65e33571e0a4f71ea81733822@haskell.org> Message-ID: <059.87363fdba2d42390bc6890de6644f28d@haskell.org> #8903: Add dead store elimination -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:16:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:16:30 -0000 Subject: [GHC] #8903: Add dead store elimination In-Reply-To: <044.457360c65e33571e0a4f71ea81733822@haskell.org> References: <044.457360c65e33571e0a4f71ea81733822@haskell.org> Message-ID: <059.c243ebf41b4027c17860394f003b71c9@haskell.org> #8903: Add dead store elimination -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:16:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:16:44 -0000 Subject: [GHC] #8887: Double double assignment in optimized Cmm on SPARC In-Reply-To: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> References: <046.7dd6ce694dc9c9f0e18236436c35d4a8@haskell.org> Message-ID: <061.8af8a658021f94c9bbea74b05085a8b7@haskell.org> #8887: Double double assignment in optimized Cmm on SPARC -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Solaris | Architecture: sparc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:16:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:16:55 -0000 Subject: [GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm In-Reply-To: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> References: <046.9e3184b9c42741faf5afebe36355ed9b@haskell.org> Message-ID: <061.8717e7bb1f6379f1eb7a2cdadec5870d@haskell.org> #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:17:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:17:04 -0000 Subject: [GHC] #8585: Loopification should omit stack check In-Reply-To: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> References: <048.357f98b67b6c2b39906af5ad1988d2df@haskell.org> Message-ID: <063.fbb9d6df6d42f4d6249f0618c3e0545f@haskell.org> #8585: Loopification should omit stack check -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:17:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:17:20 -0000 Subject: [GHC] #11372: Loopification does not trigger for IO even if it could In-Reply-To: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> References: <046.4171329d8e8db02482a2f76b8e0a9e8a@haskell.org> Message-ID: <061.d53c9192694a48dadbb718171dcf79a7@haskell.org> #11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, Resolution: fixed | loopification, code generation, | CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1767 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: cmm, loopification, code generation => cmm, loopification, code generation, CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:18:12 -0000 Subject: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors In-Reply-To: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> References: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> Message-ID: <061.924dac0736660d5fed28172625efdd14@haskell.org> #2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 12:18:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 12:18:29 -0000 Subject: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust In-Reply-To: <045.e33af6968458760182e141457b350018@haskell.org> References: <045.e33af6968458760182e141457b350018@haskell.org> Message-ID: <060.abf772338b1e0ae009fec9c1935cd80f@haskell.org> #4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: CodeGen 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: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 13:12:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 13:12:41 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.b3d85cf2cd866a9a3876db6136dc0803@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It seems to me we want a way to write a `ByteArray#` literal, without forcing every string literal to be compiled to a `ByteArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 13:22:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 13:22:34 -0000 Subject: [GHC] #13561: Remove unsafe Chan combinators In-Reply-To: <046.9b8c966d23c3a50c08be628b9e43df65@haskell.org> References: <046.9b8c966d23c3a50c08be628b9e43df65@haskell.org> Message-ID: <061.5fed8923f033395da2b7ffc7b672b201@haskell.org> #13561: Remove unsafe Chan combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4154 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): It seems like some of GHC's dependencies use those functions (e.g. `haskeline` uses `isEmptyChan`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 13:26:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 13:26:01 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives In-Reply-To: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> References: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> Message-ID: <061.86deebd207d57635cc543877618a927d@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 rwbarton): * status: closed => new * resolution: invalid => Comment: This was not about algebraic cases but primitive cases, for example on `Int#`. As far as I know the only situation where this will arise is when transforming {{{#!hs case tagToEnum# (x ==# y) of { False -> ... True -> ... } }}} to {{{#!hs case x ==# y of { 0# -> ... 1# -> ... } }}} By using `0#` and `1#` rather than `1#` (or `0#`) and `__DEFAULT` we could convey to the backend the information that the scrutinee is guaranteed to evaluate to either 0 or 1. With just two cases this probably doesn't matter, but when there are many cases we'd like to generate a jump table and if we know the scrutinee is guaranteed to be in-range then we can skip range checks. For an example usage, see `toChunk3#` in the attachment to #9159. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 13:41:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 13:41:08 -0000 Subject: [GHC] #13523: Be more explicit in generated case alternatives In-Reply-To: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> References: <046.de4d88bceb45e1a7cfd0334fc2e28195@haskell.org> Message-ID: <061.8ceaedd2a0d606ad03ed9c2943075654@haskell.org> #13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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): Do this on the branch on #13397, which we still need to commit, after double-checking perf. (Might you do that Reid?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 13:43:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 13:43:16 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case In-Reply-To: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> References: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> Message-ID: <059.6d08ca0ada410332e85298af98bc86e7@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: closed => new * resolution: invalid => Comment: Reply to simonpj.\\ Thanks.\\ I reopen this ticket in order to bring clarity to what I mean. "... The goal of typed holes is to help with writing Haskell code rather than to change the type system..." \\ I agree with Typed Holes. Here I would like to point out a matter of logical sense. {{{f' = [True | s <- [_, _]]}}} immediately raise an error. This behaviour is in conformity. Of course. But it is not necessarily correct. It will be noted that it is a single function in this context. But if {{{f'}}}is written in {{{f}}} at the end of other functions, this error has no logical sense.\\ Consider {{{undefined}}}. {{{g = [r | r <- [undefined, undefined]]}}}. the result is {{{Exception: Prelude.undefined}}}.\\ But if {{{g = [1 | r <- [undefined, undefined]]}}} the result is {{{[1,1]}}}.\\ It is as if there was no computation of {{{undefined}}}.\\ We can have the same effect if we have functions in the list as:\\ {{{h = [1 | r <- [(\x -> x*3), (\y -> y+1)]]}}}.\\ \\ Here, the function {{{f'}}} write at the end of the function {{{f}}} should play the same behaviour from a logical point of view.\\ It should also be noted that the error happens right away.\\ If the error was delayed the function {{{f'}}} would behave as with {{{undefined}}}.\\ Perhaps it is here that we must change the behavior where the error occurs?\\ In fact, it's a bit like if GHC would produce the error during the reading of {{{_}}} from the list as {{{[_, _]}}} instead of producing the error during the computation of {{{_}}}. \\ Do you understand?\\ And what do others think?\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 14:55:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 14:55:55 -0000 Subject: [GHC] #13559: Remove LLVM/-fPIC check in DynFlags In-Reply-To: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> References: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> Message-ID: <061.6d0a6ad75ab44e6cf6843996b88126a5@haskell.org> #13559: Remove LLVM/-fPIC check in DynFlags -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: 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): I'll push a diff tomorrow that removes that code, as well as some other iOS specific annoyance. I'll also try to do some additional testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 15:25:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 15:25:29 -0000 Subject: [GHC] #13561: Remove unsafe Chan combinators In-Reply-To: <046.9b8c966d23c3a50c08be628b9e43df65@haskell.org> References: <046.9b8c966d23c3a50c08be628b9e43df65@haskell.org> Message-ID: <061.8f4f8e14cf3d87eef939cda270ab8277@haskell.org> #13561: Remove unsafe Chan combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4154 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): See https://github.com/judah/haskeline/pull/61/files for a fix for haskeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 15:37:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 15:37:13 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.fbf948a6fc2163c58eb15d9cb48201f4@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I mean can we change ByteArray# 's representation into just length and content (removing the header)? I don't believe this is possible; as you point out, the garbage collecting needs the info table pointer. > It seems to me we want a way to write a `ByteArray#` literal, without forcing every string literal to be compiled to a `ByteArray#`. I agree; I can see the value in wanting a `ByteArray#` literal, but making all primitive strings `ByteArray#`s seems like a step too far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 16:00:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 16:00:32 -0000 Subject: [GHC] #13419: Testing. In-Reply-To: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> References: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> Message-ID: <061.466a2d8f26e0a9ae34773480e0cc5f07@haskell.org> #13419: Testing. -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > This is only a test. New description: This is only a test! Another test. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 16:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 16:07:42 -0000 Subject: [GHC] #13419: Testing. In-Reply-To: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> References: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> Message-ID: <061.123aadca96b4fd26a2e2e5d50118b700@haskell.org> #13419: Testing. -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > This is only a test! > > Another test. New description: This is just a test. Another test. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 16:11:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 16:11:33 -0000 Subject: [GHC] #13419: Testing. In-Reply-To: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> References: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> Message-ID: <061.37b080a0bfd119ff7999869204ff7d3b@haskell.org> #13419: Testing. -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,0 +3,2 @@ + Hmmm + New description: This is just a test. Hmmm Another test. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 17:29:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 17:29:50 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.7bdee7fe75d0d3363570d680e58c64db@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): It looks like we have to make a space-time trade off here, if `ByteArray#` 's overhead is too large, adding a `Int#` will also cost a lot. Suppose GHC is smart enough to float all string constant out, then copying once in runtime is acceptable. Otherwise i would still want to switch space for time. Here i also propose another solution: We still keep primitive literal's type as `Addr#`, but encode the literal's byte length with UTF8 rules, that is using one byte for length less than 0x7F, two bytes for length less than 0x7FF...and so on. Then put these UTF8 encoded length header bytes in front of real bytes content. Now all we have to do left is to add a new unpack function `unpackGHCString#` to decode these header bytes first(we can reuse UTF8 code!!!), then use `memcpy` or whatever you want to do with length info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 20:11:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 20:11:41 -0000 Subject: [GHC] #13542: Solaris build fails with collect2: execv: Arg list too long In-Reply-To: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> References: <046.6dd80a42580bb9fbee452f7746b0ca98@haskell.org> Message-ID: <061.8d446a7e1f5b7eae44a7638a99766a31@haskell.org> #13542: Solaris build fails with collect2: execv: Arg list too long -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Solaris | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kgardas): I've done simple test and where the compilation failed with the error above I've replaced -split-objs with -split-sections and repeated the step and then continue with `gmake`. This way I've been able to build GHC HEAD on Solaris 11.2 but only with patch below applied. I guess nobody test on Solaris so no-flock condition is kind of broken, the error is: {{{ libraries/base/GHC/IO/Handle/Lock.hsc:159:20: error: <80>� Variable not in scope: throwIO :: FileLockingNotSupported -> IO Bool <80>� Perhaps you meant <80><98>throw<80><99> (imported from GHC.Exception) | 159 | lockImpl _ _ _ _ = throwIO FileLockingNotSupported | ^^^^^^^ gmake[1]: *** [libraries/base/dist-install/build/GHC/IO/Handle/Lock.o] Error 1 }}} and my naive patch is: {{{ diff --git a/libraries/base/GHC/IO/Handle/Lock.hsc b/libraries/base/GHC/IO/Handle/Lock.hsc index 5608c18..3ef19f7 100644 --- a/libraries/base/GHC/IO/Handle/Lock.hsc +++ b/libraries/base/GHC/IO/Handle/Lock.hsc @@ -48,6 +48,10 @@ import GHC.Ptr import GHC.Real import GHC.Windows +#else + +import Control.Exception + #endif import Data.Functor }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 11 20:27:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Apr 2017 20:27:09 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code In-Reply-To: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> References: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> Message-ID: <062.16b629e501c6e1ad50c43c743c6330f8@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -19,1 +19,1 @@ - This is a feature requ + This is a feature request. New description: Currently, it is very difficult to use the MySQL/MariaDB client library with Haskell. One must use bound threads, which comes at a performance penalty. The reason is that the underlying library requires a certain initialization function to be called on each OS thread before any other functions are called. Similarly, it is difficult to optimally use libcurl with GHC. The best- performing way to use libcurl is to have one multi handle per thread and to use `curl_multi_socket_action` to respond to events. This is currently not possible from Haskell, at least not easily. (There are other issues with using libcurl from Haskell; most notably libcurl’s event support makes heavy use of callbacks, which are slow, to tell the application which file descriptors to wait for. But that is a separate issue.) Setting milestone to 8.4.1 because I don’t think that this is difficult. This is a feature request. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 03:27:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 03:27:20 -0000 Subject: [GHC] #13565: Compiler allocations on sched in nofib regressed by 10% between 091333313 and 1883afb2 Message-ID: <046.bc82a90fee6da6b730dc5caece616231@haskell.org> #13565: Compiler allocations on sched in nofib regressed by 10% between 091333313 and 1883afb2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Compiler allocations increased from 500MB to 550MB on the `Main` module of `sched` somewhere between 09333313f32be975faf9158fcd3648489d78ad82 and 03e8d26fe0a8f7981a76550118f3c584cad76c47. Investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 03:31:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 03:31:34 -0000 Subject: [GHC] #13138: Clean up ghc-pkg validation warnings in build log In-Reply-To: <049.ca50dc09c6b5bdc241ded49d456bf621@haskell.org> References: <049.ca50dc09c6b5bdc241ded49d456bf621@haskell.org> Message-ID: <064.4a35aaa6fdd61f68e72b5bdcb58edf31@haskell.org> #13138: Clean up ghc-pkg validation warnings in build log -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by asr): How can I reproduce that build log? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 05:39:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 05:39:28 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.d33ab8fe8e69ceebcca4724da324f113@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * cc: winter (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 07:33:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 07:33:19 -0000 Subject: [GHC] #13138: Clean up ghc-pkg validation warnings in build log In-Reply-To: <049.ca50dc09c6b5bdc241ded49d456bf621@haskell.org> References: <049.ca50dc09c6b5bdc241ded49d456bf621@haskell.org> Message-ID: <064.95ee4b3847ffca516133f17405494576@haskell.org> #13138: Clean up ghc-pkg validation warnings in build log -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): That's a good question. You can easily see it still happens by looking at the `stderr` of any GHC build (for example, https://phabricator.haskell.org/harbormaster/build/25271/?l=0). The reason why I haven't been able to fix this yet (with D3322) is that these entries don't appear in my local build logs when running `./validate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:11:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:11:49 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case In-Reply-To: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> References: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> Message-ID: <059.1a87ab544b0940336fb6024d41437376@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hi, the code above works well if we write the flag {{{-fdefer-typed- holes}}} in the command line.\\ the result is correct and has a sense.\\ To avoid under certain circumstances a nonsense I propose that Typed Holes are not always enabled in GHC.\\ what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:27:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:27:36 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 Message-ID: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Generated core size (as reported by ghc -v) is much bigger in ghc 8.0.2 compared to ghc 7.10.1. Things are slightly better in ghc 8.2.0rc2, but not as good as in ghc7 I think that results in a slight runtime performance problem. steps to reproduce: ghc -O A.hs {{{ Result size of CorePrep = {terms: 5,016, types: 9,813, coercions: 1,443} -- ghc8 Result size of CorePrep = {terms: 975, types: 2,375, coercions: 150} -- ghc7 Result size of CorePrep = {terms: 1,342, types: 2,838, coercions: 320, joins: 0/66} -- ghc8.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:28:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:28:10 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.9796021235a354d0fa2f5533b632f3ab@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): * Attachment "sample.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:29:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:29:18 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): * Attachment "sample.zip" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:29:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:29:18 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.eef84b1bc1f19b609de17e5b8068bd65@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): * Attachment "sample.zip" added. (right sample) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:30:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:30:39 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.61b9584a0beaa1445b8da7f0de3ff96c@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): If you comment out {{{ {-# SPECIALISE instance AdditiveGroup (Piecewise IntOfLogPoly4 Double) #-} }}} in Numeric/Polynomial/Piecewise.hs ghc7 version starts behaving similar to ghc8, at the same time AdditiveGroup instance is not used at all anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:33:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:33:34 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.d934fac23c64d050984b6ed9ef3bdb7c@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 mpickering): pacak also says on IRC that inlining any of the three files into each other leads to smaller core. Also the `INLINE` and `INLINABLE` pragmas are necessary in `A.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:51:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:51:52 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.4ca0e15169c3b1e42ced4763dfd2e7a7@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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): This reproducer depends on vector. What version? With vector-0.11.0.0 and ghc-8.0.1 I got these numbers: {{{ Result size of CorePrep = {terms: 1,227, types: 2,667, coercions: 256} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 10:55:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 10:55:42 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.d05c09e4923236c3849ed8eb49b8af82@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): I was able to reproduce this vector-0.10.12.3 for ghc7 and ghc8 and with vector-0.12.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 11:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 11:12:42 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.07bc4a8d1c55b2b37cc202340fd411c3@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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): From 975 in GHC 7.10 to 1,342 in GHC 8.2 doesn't sound terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 11:17:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 11:17:15 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.5e75f4972771096ca7fc805cdb8c8b4d@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): > From 975 in GHC 7.10 to 1,342 in GHC 8.2 doesn't sound terrible. When I was stripping down the example I was looking at sizes for ghc7 and ghc8. I can try to check ghc8.2 on original code, but it'll take time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:16:34 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn In-Reply-To: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> References: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> Message-ID: <061.9313bc024ac502173176fcca6acaa257@haskell.org> #13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3170 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"751996e90a964026a3f86853338f10c82db6b610/ghc" 751996e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="751996e90a964026a3f86853338f10c82db6b610" Kill off complications in CoreFVs When doing type-in-type, Richard introduce some substantial complications in CoreFVs, gathering types and free variables of type. In Trac #13160 we decided that this complication was unnecessary, so this patch removes it. Unfortnately I then fell down a twisty rabbit hole. Roughly: * An apparently-innocuous change in the AnnApp case of fiExpr made the fuction a little bit stricter, so we ended up peering into the arguments when we didn't before (namely when there are no bindings being floated inwards). I've rejigged it so that it's not fragile any more. * Peering into the arguments was sometimes expensive, becuase exprIsExpandable can be expensive because it looks deeply into the expression. * The combination of the two led to a non-linear explosion of work when the argument of a function is a deeep nest of constructors. This bug has been lurking for ages. I solved it by replacing exprIsExpandable with exprIsHNF + exprIsTrivial; see Note [noFloatInto considerations] * The code around floating case-expressions turned out to be very delicate, because can_fail primops (which we want to float inwards) can't be floated outwards; so we have to be careful never to float them too far. Note [Floating primops] has the details * I ended up refactoring some rather opaque code in sepBindsByDropPoint. Working all this out meant that I rewrote quite a bit of code, so it's now a reasonably substantial patch. But it's a net improvement. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:16:34 -0000 Subject: [GHC] #13543: Improve demand analysis for join points In-Reply-To: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> References: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> Message-ID: <061.eada0856f2db43e3a6576d4cb99fc705@haskell.org> #13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b5b7d820afd8fca098bf1f4a7380d425ca6be31d/ghc" b5b7d82/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5b7d820afd8fca098bf1f4a7380d425ca6be31d" Improve demand analysis for join points I realised (Trac #13543) that we can improve demand analysis for join point quite straightforwardly. The idea is explained in Note [Demand analysis for join points] in DmdAnal }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:16:34 -0000 Subject: [GHC] #13558: Inconsistency in CoreUtils.exprIsOk In-Reply-To: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> References: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> Message-ID: <061.b0646d9f210aa62f13ddddfe2e0f7376@haskell.org> #13558: Inconsistency in CoreUtils.exprIsOk -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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:"8d8d094d45fc638e3fac332fbce8138a1c06b9c3/ghc" 8d8d094d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d8d094d45fc638e3fac332fbce8138a1c06b9c3" Make let and app consistent in exprIsCheapX This fixes Trac #13558, by making App and Let behave consistently; see Note [Arguments and let-bindings exprIsCheapX] I renamed the mysterious exprIsOk to exprIsCheapX. (The "X" is because it is parameterised over a CheapAppFun.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:25:31 -0000 Subject: [GHC] #13567: Do loopification using join points Message-ID: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> #13567: Do loopification using join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Here's an idea: use join points to accomplish all that the existing "loopification" patch does, and more. The idea is described under "New idea: use join points" in [wiki:Commentary/Compiler/Loopification]. This ticket is to discuss and track progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:25:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:25:57 -0000 Subject: [GHC] #13567: Do loopification using join points In-Reply-To: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> References: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> Message-ID: <061.1a98ed42ab1ff34629c86af4a0f0be44@haskell.org> #13567: Do loopification using join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:26:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:26:31 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn In-Reply-To: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> References: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> Message-ID: <061.994509f71311c9cbabcffa7d57c5cd3e@haskell.org> #13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: closed Priority: high | Milestone: 8.4.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:D3170 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:27:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:27:10 -0000 Subject: [GHC] #13543: Improve demand analysis for join points In-Reply-To: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> References: <046.3c4a77ff5e0e28a91ea42884fbdafb1b@haskell.org> Message-ID: <061.a7e13ce304b72dfa2e6259fd33141332@haskell.org> #13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Done. No visible effect on nofib, but still good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:27:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:27:23 -0000 Subject: [GHC] #13558: Inconsistency in CoreUtils.exprIsOk In-Reply-To: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> References: <046.a04342191a240c23f0b62cf9aef98623@haskell.org> Message-ID: <061.e66d1372a70ccb5a07ae54297b679119@haskell.org> #13558: Inconsistency in CoreUtils.exprIsOk -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 15:31:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 15:31:36 -0000 Subject: [GHC] #13567: Do loopification using join points In-Reply-To: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> References: <046.202e5da884dbbf7ba651e535c183b40e@haskell.org> Message-ID: <061.06bb03c26fd4833848f6a32cc15b3d8f@haskell.org> #13567: Do loopification using join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This would work well with #13051, which Thomas Jakway is still thinking about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 17:42:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 17:42:29 -0000 Subject: [GHC] #12912: IO library should not use select() In-Reply-To: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> References: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> Message-ID: <062.bb454e34da61e6e93852ea9debdabefd@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): No, this is certainly not expected. 37d7c1596ee936ec6597a5c1898e1fdca7c04f77 adds a testcase to ensure that we catch this next time. The problem appears to be that the patch assumes that all IO operations go through the IO manager, which will take care of waiting for us. However, `GHC.IO.Handle.Text.hWaitForInput` appears to call `GHC.IO.Fd.ready` directly, which then passes the timeout to `fdReady`. It's not entirely clear what was intended by this comment, {{{#!hs // We only handle msecs == 0 on non-Windows, because this is the // only case we need. Non-zero waiting is handled by the IO manager. }}} Jaffacake, can you clarify how you intended for this work? Where is this IO manager treatment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 17:47:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 17:47:54 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope Message-ID: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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: -------------------------------------+------------------------------------- {{{ module A where data T = A }}} {{{ module B where import A data S = A foo :: A -> () foo = undefined }}} Compiling this example, the usage of `A` in `foo` is reported as both ambiguous and out of scope. I haven't mentioned data kinds at all so `A` should certainly refer to a type constructor which isn't in scope. The problem is that `DataKinds` is checked too late in `lookup_demoted`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 17:48:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 17:48:05 -0000 Subject: [GHC] #13568: Name is reported as ambiguous and not in scope In-Reply-To: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> References: <049.00d82fba52dec5af37f45e0e39533b2f@haskell.org> Message-ID: <064.0fa2c519aea67413baa914d862b76392@haskell.org> #13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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 mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 17:59:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 17:59:59 -0000 Subject: [GHC] #12912: IO library should not use select() In-Reply-To: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> References: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> Message-ID: <062.553000da8b6dbfdc25b78e33e549b1a8@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I think I just missed that we also called into here from `hWaitForInput`, oops. We'll need to do `hWaitForInput` with a non-zero timeout a different way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:17:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:17:32 -0000 Subject: [GHC] #12912: IO library should not use select() In-Reply-To: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> References: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> Message-ID: <062.878a7653d07942b2674496692c5ed5a1@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I did some grepping and I'm pretty certain that this is the only caller of `ready` that we need to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:53:17 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.10e583881acec6da08714852021318ed@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fa5a73f0a86908da31ec72ce33d37a7a704a0600/ghc" fa5a73f0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fa5a73f0a86908da31ec72ce33d37a7a704a0600" Allow qualified names to be children in export lists When doing this I noticed a horrible amount of duplication between lookupSubBndrOcc and lookupExportChild (which I am responsible for). I opened #13545 to keep track of this. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13528 Differential Revision: https://phabricator.haskell.org/D3434 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:53:17 -0000 Subject: [GHC] #7722: iOS patch no 11: Fix quirk with runtime loader In-Reply-To: <056.3bdc8659a743b1f5721b6da08000f25f@haskell.org> References: <056.3bdc8659a743b1f5721b6da08000f25f@haskell.org> Message-ID: <071.0ec8afe2b7714a792b79322e2b2af9f8@haskell.org> #7722: iOS patch no 11: Fix quirk with runtime loader --------------------------------------+----------------------- Reporter: StephenBlackheath | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7724 Related Tickets: | --------------------------------------+----------------------- Comment (by Ben Gamari ): In [changeset:"68c00a1b38707b2a5c813cbe3da3ffb7d97893b6/ghc" 68c00a1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68c00a1b38707b2a5c813cbe3da3ffb7d97893b6" Drop special handling of iOS iOS at least since iOS8 (we are currently at iOS10.3), allows for dynamic libaries, hence any artificail restriction on dyanmic libraries should be lifted. Please ping me with any iOS related issues that should potentially resurface. The iOS toolchain has considerably changed over the years, and I'm willing to drop work arounds in good faith. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13559, #7722 Differential Revision: https://phabricator.haskell.org/D3451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:53:17 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.87ee5c89937548aa40a6f13fb8b3636c@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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 Ben Gamari ): In [changeset:"fa5a73f0a86908da31ec72ce33d37a7a704a0600/ghc" fa5a73f0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fa5a73f0a86908da31ec72ce33d37a7a704a0600" Allow qualified names to be children in export lists When doing this I noticed a horrible amount of duplication between lookupSubBndrOcc and lookupExportChild (which I am responsible for). I opened #13545 to keep track of this. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13528 Differential Revision: https://phabricator.haskell.org/D3434 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:53:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:53:17 -0000 Subject: [GHC] #13559: Remove LLVM/-fPIC check in DynFlags In-Reply-To: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> References: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> Message-ID: <061.579ee9870fe5630751503adf88b3260f@haskell.org> #13559: Remove LLVM/-fPIC check in DynFlags -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"68c00a1b38707b2a5c813cbe3da3ffb7d97893b6/ghc" 68c00a1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68c00a1b38707b2a5c813cbe3da3ffb7d97893b6" Drop special handling of iOS iOS at least since iOS8 (we are currently at iOS10.3), allows for dynamic libaries, hence any artificail restriction on dyanmic libraries should be lifted. Please ping me with any iOS related issues that should potentially resurface. The iOS toolchain has considerably changed over the years, and I'm willing to drop work arounds in good faith. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13559, #7722 Differential Revision: https://phabricator.haskell.org/D3451 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:54:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:54:15 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.43d8b4a06faedbf6263c4807beb4496a@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: mpickering Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge @@ -4,1 +4,1 @@ - {{{ + {{{#!hs New description: Unqualified exports of constructors doesn't work anymore in 8.2.1-rc1. It worked before in 8.0. Is this intended or a regression? {{{#!hs module Test ( GHC.Exts.IsList( Item , fromList , toList ) , Data.Bool.Bool(True, False) ) where import qualified GHC.Exts import qualified Data.Bool }}} The error: {{{ • Not in scope: data constructor ‘False’ Perhaps you meant ‘Prelude.False’ (imported from Prelude) • In the export: Data.Bool.Bool(False, True) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 18:55:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 18:55:05 -0000 Subject: [GHC] #13559: Remove LLVM/-fPIC check in DynFlags In-Reply-To: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> References: <046.873c79c28d94b5bee3de153698a4e3b5@haskell.org> Message-ID: <061.44466dad5e9e5288499a133737644956@haskell.org> #13559: Remove LLVM/-fPIC check in DynFlags -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 20:30:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 20:30:14 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.524aad76e2201875a1fd4ca66438a60b@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: mpickering Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: module/T13528 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => module/T13528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:02:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:02:01 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.e78c54504a6043e38d5454d932d5e071@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: closed Priority: normal | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:07:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:07:18 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.2cef11196e51c3be60c3fdf2135f8236@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 nh2): Replying to [comment:7 angerman]: > clang doesn't understand `-fuse-ld` (at least not the one that comes with the android toolchain, not sure if this statement holds universally) This seems to be Android toolchain specific. Upstream clang suppports `-fuse-ld` since 2014: https://github.com/llvm- mirror/clang/commit/bab68c96f15867af6938d9c8f922d59d31351cad -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:12:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:12:25 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.30f49e1d6bc6d07f1e0fad3b86afa175@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 nh2): Replying to [comment:5 angerman]: > I'm also a bit confused why gcc would not respect the LD env var. I guess this may be controversial, but I have always liked the fact that cabal and GHC rely as little as possible on environment variables. It has made it much easier many times for me to debug ghc issues (funnily, especially the linker investigation) because I can see all relevant inputs to a ghc invocation simply in `ps` or `strace`, and re-run them to isolate problems without accidentally not replicating the environment correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:17:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:17:38 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.ecbe9064c96131e693174847bf1e20fd@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: mpickering => (none) * status: closed => new * resolution: fixed => Comment: The commit in comment:3 does not close this ticket. On the contrary, it was the reason for opening it. No? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:22:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:22:42 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.50d6c448c95af8e2627e4969d66b1aea@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:24:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:24:36 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.a9ead8f5a8ad31d505b532e942e91976@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, yes, I misread. Apologies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 12 21:49:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Apr 2017 21:49:26 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.1037e3d26d029bf78243c87ca7131bc3@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 01:27:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 01:27:29 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.3dad470dda1092635ef8fbf8aa1f0019@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): GHC 8.2 on original code: {{{ Result size of Demand analysis = {terms: 5,548, types: 10,236, coercions: 2,752, joins: 10/79} !!! Demand analysis [A]: finished in 198.43 milliseconds, allocated 43.533 megabytes *** CoreTidy [A]: Result size of Tidy Core = {terms: 1,150, types: 2,274, coercions: 320, joins: 0/14} !!! CoreTidy [A]: finished in 6.72 milliseconds, allocated 6.210 megabytes writeBinIface: 149 Names writeBinIface: 279 dict entries writeBinIface: 149 Names writeBinIface: 279 dict entries *** CorePrep [A]: Result size of CorePrep = {terms: 1,342, types: 2,838, coercions: 320, joins: 0/66} }}} Looks like ghc 8.2 also produces similar sized core and manages to clean it up later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 01:49:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 01:49:08 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.6047e7a0f3b49317306fe3770b66838a@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 angerman): Replying to [comment:10 nh2]: > Replying to [comment:7 angerman]: > > clang doesn't understand `-fuse-ld` (at least not the one that comes with the android toolchain, not sure if this statement holds universally) > > This seems to be Android toolchain specific. > > Upstream clang suppports `-fuse-ld` since 2014: https://github.com/llvm- mirror/clang/commit/bab68c96f15867af6938d9c8f922d59d31351cad This likely has been a misreading of the error on my side, as noted in https://phabricator.haskell.org/D3351. The LD that comes witht he android toolchain is called -ld or -ld.gold, and both are effectively gold, and there is no tool called just `ld.gold`, there is one called `ld`, but that is ld64, and would be horribly wrong to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 01:58:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 01:58:24 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.997c017a63616df03f9460cd7ee1e0fd@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 angerman): Replying to [comment:11 nh2]: > Replying to [comment:5 angerman]: > > I'm also a bit confused why gcc would not respect the LD env var. > > I guess this may be controversial, but I have always liked the fact that cabal and GHC rely as little as possible on environment variables. > > It has made it much easier many times for me to debug ghc issues (funnily, especially the linker investigation) because I can see all relevant inputs to a ghc invocation simply in `ps` or `strace`, and re-run them to isolate problems without accidentally not replicating the environment correctly. My personal issue with not respecting env variables is that, without respecting the environment, one has to - have explicit flags for each possible configuration value, that otherwise would have been taken from the environment. - by not using the environment, one is posed to break tooling that depends on the environment. GHC already has a lot of logic to find tools at configuration time and store their paths. `FIND_LD` already tries to detect gold, (and fails for the android toolchain...) I am much more in favor of doing tool checking rather than magic. What I mean is this: instead of trying hard to find some tool (say ld), use $LD. However if we know we want gold, try `$LD --version` to verify it actually *is* gold. And if it's not, put out a warning that $LD is not set to `gold` and that this is known not to work. However if you want to ignore the error pass `--compat-warning-only`. Which would then print a warning: > Warning: linker ($LD) does not seem to be gold. Continuing anyway due to --compat-warning-only. instead of > Error: linker ($LD) does not seem to be gold. bfd is known not to work. To continue anyway, pass --compat-warning-only. Then again, this makes me wonder why we test for gold, and not against bfd in the first place? Why force gold, if lld is fine as well, when all we want is to make sure we don't use a buggy/broken/slow linker called bfd? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 07:58:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 07:58:52 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products Message-ID: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's something we talked about last year which I wanted to look into but then got distracted (but I'm writing this one up now so it doesn't get lost again): Consider large field updates such as {{{#!hs module BigRec where data T = C { fld01 :: !Int , fld02 :: !Int , fld03 :: Int , fld04 :: Int , fld05 :: Int , fld06 :: Int , fld07 :: Int , fld08 :: Int , fld09 :: Int , fld10 :: Int , fld11 :: Int , fld12 :: Int , fld13 :: Int , fld14 :: Int , fld15 :: Int , fld16 :: Int , fld17 :: Int , fld18 :: Int , fld19 :: Int } inc01 x = x { fld01 = (fld01 x) + 1 } inc0102 x = x { fld01 = (fld01 x) + 1, fld02 = (fld02 x) + 1 } }}} These get translated into long chains of assignments, which in turn result in respectively long chains of register<->memory move instructions being generated by the NCG {{{#!c BigRec.inc0102_entry() // [R2] { [(c1em, block_c1em_info: const 0; const 31;), (c1ep, BigRec.inc0102_info: const 4294967301; const 0; const 15;)] } {offset c1ep: if ((Sp + -8) < SpLim) goto c1ez; else goto c1eA; c1ez: // nop R1 = BigRec.inc0102_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c1eA: I64[Sp - 8] = block_c1em_info; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c1em; else goto c1en; c1en: call (I64[R1])(R1) returns to c1em, args: 8, res: 8, upd: 8; c1em: Hp = Hp + 160; if (Hp > I64[BaseReg + 856]) goto c1eD; else goto c1eC; c1eD: I64[BaseReg + 904] = 160; // nop call stg_gc_unpt_r1(R1) returns to c1em, args: 8, res: 8, upd: 8; c1eC: _s15F::P64 = P64[R1 + 7]; _s15G::P64 = P64[R1 + 15]; _s15H::P64 = P64[R1 + 23]; _s15I::P64 = P64[R1 + 31]; _s15J::P64 = P64[R1 + 39]; _s15K::P64 = P64[R1 + 47]; _s15L::P64 = P64[R1 + 55]; _s15M::P64 = P64[R1 + 63]; _s15N::P64 = P64[R1 + 71]; _s15O::P64 = P64[R1 + 79]; _s15P::P64 = P64[R1 + 87]; _s15Q::P64 = P64[R1 + 95]; _s15R::P64 = P64[R1 + 103]; _s15S::P64 = P64[R1 + 111]; _s15T::P64 = P64[R1 + 119]; _s15U::P64 = P64[R1 + 127]; _s15V::P64 = P64[R1 + 135]; _s15X::I64 = I64[R1 + 151] + 1; _s15W::I64 = I64[R1 + 143] + 1; I64[Hp - 152] = BigRec.C_con_info; P64[Hp - 144] = _s15F::P64; P64[Hp - 136] = _s15G::P64; P64[Hp - 128] = _s15H::P64; P64[Hp - 120] = _s15I::P64; P64[Hp - 112] = _s15J::P64; P64[Hp - 104] = _s15K::P64; P64[Hp - 96] = _s15L::P64; P64[Hp - 88] = _s15M::P64; P64[Hp - 80] = _s15N::P64; P64[Hp - 72] = _s15O::P64; P64[Hp - 64] = _s15P::P64; P64[Hp - 56] = _s15Q::P64; P64[Hp - 48] = _s15R::P64; P64[Hp - 40] = _s15S::P64; P64[Hp - 32] = _s15T::P64; P64[Hp - 24] = _s15U::P64; P64[Hp - 16] = _s15V::P64; I64[Hp - 8] = _s15W::I64; I64[Hp] = _s15X::I64; R1 = Hp - 151; }}} This happens in a few places inside GHC's source-tree (where we have large-ish products, such as DynFlags where we update single fields), which is where I noticed this while looking at generated ASM output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 08:21:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 08:21:01 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.c7e1438aa28823fecad26da4a3a2c854@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. What do you suggest instead? `memcpy`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 08:27:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 08:27:02 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.98140c97ec18b8727623956050e89313@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | TypeApplications 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:"0ae72512255ba66ef89bdfeea65a23ea6eb35124/ghc" 0ae72512/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ae72512255ba66ef89bdfeea65a23ea6eb35124" Yet more work on TcSimplify.simplifyInfer The proximate cause for this patch is Trac #13482, which pointed out further subtle interactions between - Inferring the most general type of a function - A partial type signature for that function That led me into /further/ changes to the shiny new stuff in TcSimplify.simplifyInfer, decideQuantification, decideMonoTyVars, and related functions. Happily, I was able to make some of it quite a bit simpler, notably the bit about promoting free tyvars. I'm happy with the result. Moreover I fixed Trac #13524 at the same time. Happy days. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 08:27:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 08:27:02 -0000 Subject: [GHC] #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together In-Reply-To: <050.32ff9ffcd456d5039c2557ae9a212950@haskell.org> References: <050.32ff9ffcd456d5039c2557ae9a212950@haskell.org> Message-ID: <065.51c90ad751b26b6b8b8879dd502d67f4@haskell.org> #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0ae72512255ba66ef89bdfeea65a23ea6eb35124/ghc" 0ae72512/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ae72512255ba66ef89bdfeea65a23ea6eb35124" Yet more work on TcSimplify.simplifyInfer The proximate cause for this patch is Trac #13482, which pointed out further subtle interactions between - Inferring the most general type of a function - A partial type signature for that function That led me into /further/ changes to the shiny new stuff in TcSimplify.simplifyInfer, decideQuantification, decideMonoTyVars, and related functions. Happily, I was able to make some of it quite a bit simpler, notably the bit about promoting free tyvars. I'm happy with the result. Moreover I fixed Trac #13524 at the same time. Happy days. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 08:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 08:28:30 -0000 Subject: [GHC] #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together In-Reply-To: <050.32ff9ffcd456d5039c2557ae9a212950@haskell.org> References: <050.32ff9ffcd456d5039c2557ae9a212950@haskell.org> Message-ID: <065.f95b007314b14f5446cead9c9c3a6f31@haskell.org> #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_compile/T13482 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => partial-sigs/should_compile/T13482 * resolution: => fixed Comment: Great examples, thank you! All fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 08:30:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 08:30:30 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.e132c4c96cf702bb96b9c5aefc3097fa@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13524 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T13524 * resolution: => fixed Comment: I fixed this, somewhat by accident. The key code is in `TcSimplify.decideQuantifiedTyVars`, where there is a comment to explain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 08:42:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 08:42:27 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower Message-ID: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This commit {{{ commit 751996e90a964026a3f86853338f10c82db6b610 Author: Simon Peyton Jones Date: Fri Apr 7 17:10:07 2017 +0100 Kill off complications in CoreFVs }}} makes `n-body` in nofib go 25% slower. See [https://perf.haskell.org/ghc/#revision/751996e90a964026a3f86853338f10c82db6b610 perf results page]. Investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:06:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:06:14 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.e014f6cf652a6d0d5d6862b359373426@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): ''Should these two instance declarations be accepted?'' Depends what you mean by "accepted". I think the case is suffering from GHC's delayed/lazy instance enforcement, as affects the complications of confluence around partially overlapping instances. The `C Char ...` instance clearly could never work -- its constraint needs an infinite regress on `C Char [[[[ ... ]]]] ...`. Is anybody saying that instance on its own should be rejected? If so, see counter-example/highly valuable exploit below. It's an interesting experiment trying to find valid calls for `f` [I'm using 7.10]. This works: `f (Just "quoi?")`. This doesn't: `f ("quoi")` -- GHC complains `"Couldn't match expected type 'Maybe y0' with actual type '[Char]'"`. So GHC __is__ applying the fundep `a -> b` Consistency Condition as per '''Definition 6''' in the CHRs/Mark Jones 2000 paper. It is taking `[x] [Maybe y]` to infer that in `[x] [x]` we must have `x ~ Maybe y` -- as the O.P. is saying. I think we've no reason to reject this example. Or perhaps Iavor could explain what "loophole" this opens up? Can it result in type incoherence? Before we reject this example as bogus, @Richard, I think there are examples similar to it that might get caught in the crossfire. [That's the reason I arrived here, because I'm trying to understand how/why the FunDeps work for it.] The classic Type-level type equality test: {{{ class TTypeEq (a :: *) (a' :: *) (b :: Bool) | a a' -> b instance TTypeEq a a True instance (b ~ False) => TTypeEq a a' b }}} Seems to break '''Definition 6'''. There's a substitution for the two instances that makes the determinants of the FunDep equal, namely `{a' ~ a}`. And under that substitution, the dependents are not equal `{b vs False}`. FWIW, Hugs applies a stricter interpretation of '''Definition 6''', with the consequence no such declaration of `TTypeEq` is accepted [explored in Oleg/Ralph's HList paper]. Or if we include substitution `{b ~ True}`, that substitution invalidates the constraint on the `False` instance. Clearly GHC isn't evaluating the instance's constraints for consistency with its improvement of the class parameters. We can't write that second instance as: {{{ instance TTypeEq a a' False }}} GHC complains `"Functional Dependencies conflict between instance declarations"` What would any proposed fix for this ticket do to a class like? {{{ class TTypeEq2 x a a' b | a a' -> b instance TTypeEq2 Bool a a True instance TTypeEq2 Char a a True instance (b ~ False) Bool a a' b instance (b ~ False) Char a a' b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:51:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:51:51 -0000 Subject: [GHC] #13506: Spurious extra error message due to functional dependencies In-Reply-To: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> References: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> Message-ID: <061.4c8c27b90f1b4313667cd9c3cd12f2c4@haskell.org> #13506: Spurious extra error message due to functional dependencies -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T13506 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:52:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:52:09 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.342f5e89294f6c54751085f3dc2d200a@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: FunDeps 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 simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:52:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:52:19 -0000 Subject: [GHC] #12763: Incorrect behavior with empty functional dependencies In-Reply-To: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> References: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> Message-ID: <062.17cf9268c34365847af71d6aaef77b67@haskell.org> #12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12763 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:52:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:52:36 -0000 Subject: [GHC] #12704: Check if constraint synonym satisfies functional dependencies In-Reply-To: <045.a9a7c74299c8b61d662ad7a5ba1a3210@haskell.org> References: <045.a9a7c74299c8b61d662ad7a5ba1a3210@haskell.org> Message-ID: <060.f31fd2c1c457fbf43efd1197c41a5d55@haskell.org> #12704: Check if constraint synonym satisfies functional dependencies -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: FunDeps 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: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:53:08 -0000 Subject: [GHC] #12647: Can't capture improvement of functional dependencies In-Reply-To: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> References: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> Message-ID: <066.ae982d2d7fa359f27cdcfbc37b0f48b6@haskell.org> #12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: FunDeps 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: FunctionalDependencies => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:55:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:55:47 -0000 Subject: [GHC] #10797: Kind-level functional dependencies are not resolved properly In-Reply-To: <046.e5566984a246d66127e6e59197588043@haskell.org> References: <046.e5566984a246d66127e6e59197588043@haskell.org> Message-ID: <061.a4afb5f16fa09ba9e6f6b30aa9cd99ad@haskell.org> #10797: Kind-level functional dependencies are not resolved properly -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: FunDeps 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: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:56:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:56:26 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.21fcd89ac2ef20aabb2e4b7fd0238893@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps 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: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:56:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:56:42 -0000 Subject: [GHC] #10570: Terrible error message with fundeps and PolyKinds In-Reply-To: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> References: <046.4466b015687c38c71e7a50b843a82b42@haskell.org> Message-ID: <061.7205ac5a1471c2a9ce7267fde7621f94@haskell.org> #10570: Terrible error message with fundeps and PolyKinds -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: FunDeps 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: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:56:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:56:53 -0000 Subject: [GHC] #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 In-Reply-To: <047.d3b7b31aab7749db694d46171b616686@haskell.org> References: <047.d3b7b31aab7749db694d46171b616686@haskell.org> Message-ID: <062.d8cd22e7331d362ab06fa4befd87dee7@haskell.org> #10564: GHC 7.10.2 RC cannot build HList-0.4.0.0 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Resolution: fixed | Keywords: FunDeps Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 11:57:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 11:57:12 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition In-Reply-To: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> References: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> Message-ID: <062.13beeb3fb7cda8c1f1e1efe86213ca3c@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10109 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 12:51:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 12:51:51 -0000 Subject: [GHC] #13316: Bad inlining cascade leads to slow optimisation In-Reply-To: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> References: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> Message-ID: <061.f0b141a2b233d02b6b0f25c2bc4abecb@haskell.org> #13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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): Here's my work-in-progress {{{ Modified compiler/simplCore/SimplUtils.hs diff --git a/compiler/simplCore/SimplUtils.hs b/compiler/simplCore/SimplUtils.hs index 7deaf5b..2f9e2e9 100644 --- a/compiler/simplCore/SimplUtils.hs +++ b/compiler/simplCore/SimplUtils.hs @@ -1200,7 +1200,7 @@ postInlineUnconditionally dflags env top_lvl bndr occ_info rhs unfolding -- PRINCIPLE: when we've already simplified an expression once, -- make sure that we only inline it if it's reasonably small. - && (not in_lam || + && ( (not in_lam && not (isValueUnfolding unfolding)) || -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = @@ -1209,7 +1209,7 @@ postInlineUnconditionally dflags env top_lvl bndr occ_info rhs unfolding -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' - (isCheapUnfolding unfolding && int_cxt)) + (int_cxt && isCheapUnfolding unfolding)) -- isCheap => acceptable work duplication; in_lam may be true -- int_cxt to prevent us inlining inside a lambda without some -- good reason. See the notes on int_cxt in preInlineUnconditionally }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 12:58:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 12:58:01 -0000 Subject: [GHC] #9066: Template Haskell cannot splice an infix declaration for a data constructor In-Reply-To: <047.316ce5f75a1c71475de4d088845130df@haskell.org> References: <047.316ce5f75a1c71475de4d088845130df@haskell.org> Message-ID: <062.b8de1f0ec7247b0016bb4195154b308b@haskell.org> #9066: Template Haskell cannot splice an infix declaration for a data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T9066 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't think this was every really fixed properly and the wrinkle still exists in `RnEnv`. It seems that requiring namespace information on the `InfixD` constructor is the best way forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 13:11:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 13:11:03 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.6335d6503e2774ce2d0a269f06c6da49@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13524 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Will this make 8.2.1, or even 8.2 rc2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 13:30:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 13:30:20 -0000 Subject: [GHC] #13571: Injective type family syntax accepted without TypeFamilyDependencies Message-ID: <048.555a912faf2a1ac128c4b78fd974a910@haskell.org> #13571: Injective type family syntax accepted without TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple Injective | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program compiles fine although it names the result type variable, which is a piece of syntax that should only be available with `TypeFamilyDependencies` (injective type families): {{{#!haskell {-# LANGUAGE TypeFamilies #-} module Foo where type family F a = r where F a = a }}} If I say: {{{#!haskell type family F a = r | r -> a where F a = a }}} only then the definition is rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 13:33:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 13:33:02 -0000 Subject: [GHC] #13572: Add ArgMin / ArgMax pattern synonyms Message-ID: <051.ea5d7e6d84f468e7faa4e35e64a19715@haskell.org> #13572: Add ArgMin / ArgMax pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import Data.Semigroup pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin a b = Min (Arg a b) pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax a b = Max (Arg a b) }}} Or even record pattern synonyms, à la [https://github.com/energyflowanalysis/efa-2.1/blob/3eb86c0b6b2d2fb66cd5b76ce5c0437d42f8cdf8/sandbox/delaunay/HalfPlaneMap.hs#L181 this] {{{#!hs pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin {minArg, minValue} = Min (Arg minArg minValue) pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax [maxArg, maxValue} = Max (Arg maxArg maxValue) }}} and we can define {{{#!hs import Data.Semigroup.Foldable argmin :: Ord k => Foldable1 f => (a -> k) -> (f a -> a) argmin f = minValue . foldMap1 (\a -> ArgMin (f a) a) argmax :: Ord k => Foldable1 f => (a -> k) -> (f a -> a) argmax f = maxValue . foldMap1 (\a -> ArgMax (f a) a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 13:36:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 13:36:10 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.3a16b6264629d8a61cf31ee77c2bf698@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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): Some afterthoughts: * What if the instances from the O.P. were declared in separate modules? Then GHC couldn't apply the mutual improvement. Would it reject the instances as inconsistent? * I find the statement of '''Definition 6''' in the CHR paper a bit imprecise. Mark Jones 2000 paper is clearer [Section 6.1]. It says "if `tX` and `sX` have a most general unifier `U`, then `UtY = UsY`." where `tX, sX` are the determinant types from the instance decl, `tY, sY` are the dependents. * I wonder if what GHC is doing to apply that test is rather than `UtY = UsY`, it's checking `UtY ~ UsY` -- that is, checking unifiability rather than equality(?) That would explain the behaviour with the `TTypeEq` examples. * Re the "dysfunctional" Functional Dependencies ;-), we could do with some better way of writing instances to give maximum help for type improvement. Currently you keep running up against instance-FunDep conflicts. And I don't think Injective type functions help much. For example type-level `Plus` over `Nat`s, with three-way FunDeps. [Yes I know Oleg worked it out years ago, but it's a ''tour de force''.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 15:09:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 15:09:08 -0000 Subject: [GHC] #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild In-Reply-To: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> References: <049.89caaf22c2ba5f38d8c235593b0d8067@haskell.org> Message-ID: <064.e78d0286b55e16598700ab9b526c1825@haskell.org> #13545: Remove duplication between lookupSubBndrOcc and lookupExportChild -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): There is the slight complication that `lookupExportChild` runs after typechecking which means that it invokes typechecker lookup functions to resolve things to do with record pattern synonym selectors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 15:45:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 15:45:36 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.b188cd885d80209c114b6eb24a722bc4@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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): I found another reason to do this: `tagToEnum# (x ># y)` is floated out by full laziness, creating a new thunk and a free variable of the function closure. But plain `(x ># y)` is not: it's too cheap to be worth it. We could make `tagToEnum# (x ># y)` look cheaper, but if we eliminate it we don't have to bother. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 15:54:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 15:54:35 -0000 Subject: [GHC] #13573: Add Foldable1 / Traversable1 to base Message-ID: <051.5343934480dda921b1b6981f18b39763@haskell.org> #13573: Add Foldable1 / Traversable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `NonEmpty` and `Semigroup` are in ''base'' and are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1], [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Traversable.html Traversable1] in ''base'' as well. `Foldable` has partial functions already, functions that only make sense for non-empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github] page) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 15:56:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 15:56:34 -0000 Subject: [GHC] #13573: Add Foldable1 / Traversable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.c7544240bd1022027d98ea4dfe60ce2a@haskell.org> #13573: Add Foldable1 / Traversable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * type: bug => feature request @@ -1,1 +1,1 @@ - `NonEmpty` and `Semigroup` are in ''base'' and are on our way to add + `NonEmpty` and `Semigroup` are in ''base'' and we are on our way to add @@ -43,1 +43,1 @@ - controversial + controversial but I never liked so many partial functions in `Foldable`. New description: `NonEmpty` and `Semigroup` are in ''base'' and we are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1], [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Traversable.html Traversable1] in ''base'' as well. `Foldable` has partial functions already, functions that only make sense for non-empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github] page) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial but I never liked so many partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 16:01:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 16:01:44 -0000 Subject: [GHC] #13573: Add Foldable1 to base (was: Add Foldable1 / Traversable1 to base) In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.674a9d12cee7e220c3759a62970f07b5@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -5,3 +5,1 @@ - Semigroup-Foldable.html Foldable1], - [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- - Semigroup-Traversable.html Traversable1] in ''base'' as well. + Semigroup-Foldable.html Foldable1] in ''base'' as well. New description: `NonEmpty` and `Semigroup` are in ''base'' and we are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] in ''base'' as well. `Foldable` has partial functions already, functions that only make sense for non-empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github] page) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial but I never liked so many partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 16:17:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 16:17:32 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.905c359c16154e0c6859090fb753b2bb@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -5,1 +5,2 @@ - Semigroup-Foldable.html Foldable1] in ''base'' as well. + Semigroup-Foldable.html Foldable1] in ''base'' as well (`Foldable1` is + like `Foldable` for non-empty structures). @@ -7,5 +8,5 @@ - `Foldable` has partial functions already, functions that only make sense - for non-empty structures such as `foldr1`, `foldl1`, `minimum` and - `maximum`. There are also functions which ''could'' be defined in terms of - `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` - see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue + `Foldable` has partial functions, functions that only make sense for non- + empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. + There are also functions which ''could'' be defined in terms of `Foldable` + like `head` / `tail` (for definition of `unimprove` and `Diff` see + [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue @@ -15,0 +16,2 @@ + + If `Foldable1` we can make these functions total: New description: `NonEmpty` and `Semigroup` are in ''base'' and we are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] in ''base'' as well (`Foldable1` is like `Foldable` for non-empty structures). `Foldable` has partial functions, functions that only make sense for non- empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github] page) If `Foldable1` we can make these functions total: {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial but I never liked so many partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 16:17:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 16:17:46 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.9442accb1bff9a768e92924cb46c570e@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -17,1 +17,1 @@ - If `Foldable1` we can make these functions total: + With `Foldable1` we can make these functions total: New description: `NonEmpty` and `Semigroup` are in ''base'' and we are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] in ''base'' as well (`Foldable1` is like `Foldable` for non-empty structures). `Foldable` has partial functions, functions that only make sense for non- empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github] page) With `Foldable1` we can make these functions total: {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial but I never liked so many partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 16:49:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 16:49:41 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.ad422236c928c815ed4afbeb3bdbceb0@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 16:56:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 16:56:36 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.197faff6e4a5a0b1072f3902d962bb82@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Git bisect indicates that the regression in `Data.IP.Addr` occurred in b9e49d3e9580e13d89efd1f779cb76f610e0d6e0 "Add -fspecialise-aggressively". Compiler allocation with `-O` increased from 1.53GB to 2.25GB and compilation time increased from 1.8s to 2.6s. Is this to be expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 17:05:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 17:05:46 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.9ea9fda9d36c1aceedb316c09e4c0de2@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 17:12:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 17:12:36 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.c98e38aa2346206bdbf39ffae4345624@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 bgamari): Yes, I believe we discussed this around six months ago and the suggestion was to emit a `memcpy` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 18:35:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 18:35:00 -0000 Subject: [GHC] #13572: Add ArgMin / ArgMax pattern synonyms In-Reply-To: <051.ea5d7e6d84f468e7faa4e35e64a19715@haskell.org> References: <051.ea5d7e6d84f468e7faa4e35e64a19715@haskell.org> Message-ID: <066.66b6a786c22f9842410d131d3cacf888@haskell.org> #13572: Add ArgMin / ArgMax pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -20,1 +20,1 @@ - pattern ArgMax [maxArg, maxValue} = Max (Arg maxArg maxValue) + pattern ArgMax {maxArg, maxValue} = Max (Arg maxArg maxValue) New description: {{{#!hs import Data.Semigroup pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin a b = Min (Arg a b) pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax a b = Max (Arg a b) }}} Or even record pattern synonyms, à la [https://github.com/energyflowanalysis/efa-2.1/blob/3eb86c0b6b2d2fb66cd5b76ce5c0437d42f8cdf8/sandbox/delaunay/HalfPlaneMap.hs#L181 this] {{{#!hs pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin {minArg, minValue} = Min (Arg minArg minValue) pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax {maxArg, maxValue} = Max (Arg maxArg maxValue) }}} and we can define {{{#!hs import Data.Semigroup.Foldable argmin :: Ord k => Foldable1 f => (a -> k) -> (f a -> a) argmin f = minValue . foldMap1 (\a -> ArgMin (f a) a) argmax :: Ord k => Foldable1 f => (a -> k) -> (f a -> a) argmax f = maxValue . foldMap1 (\a -> ArgMax (f a) a) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 18:41:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 18:41:13 -0000 Subject: [GHC] #13572: Add ArgMin / ArgMax pattern synonyms In-Reply-To: <051.ea5d7e6d84f468e7faa4e35e64a19715@haskell.org> References: <051.ea5d7e6d84f468e7faa4e35e64a19715@haskell.org> Message-ID: <066.804fdb522ec8ca6abbdc2c0859c930b9@haskell.org> #13572: Add ArgMin / ArgMax pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 bgamari): * cc: core-libraries-committee@… (added) Comment: Where are you suggesting these are added? I think this should really go through the usual [[https://wiki.haskell.org/Core_Libraries_Committee|libraries process]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 18:48:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 18:48:44 -0000 Subject: [GHC] #13524: GHC does not preserve order of forall'd vars with TypeApplications In-Reply-To: <047.235119fd783f4106c422b2bed378dde5@haskell.org> References: <047.235119fd783f4106c422b2bed378dde5@haskell.org> Message-ID: <062.e4f28ba73a1a0e3af941e3c7809f27b5@haskell.org> #13524: GHC does not preserve order of forall'd vars with TypeApplications -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T13524 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Yes, I've merged this to `ghc-8.2` as ace3117924133b69e9be78d1b1ed76a2f9956d47. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 19:55:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 19:55:01 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.0737a8336c4e8457cfcb6c0b041c4fcb@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm still puzzled by the ''quadrupling'' in compile time describe in the Description. Is that reproducible. Incrasing from 1.8s to 2.6s seems much less dramatic. Bisection is great! I would not have suspected that patch. Inspecting it, I think that perhaps dfuns are specialised after the patch but not before. Try `-dshow-passes` before and after to show code size; and `-ddump-rules` to show what specialision rules have been created (at least for top level things). Then worth checking that the extra specialisations make sense. (I'm assuming that this program does not actually say `-fspecialise- aggressively`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 20:35:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 20:35:48 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.b0446ce77bbcd71500717eaf3caa8701@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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, I just saw this, sorry for the very late reply. I don't think that the original example technically violates the FD property as the second instance (the one with `C Char ...`) is vacuous and doesn't actually add any new instances to `C` (there is no base case). The first instances on its own is OK, so the whole program is OK. I am not sure that this is any easy thing to spot in general though. There is, however, a real problem with the consistency checking of FDs though, as illustrated by the following example: {{{ class F tag a b | a -> b class G a b | a -> b class H a b | a -> b instance G a b => F Int [a] [b] instance H a b => F Char [a] [b] instance G Int Int instance H Int Char }}} These instances are accepted by GHC 8.0.1 but are inconsistent, because we can derive both `F Int [Int] [Int]` and `F Char [Int] [Char]` which violates the FD on `F`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 20:54:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 20:54:27 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ In-Reply-To: <044.319927771157cb149232cac95f75e05c@haskell.org> References: <044.319927771157cb149232cac95f75e05c@haskell.org> Message-ID: <059.ba318884854cbc6f29c1d8adedea6359@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3319 Wiki Page: | -------------------------------------+------------------------------------- Comment (by IlanGodik): Now this update in coming in to everyone, breaking all previous GHC versions. I'd recommend cherry-picking this fix into 8.0 and to 7.10 branches ASAP to allow people to continue using these versions of GHC, also given that 8.2 isn't out yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 20:58:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 20:58:12 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.35122558fb94e3353548fc022e1745f8@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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): * status: new => infoneeded Comment: I'm a bit lost here. Am I to understand from comment:7 that this was an issue in GHC 8.0 that is fixed in 8.2.1-rc1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 21:03:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 21:03:25 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.363c595cc2006037d0dad8852968723d@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #10800 Comment: Note that #10800 is another ticket reporting a compile-time regression in `vector`'s testsuite between GHC 7.8 and 7.10. While it was apparently resolved in GHC 8.0, we never were able to come to a conclusion on what fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 21:04:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 21:04:46 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.bdceb46c26a94e001573e62d1ee04c61@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13535 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13535 Comment: While it's not clear whether it's related in cause, #13535 also reports a compile-time regression in `Tests.Vector`, this time in GHC 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 21:35:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 21:35:25 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod Message-ID: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> #13574: crash when using template haskell and ghc-mod --------------------------------------+--------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- GHC crashes whenever I try to use the ghc-mod tool with even a trivial Template Haskell project. I thought it might be ghc-mod's fault, but a ghc-mod maintainer looked at the info I collected about the bug and he says its a bug in GHC. Here's the discussion about the bug, with the relevant logs and troubleshooting so far: https://github.com/DanielG/ghc-mod/issues/880#issuecomment-293436359 Let me know if it would help to copy+paste that conversation here instead of just providing a link. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 21:37:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 21:37:48 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ In-Reply-To: <044.319927771157cb149232cac95f75e05c@haskell.org> References: <044.319927771157cb149232cac95f75e05c@haskell.org> Message-ID: <059.e625196a8e8c867fbaafd5f32168388b@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3319 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have prepared a new set of tarballs with a patched GCC; they are being uploaded as we speak. I'll send out an announcement tonight when the uploads are complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 22:12:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 22:12:39 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod In-Reply-To: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> References: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> Message-ID: <063.13157b83e906a3de28f8a5d678fb8953@haskell.org> #13574: crash when using template haskell and ghc-mod ---------------------------------+-------------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Is this issue reproducible with GHC 8.0.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 22:42:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 22:42:19 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod In-Reply-To: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> References: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> Message-ID: <063.2fddc8c908efcae002e8f88c40c002a1@haskell.org> #13574: crash when using template haskell and ghc-mod ---------------------------------+-------------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by quisquous): Unfortunately I do not know because GHC 8.0.2 is not yet available as a binary package for OpenBSD 6.0 (or the just released 6.1) and I haven't yet been able to successfully build GHC 8.0.2 on OpenBSD 6.0 on my own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 22:58:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 22:58:54 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.f098b1d49270f204393025ff66577051@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I setup a test environment to build just `tests/Utilities.hs`, `tests/Boilerplater.hs`, and `tests/Tests/Vector.hs` with both GHC 8.3 (13131ce9165b4e5e5193dc381f6f3d021e53792f and 8.0.2. In addition to building `Tests.Vector` as-is, I also built it enabling each of the testcases in the `tests` list individually (that is, commenting out all but one). The result is interesting: While compilation on `master` is significantly faster than 8.0.2 in the individual cases, it is significantly slower when all of the testcases are enabled. Clearly there is something non-linear going on here. I'm on the case. {{{ Building Utilities, Boilerplater, and Tests.Vector of vector 1d208ee9e3a252941ebd112e14e8cd5a982ac2bb GHC 8.3 (13131ce9165b4e5e5193dc381f6f3d021e53792f nothing: <> Data.Vector.Vector (Bool) <> Data.Vector.Vector (Int) <> Data.Vector.Primitive.Vector (Int) <> Data.Vector.Primitive.Vector (Double) <> Data.Vector.Storable.Vector (Int) <> Data.Vector.Storable.Vector (Double) <> Data.Vector.Unboxed.Vector () <> Data.Vector.Unboxed.Vector (Bool) <> Data.Vector.Unboxed.Vector (Int) <> Data.Vector.Unboxed.Vector (Double) <> Data.Vector.Unboxed.Vector (Int,Bool) <> Data.Vector.Unboxed.Vector (Int,Bool,Int) <> everything <> GHC 8.0.2 nothing <> Data.Vector.Vector (Bool) <> Data.Vector.Vector (Int) <> Data.Vector.Primitive.Vector (Int) <> Data.Vector.Primitive.Vector (Double) <> Data.Vector.Storable.Vector (Int) <> Data.Vector.Storable.Vector (Double) <> Data.Vector.Unboxed.Vector () <> Data.Vector.Unboxed.Vector (Bool) <> Data.Vector.Unboxed.Vector (Int) <> Data.Vector.Unboxed.Vector (Double) <> Data.Vector.Unboxed.Vector (Int,Bool) <> Data.Vector.Unboxed.Vector (Int,Bool,Int) <> everything <> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 13 23:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Apr 2017 23:18:28 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.37d4a86dab385338b0fc0afe514f7611@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 pacak): > I'm a bit lost here. Am I to understand from comment:7 that this was an issue in GHC 8.0 that is fixed in 8.2.1-rc1? It can probably be closed for now. The problem is this sample is very fragile - for example if I remove AdditiveGroup instance which is not used at all or even specialization pragma - it suddenly works as expected in ghc 8.0. There are more code using generics in our project. If I find a way to reproduce it for ghc 8.2 - I can reopen it again with new data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 00:23:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 00:23:14 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.934c35237a63bd8a4c2f230d79842a05@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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): Thanks Iavor, * Yes the `C Char ...` instance is vacuous. I think GHC must accept it, because for all it knows there is some other instance decl for `C` that will provide a base case. That tells us we should be cautious if an instance (or set of instances) is accepted: the instances alone are weak evidence until/unless we can prove they can be inhabited. * I think what Simon's worried about is that the two instance decls have got entangled. And yet they don't overlap. So I'd be suspicious we'd see different behaviour under separate compilation. * Your instances for `F` break the FunDep coverage condition, so presumably you needed UndecidableInstances. What's reasonable to expect after that? I did get some types to inhabit those instances; and yes they were inconsistent with the Fundeps on `F`. * I guess GHC with UndecidableInstances sees there's a constraint on the instance (`G`, `H`), and that constraint carries a FunDep, so delegates the FunDep to it. We know GHC doesn't/can't chase round all the constraints, because it can't see all the instances. It delays that check to the use site -- but then that only considers the instances selected at that site. * Constraints like you've put are useful -- the type-level Type Equality test example. Arguably any such Type Equality test breaks '''Definition 6''' Consistency condition. * Does your example actually do any harm anywhere? Could some distant module end up treating an Int as a Char/segfaulting? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 00:25:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 00:25:18 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod In-Reply-To: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> References: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> Message-ID: <063.daec5d2b405822fea2eead403a33852e@haskell.org> #13574: crash when using template haskell and ghc-mod ---------------------------------+-------------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Alright, I can try to reproduce on OpenBSD 6.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 00:31:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 00:31:37 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.24c28c528bcfa14ebcd7b3f3cb947b4a@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13372 | Differential Rev(s): Wiki Page: | Exceptions/StackTraces | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13372 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 00:32:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 00:32:30 -0000 Subject: [GHC] #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base In-Reply-To: <045.e8d5052962549532effd4485f8aa5560@haskell.org> References: <045.e8d5052962549532effd4485f8aa5560@haskell.org> Message-ID: <060.4394301b7e1687101a88abc21351a200@haskell.org> #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12096 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 00:52:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 00:52:13 -0000 Subject: [GHC] #13566: Bigger core size in ghc8 compared to ghc7 In-Reply-To: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> References: <044.851d59ce1ad4816ad5e9fafbe617e627@haskell.org> Message-ID: <059.1aa284afee4c1c4386c2d88f6bc216cb@haskell.org> #13566: Bigger core size in ghc8 compared to ghc7 -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: invalid | 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): * status: infoneeded => closed * resolution: => invalid Comment: Alright, do let us know if you manage to get a clean reproducer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 00:59:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 00:59:23 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.79d170d8a556b3494b53b076b10008a8@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13372 | Differential Rev(s): Wiki Page: | Exceptions/StackTraces | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 01:01:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 01:01:43 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod In-Reply-To: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> References: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> Message-ID: <063.9d416bfd4632cae0b3c4c5abb3f20718@haskell.org> #13574: crash when using template haskell and ghc-mod ---------------------------------+-------------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): I put together [[https://github.com/bgamari/T13574-repro|this]] reproducer from the information you left on the `ghc-mod` ticket. I was unable to reproduce the crash with OpenBSD 6.0 on amd64 and GHC 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 01:36:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 01:36:32 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.d7178fa0aff94716ef87852fae99e60e@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed in most phases of simplification the program with all testcases enabled is roughly three to five times larger in `master` than it was in `8.0.2`. After CorePrep, however, the program is nearly a factor of 8 larger, {{{ # 8.0.2 Result size of CorePrep = {terms: 118,005, types: 138,524, coercions: 50,256} # master Result size of CorePrep = {terms: 796,181, types: 907,739, coercions: 1,094,846, joins: 3,382/34,300} }}} It may also be interesting to note that if you sum the allocations of all of the testcases individually, you get something a bit higher than the allocations required to compile the "everything" case. I wonder if So, there are two (possibly related) questions here: 1. Why did the Core get so much larger from 8.0 to 8.2? 2. How was GHC 8.0 able to compile the "everything" case with less than a factor of two of the allocations of the individual cases, while 8.2 requires a factor of five? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 02:11:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 02:11:27 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.defd57135ae2ddb8287c63890c5cf255@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Comparing the compilation of just the `Data.Vector.Vector (Bool)` with GHC 8.0.2 and 8.2 is also quite interesting: starting early in simplification we see that 8.2's core is typically less than half(!) the size of 8.0's (perhaps some goodness due to early inlining?). For instance, {{{ # 8.0.2 = {terms: 271,375, types: 552,012, coercions: 226,814} # 8.2 Result size of Simplifier iteration=1 = {terms: 105,610, types: 209,276, coercions: 135,191, joins: 299/5,710} }}} This remains the case throughout most of simplification; however, it seems that either Core Tidy or Core Prep cleans things up in 8.0, resulting in rather similar program sizes, {{{ # 8.0.2 Result size of CorePrep = {terms: 56,693, types: 73,297, coercions: 24,938} !!! CorePrep [Tests.Vector]: finished in 135.38 milliseconds, allocated 97.842 megabytes # 8.2 Result size of CorePrep = {terms: 69,730, types: 85,131, coercions: 125,647, joins: 248/2,453} !!! CorePrep [Tests.Vector]: finished in 132.14 milliseconds, allocated 106.584 megabytes }}} Seeing that the Core sizes are comparable when compiling a single testcase, question (2) is becoming quite interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 03:40:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 03:40:51 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.bbafaaa8d1b96cc53f8d9dd74fecf3f5@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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): hmm curioser and curioser. Going back to the O.P., I see this behaviour at both GHC 7.10 and 8.0.1: * Take out the `instance C Char ...`; and `f` is happy with any type of operand, not necessarily a `Maybe`. * Keep in the `instance C Char ...`; but give `f` a signature and again it's happy: `f :: (C Bool [a] [a]) => a -> [a]` * Keep in the `instance C Char ...`; give `f` this signature, and we're back needing `Maybe`: `f :: (C Bool [a] b) => a -> b` So there is something wrong: why is the `C Char ...` instance getting tangled up with the `C Bool ...` instance? The only connection would be checking conformance with FunDeps; but that should be only for validation, not 'type improvement' for function `f`(?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 04:12:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 04:12:46 -0000 Subject: [GHC] #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together In-Reply-To: <050.32ff9ffcd456d5039c2557ae9a212950@haskell.org> References: <050.32ff9ffcd456d5039c2557ae9a212950@haskell.org> Message-ID: <065.65b05bf628c20e2ba935b4d24f22eb32@haskell.org> #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_compile/T13482 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dramforever): Thank you! It's a real pleasure to see a straightforward 'fixed' reply on this :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 10:58:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 10:58:37 -0000 Subject: [GHC] #13575: GHC downloads do not work Message-ID: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> #13575: GHC downloads do not work -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure whether this is the right place for this type of issue, but I cannot download GHC 8.0.2 for i386 debian 8 (http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-i386-deb8-linux.tar.xz) - I get 404 Not Found error from nginx. I tried from 2 different IPs, so the issue is likely not on my side. I tried some other urls and they all result in the same 404 error: * http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-armv7-deb8-linux.tar.xz * http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-centos67-linux.tar.xz * http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-unknown- openbsd.tar.xz * http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-deb8-linux.tar.xz * http://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-src.tar.xz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 13:36:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 13:36:09 -0000 Subject: [GHC] #13575: GHC downloads do not work In-Reply-To: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> References: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> Message-ID: <059.5573675a5c71dc540ba16ab739ac032c@haskell.org> #13575: GHC downloads do not work -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, thanks for reporting this! I'm looking into it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 13:48:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 13:48:15 -0000 Subject: [GHC] #13575: GHC downloads do not work In-Reply-To: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> References: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> Message-ID: <059.114aaff3141704fa4af468921b7cded1@haskell.org> #13575: GHC downloads do not work -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, it seems my upload script replaced the actual tarballs with symlinks. I'm working on uploading them, starting with 8.0.2, but unfortunately it will take a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 13:56:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 13:56:51 -0000 Subject: [GHC] #13575: GHC downloads do not work In-Reply-To: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> References: <044.170356ad5872efe897d21eaa1885b4f7@haskell.org> Message-ID: <059.74c88cb80f3a652cabe2f4d203ef0531@haskell.org> #13575: GHC downloads do not work -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've sent an announcement [[https://mail.haskell.org/pipermail/ghc- devs/2017-April/014124.html|here]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 17:59:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 17:59:50 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) Message-ID: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------------+---------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I compiled GHC from source (ff84d052850b637b0) with a few modifications to create a cross-compiler for arm64. This was the configuration: {{{ CC=aarch64-apple-darwin14-clang ./configure --prefix=/usr/local/ghc-ios --target=aarch64-apple-darwin14 --disable-large-address-space --enable- bootstrap-with-devel-snapshot }}} Here's my "mk/build.mk": {{{ HADDOCK_DOCS=NO WITH_TERMINFO=NO DYNAMIC_BY_DEFAULT=NO DYNAMIC_GHC_PROGRAMS=NO DYNAMIC_TOO=NO }}} I used the stage1 compiler to export an arm64 library. The application (which links the library) crashes when run on my device (iOS 10.2.1). The application runs without issue on x86 and arm32. When I initialize with -DS, I get the following error: {{{ internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 88 (GHC version 8.3.20170408 for aarch64_apple_ios) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug // SIGABRT at line 182 in RtsMessages.c }}} To narrow down the offending code, I replaced all my functions with print statements and slowly added the functionality back until I could reproduce the crash. It looks like the crash happens around a call to this function: {{{ foreign export ccall hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm = hs_toAlgorithmIdentifier hs_toAlgorithmIdentifier :: (ToAlgorithm t a, AlgorithmId a) => StablePtr t -> IO CString hs_toAlgorithmIdentifier ptr = do algId <- fmap (toAlgorithmId . toAlgorithm) $ deRefStablePtr ptr newCString algId }}} Oddly, when I add print statements around this call, I get a EXC_BREAKPOINT instead of a SIGABRT. Here's the output for this case: {{{ ****************TEST************ ****************TEST************ ****************TEST************ ****************TEST************ v1K_FZuskg6Bkm-whFvkQ8IzHxnXDSGibCwbqZpM0fk= here ****************TEST************ here1 here2 }}} I've disabled dead code stripping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 18:16:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 18:16:41 -0000 Subject: [GHC] #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 Message-ID: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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: -------------------------------------+------------------------------------- Thanks to hvr from mentioning this. https://hackage.haskell.org/package/open-symbology-0.1/docs/src/Finance- OpenSymbology-PricingSourceParsers.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 19:01:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 19:01:42 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.26cbed8c3178443b1394db7bb6af6002@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): @simonpj, no I cannot reproduce the claimed regression. I only see the regression Ben noted. I will investigate that one further today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 20:22:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 20:22:08 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.983992ae2e798e78ec1613dca2af0468@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): No, the program doesn't say `-fspecialise-aggressively`. `-dshow-passes` indicates that everything stays the same up until specialization, with `terms: 2,528, types: 2,420, coercions: 214`. In specialization, it previously rose to `terms: 2,601, types: 2,487, coercions: 214`, but after the change instead jumps to `terms: 3,468, types: 3,731, coercions: 214`. Looking at `-ddump-rules`, the difference is pretty dramatic. Before, we had just {{{ "SPEC Control.Monad.when @ (Text.Appar.Parser.MkParser GHC.Base.String)" [ALWAYS] forall ($dMonad :: Monad (MkParser String)). when @ (MkParser String) $dMonad = $swhen }}} After the change, we have many, many rules (I'll attach them). While the specializations all look fairly reasonable to me, I'm not sure we really want quite that many by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 20:25:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 20:25:33 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.6e4a3acf53845bda4db2ec2ec0680a82@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "rules-after" added. Specialization rules after -fspecialise-aggressively commit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 21:05:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 21:05:57 -0000 Subject: [GHC] #13578: Incorrect Record Pattern Synonym example in users guide Message-ID: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> #13578: Incorrect Record Pattern Synonym example in users guide -------------------------------------+------------------------------------- Reporter: cjholdbrooks | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The first example in section 9.7.1 of the users guide provides the example {{{#!hs pattern Point :: (Int, Int) pattern Point{x, y} = (x, y) }}} which results in the error {{{ • Pattern synonym ‘Point’ has two arguments but its type signature has none • In the declaration for pattern synonym ‘Point’ }}} upon load. I believe the correct code is as follows. {{{#!hs pattern Point :: Int -> Int -> (Int, Int) pattern Point{x, y} = (x, y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 14 22:20:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Apr 2017 22:20:23 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod In-Reply-To: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> References: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> Message-ID: <063.a25e6c3d81f8c29e615145908669e4ce@haskell.org> #13574: crash when using template haskell and ghc-mod ---------------------------------+-------------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by DanielG): * cc: DanielG (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 01:39:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 01:39:27 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.dc68193ebfa03f6f82d18679101a212d@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps 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 AntC): * keywords: => FunDeps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 01:53:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 01:53:13 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.17a6e76835608c068a93bb67d1552dcb@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D3424 Comment: I now think I know what's going on here, but unsure the best way to fix it. Interestingly, the problem has nothing to do with `Typeable` or `TypeInType`. Indeed it's amazing we've never hit this problem before. We have {{{ [G] c1 :: k1[tau] ~ j1[tau] }}} in an implication. Both `k1` and `j1` are filled in at this point: `k1 := Type` and `j1 := k2[sk]`. This constraint is then passed through `solveSimpleGivens`, where it is canonicalized. `can_eq_nc'` flattens both sides, following both `k1` and `j1` to find `Type`. `can_eq_nc'` then calls `rewriteEqEvidence` which creates a new {{{ [G] c2 :: Type ~ k2[sk] }}} Of course, GHC produces evidence for `c2`: `c2 = g1 ; c1 ; g2`, where `g1` and `g2` are the coercions that come from flattening `k1` and `j1`. The problem is that these coercions, `g1` and `g2` are both reflexive, as they arise simply from zonking. See the line of code [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcFlatten.hs#L1288 here]. When `c2` is stitched together from `g1`, `c1`, and `g2`, the calls to `mkTcTransCo` notice that some of the arguments are `Refl`, and so ignores the reflexive arguments. The end result is that `c2 = c1`. And then, when `c2` gets put in the inert set, its kind still mentions unzonked variables. (Even though the associated `ctPred` is just fine.) What to do? Here are some ideas: 1. Stop `mkTcTransCo` (but not `mkTransCo`) from optimizing this case. 2. Add a zonk somewhere (`addInertEq`? seems better than `rewriteEqEvidence`) to fix this problem. 3. Add a new coercion form `ZonkCo` that relates an unzonked tyvar to its contents. This way, we can have the invariant that, whenever `(ty', co) <- flatten ty`, we have `co :: ty' ~ ty`. (Right now, that final equality is true only modulo zonking. But the new `ZonkCo` would allow it to be true without needing to zonk.) In fully-typechecked Core, `ZonkCo` would zonk to become reflexive, and so Core would have no `ZonkCo`s. 4. Add a new `castTcCoercion` function that stitches three coercions together using transitivity; this `castTcCoercion` would cleverly not optimize the `Refl` away. I favor (1) but am worried about performance implications. (3) is probably the most principled, but it seems like a sledgehammer to tap in a nail. (4) is a middle ground, but I'm worried that what's happening here (a coercion returned from the flattener having an unzonked kind) happens elsewhere where we wouldn't use `castTcCoercion`. What are your thoughts? (NB: The patch linked to here does not have any of these fixes. I posted that patch some time ago but never added the link from this ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 02:53:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 02:53:56 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.d79ef50b1a427a1f713d640c9232f93d@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies 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 AntC): Replying to Simon: > This would make it possible for given constraints involving fundeps to work properly, which they don't at present (as ​Iavor points out). Iavor is mostly complaining that currently you can declare instances that break FunDeps Consistency. (And because GHC knows that, it is conservative in applying type improvement via FunDeps. Also his examples either break the FunDeps Coverage Condition -- so needing `UndecidableInstances`; or use dependents (rhs of FunDeps arrow) with no free vars, so there's no algorithmic determinism.) If we desugar FunDeps to Type Families, and allow them to be Closed Type Families, then we can carry on breaking FunDeps Consistency, via overlapping equations. If OTOH we desugar FunDeps to Open Type Families, then we can't write overlapping equations; therefore we can't define (for example) a type- level Type Equality test. (This is somewhat orthogonal to whether we can write overlapping instances for the Class.) I can see the combination of FunDeps and `OverlappingInstances` is deadly for consistency. (To be precise, overlap of the determinants for FunDeps, on lhs of the arrow.) I can also see how terrifically useful it is -- for example for all sorts of record-like systems from HList onwards. I think I could make an argument that actually the combo FunDeps+Overlapping is consistent. That would need going back to the database Relational Theory from which Mark Jones borrowed FunDeps. And would require some discipline in what instances you declare. (I think most people actually observe that discipline, but GHC doesn't enforce it. I have an idea how we could help GHC enforce it -- a very old, recycled idea from Tom Schrijvers/CHRs.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 03:03:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 03:03:21 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.9d8277a35b1e2e9ccbebc1174582f613@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * related: #9583, #10293, #13059 => #9583, #10293, #13059, #10818 Comment: It appears that much or all of the regression in the original example occurred in b9e49d3e9580e13d89efd1f779cb76f610e0d6e0. Before, I get {{{ dfeuer at squirrel:~/src/cabal> ~/src/ghc-iproute-before/inplace/bin/ghc- stage2 -Rghc-timing -O -c Cabal/Language/Haskell/Extension.hs <> }}} After, {{{ dfeuer at squirrel:~/src/cabal> ~/src/ghc-iproute-after/inplace/bin/ghc- stage2 -Rghc-timing -O -c Cabal/Language/Haskell/Extension.hs <> }}} Jeepers! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 03:06:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 03:06:34 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.aa294d8a3e73cfe19c13399a65c0ebf5@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #9630 Comment: It looks like the same commit that causes the regression in `Data.IP.Addr` here was also responsible for the much more dramatic `Language.Haskell.Extension` regression described in #9630. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 03:09:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 03:09:07 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.50b27656ed6d6d93a09331aaacb834b9@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9630 | 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 Apr 15 03:19:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 03:19:10 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.e3de23b9bd289c3e1a714413ddf95fba@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Note: b9e49d3e9580e13d89efd1f779cb76f610e0d6e0 added 1024 specialization rules to `-ddump-rules` for this module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 04:08:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 04:08:33 -0000 Subject: [GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode In-Reply-To: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> References: <044.d5acc485a28c44206c1ed91a697769e3@haskell.org> Message-ID: <059.9e6c871a632a84b1826c4c8d23648b99@haskell.org> #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode -------------------------------------+------------------------------------- Reporter: errge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #7867 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Does this still occur? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 09:55:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 09:55:33 -0000 Subject: [GHC] #13579: -fdefer-type-errors and -fdefer-typed-holes flag do not perform their roles Message-ID: <044.4b8419965f2c282b3fb30bef94dff64a@haskell.org> #13579: -fdefer-type-errors and -fdefer-typed-holes flag do not perform their roles -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- with {{{-fdefer-type-errors}}} flag\\ Prelude > {{{let f = [True | x <- [_,_]]}}} raise two warning. Good!.\\ Prelude > {{{f}}}\\ {{{[True, True]}}}\\ With this function \\ Prelude> {{{let f' = [True | x <- [_, _]] in f'}}}\\ GHCi raise two errors. It is not clear! idem with {{{-fdefer-typed-holes}}} flag\\ If you compile, there is a warning and of course no result and after linking an error is raise. This situation is not clear for me.\\ Logically it should have a result.\\ logically the function {{{f}}} and the function {{{f'}}} send a result.\\ Typed Holes worsens in this case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 19:06:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 19:06:16 -0000 Subject: [GHC] #12874: Read/Show Incompatibility in base In-Reply-To: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> References: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> Message-ID: <064.09ed564c42be9a5a50a867629f21e3fd@haskell.org> #12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * component: Compiler => libraries/base Comment: This does indeed seem to be a problem with `Proxy`'s `Read` instance. I've copied its current implementation below: {{{#!hs instance Read (Proxy s) where readsPrec d = readParen (d > 10) (\r -> [(Proxy, s) | ("Proxy",s) <- lex r ]) }}} That `readParen (d > 10)` is a problem, since if the precendence `d` is greater than 10, then in order for parsing to succeed, `"Proxy"` must be surrounded by at least one set of parentheses. But, as you noted, this is too stringent of a requirement, since `show (Thing Proxy)` yields `"Thing Proxy"`, without any parentheses. One way to fix this is to ignore the precedence: {{{#!hs instance Read (Proxy s) where readsPrec _ = readParen False (\r -> [(Proxy, s) | ("Proxy",s) <- lex r ]) }}} Then `"Thing Proxy"`, `"Thing (Proxy)"`, etc. all parse. But then again, this definition is basically equivalent to what `deriving Read` produces. Why not use that? FWIW, `Proxy` isn't the only type to suffer from this problem. It looks like `Coercion`, `:~:`, `:~~:`, and `U1` also have `Read` instances with the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 19:58:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 19:58:44 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.21f0b651e1af7a5127e04144e02eb261@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by SantiM): Hello, I'd be happy to take this issue as my first contribution to GHC. I wanted to ask a few questions first though: 1) I didn't find tests on the 'ghc' command or the "showOptions" function[0]. Any suggestions on where to put the test for this change and how to go about it? 2) We could fix this by just adding 'nub' to the showOptions, but I guess that is not good enough and we probably want to take a look at how flags are registered in DynFlags. Ideas? Thanks [0] https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=showOptions&type= -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 21:37:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 21:37:05 -0000 Subject: [GHC] #13580: TypeApplications: panic from unknown function identifier Message-ID: <046.9424a4a815d11f9c0035ca39aca4aeac@haskell.org> #13580: TypeApplications: panic from unknown function identifier --------------------------------------+--------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Using type application with an unknown function identifier causes ghci to panic: {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XDataKinds Prelude> :set -XTypeApplications Prelude> foo @3 ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] foo_a12q :: t_a12p[tau:1] (CHoleCan: foo) [W] foo_a12O :: t_a12N[tau:1] (CHoleCan: foo)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 22:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 22:13:08 -0000 Subject: [GHC] #13581: UNPACK should allow recursion that obviously terminates Message-ID: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> #13581: UNPACK should allow recursion that obviously terminates -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to do this: {{{ {-# LANGUAGE TypeFamilies MagicHash KindSignatures #-} data Peano = Zero | Succ Peano data family BigWord (n :: Peano) data instance BigWord Zero = MachineWord# Word# data instance BigWord (Succ n) = BigWord {-# UNPACK #-}(BigWord n) {-# UNPACK #-}(BigWord n) }}} However, the compiler tells me that it is ignoring the UNPACKs, and the only reason I can see is that they are apparently recursive. This exact type of recursion is handled just fine in instance declarations because the recursive instance has fewer type constructors than the head; can't UNPACK do the same thing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 22:44:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 22:44:49 -0000 Subject: [GHC] #13574: crash when using template haskell and ghc-mod In-Reply-To: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> References: <048.3f725f38a1daca5e1e68be6158dc5288@haskell.org> Message-ID: <063.0cfd96c78b39577bc259ef073d9e4ae3@haskell.org> #13574: crash when using template haskell and ghc-mod ---------------------------------+-------------------------------------- Reporter: quisquous | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: OpenBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by quisquous): * status: new => closed * resolution: => fixed Comment: I upgraded my machine to OpenBSD 6.1 and I get a permissions issue when running ghc-mod instead: {{{ Failed to execute process '/home/scott/.local/bin/ghc-mod'. Reason: exec: Permission denied }}} and on the console I see: {{{ /home/scott/.local/bin/ghc-mod(78252): W^X binary outside wxallowed mountpoint }}} I suspect the crash I was seeing in 6.0 was related to OpenBSD not allowing WX by default. Workaround is to put the ghc-mod binary in a location that allows WX, like /usr/local, or by setting wxallowed on the /home partition by updating /etc/fstab. In any case, once I set wxallowed on /home, /home/scott/.local/bin/ghc-mod no longer gives a permissions error AND it does not crash when checking a Template Haskell project. I'm going to close the ticket for now, I'll reopen it if I am able repro the crash some other way. Thanks for looking into this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 22:45:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 22:45:01 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.d0d06dcb39a415fd9e86318b6117ff16@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The end result is that c2 = c1. And then, when c2 gets put in the inert set, its kind still mentions unzonked variables. (Even though the associated ctPred is just fine.) I don't see the problem. See `Note [Ct/evidence invariant]` in `TcRnTypes`. The types in evidence terms are no zonked, and that should not matter one whit. Can you explain more precisely what actually goes wrong and why? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 23:20:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 23:20:20 -0000 Subject: [GHC] #13580: TypeApplications: panic from unknown function identifier In-Reply-To: <046.9424a4a815d11f9c0035ca39aca4aeac@haskell.org> References: <046.9424a4a815d11f9c0035ca39aca4aeac@haskell.org> Message-ID: <061.2d4250a8a28f5fcca51592b072b00830@haskell.org> #13580: TypeApplications: panic from unknown function identifier ---------------------------------+-------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13466 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13466 Comment: Closing as a duplicate of #13466 (which is fixed in 8.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 23:28:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 23:28:19 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. Message-ID: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: type-checking | Operating System: Unknown/Multiple errors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE UndecidableInstances #-} import Data.Typeable class First a b c | c -> b where first :: c -> a -> b class Second a b where second :: a -> b instance (Typeable b, First a b c) => Second a c where second = undefined main :: IO () main = print (second (9 :: Int) :: Int) }}} produces the following error message {{{ $ runghc-8.0.2 t.hs t.hs:18:15: error: • No instance for (Typeable b0) arising from a use of ‘second’ • In the first argument of ‘print’, namely ‘(second (9 :: Int) :: Int)’ In the expression: print (second (9 :: Int) :: Int) In an equation for ‘main’: main = print (second (9 :: Int) :: Int) }}} Note that the message does not explain where `b0` comes from. ghc-7.8.3 produced a better error message: {{{ $ runghc-7.8.3 t.hs t.hs:18:15: No instance for (First Int b Int) arising from a use of ‘second’ In the first argument of ‘print’, namely ‘(second (9 :: Int) :: Int)’ In the expression: print (second (9 :: Int) :: Int) In an equation for ‘main’: main = print (second (9 :: Int) :: Int) }}} Doing slight modifications changes the error message that ghc-8.0.2. e.g. {{{ - instance (Typeable b, First a b c) => Second a c where + instance (First a b c, Typeable b) => Second a c where }}} gives the same error as ghc-7.8.3. In a big program the current error is very puzzling. Is ghc picking the wrong error to show? Could it print more errors perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 23:28:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 23:28:55 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. In-Reply-To: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> References: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> Message-ID: <071.1dd35941733f1fbe536da4f81d3cb491@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes 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): * keywords: type-checking errors => type-checking errors multiparameter type classes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 15 23:46:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Apr 2017 23:46:50 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. In-Reply-To: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> References: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> Message-ID: <071.4739b8d635311290a2dc5de30dab388e@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes 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 facundo.dominguez: @@ -45,1 +45,2 @@ - Doing slight modifications changes the error message that ghc-8.0.2. e.g. + Doing slight modifications changes the error message that ghc-8.0.2 shows. + e.g. New description: The following program {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE UndecidableInstances #-} import Data.Typeable class First a b c | c -> b where first :: c -> a -> b class Second a b where second :: a -> b instance (Typeable b, First a b c) => Second a c where second = undefined main :: IO () main = print (second (9 :: Int) :: Int) }}} produces the following error message {{{ $ runghc-8.0.2 t.hs t.hs:18:15: error: • No instance for (Typeable b0) arising from a use of ‘second’ • In the first argument of ‘print’, namely ‘(second (9 :: Int) :: Int)’ In the expression: print (second (9 :: Int) :: Int) In an equation for ‘main’: main = print (second (9 :: Int) :: Int) }}} Note that the message does not explain where `b0` comes from. ghc-7.8.3 produced a better error message: {{{ $ runghc-7.8.3 t.hs t.hs:18:15: No instance for (First Int b Int) arising from a use of ‘second’ In the first argument of ‘print’, namely ‘(second (9 :: Int) :: Int)’ In the expression: print (second (9 :: Int) :: Int) In an equation for ‘main’: main = print (second (9 :: Int) :: Int) }}} Doing slight modifications changes the error message that ghc-8.0.2 shows. e.g. {{{ - instance (Typeable b, First a b c) => Second a c where + instance (First a b c, Typeable b) => Second a c where }}} gives the same error as ghc-7.8.3. In a big program the current error is very puzzling. Is ghc picking the wrong error to show? Could it print more errors perhaps? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 00:17:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 00:17:34 -0000 Subject: [GHC] #13316: Bad inlining cascade leads to slow optimisation In-Reply-To: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> References: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> Message-ID: <061.652b85d152e2787c22c98059d36d92dd@haskell.org> #13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 00:18:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 00:18:00 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.20cd07aa94a3bea9b71e7411404a05de@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 01:21:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 01:21:04 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.bcd431b6d9ecfe73a48f97c4e0c9bd3b@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It turns out that Note is no longer true. See Phab:D3424 for more explanation. There are validation failures there I have not investigated yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 01:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 01:39:55 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.c4f069e7d75d2746ff74866533c891f4@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Replying to [comment:1 SantiM]: > Hello, > Welcome SantiM! > I'd be happy to take this issue as my first contribution to GHC. Great; don't hesitate to ask me if you have any questions. Email (ben @well-typed.com) or IRC (bgamari on `#ghc`) are both fine. > I wanted to ask a few questions first though: > > 1) I didn't find tests on the 'ghc' command or the "showOptions" function[0]. Any suggestions on where to put the test for this change and how to go about it? > I think `testsuite/tests/driver/` is probably best. See [[Building/RunningTests/Adding]] for instructions on adding testcases to the testsuite. > 2) We could fix this by just adding 'nub' to the showOptions, but I guess that is not good enough and we probably want to take a look at how flags are registered in DynFlags. Ideas? > I suspect the issue is that "O" is registered twice (as of 6c05b27e5bafe9f232e7014f4760335f5e3ba591), {{{#!hs ------ Optimisation flags ------------------------------------------ , make_ord_flag defGhcFlag "O" (noArgM (setOptLevel 1)) ... , make_ord_flag defGhcFlag "O" (optIntSuffixM (\mb_n -> setOptLevel (mb_n `orElse` 1))) -- If the number is missing, use 1 }}} However, I believe the former is actually redundant, being handled by the latter. Perhaps try just removing it and adding a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 19:15:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 19:15:26 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ In-Reply-To: <044.319927771157cb149232cac95f75e05c@haskell.org> References: <044.319927771157cb149232cac95f75e05c@haskell.org> Message-ID: <059.b17f60ab6fe4997a98a1bb6ac9cf1f61@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3319 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dyukha): I have downloaded ghc few minutes ago from here https://www.haskell.org/ghc/download_ghc_8_0_2#windows64 , but I still have the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 19:18:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 19:18:58 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ In-Reply-To: <044.319927771157cb149232cac95f75e05c@haskell.org> References: <044.319927771157cb149232cac95f75e05c@haskell.org> Message-ID: <059.afe3cb9da302e0550a5315dc61f759f3@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3319 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Those links have not been updated, please use the correct ones as pointed to by https://mail.haskell.org/pipermail/ghc-devs/2017-April/014131.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 16 23:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Apr 2017 23:06:11 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.bd721d313cc350a414d970b33c07244b@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm working on bisecting this now. Unfortunately, the version/time function is far from monotone, so there may well be multiple issues involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 07:00:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 07:00:51 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.f69fdd3e64458572ea3300f01b657f11@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukexi): * cc: simonmar (added) Comment: Does anyone on specializing in the GHC API have any clues on this? (cc'ing simonmar) (or, ideas on how to track it down, should I get some time to dig back into GHC myself soon) It's a pretty major tax to pay on every program that wants to use the GHC API and also achieve soft-realtime timing, so would love to get it squashed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 08:51:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 08:51:35 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.0407d4518377931fa181ced8aca4527d@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: SantiM Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by SantiM): * owner: (none) => SantiM -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 09:55:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 09:55:28 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.6a04979230865f91442fe7474ff4891c@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: SantiM Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:B15301 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by SantiM): * differential: => Phab:B15301 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 10:12:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 10:12:55 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.6156c6887fdbde3a6e04e0d3174ed46e@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @rwbarton's comment above is correct. GHC keeps a hash table of strings (the `FastString` table) that is never deallocated. This is likely the 20MB you're seeing. If this is really a problem for you, then we could provide a way via the GHC API to clear the table. (but I'm surprised if this is really a problem, GHC will keep a lot of other data structures while it is being used, such as all the interface files it read) `resetCAFs` only applies to code that is dynamically loaded by the RTS linker, so it's not doing anything in your case - the ghc package is statically linked into your binary. You do need to force a major GC as @rwbarton mentioned to get the RTS to return memory to the OS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 11:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 11:28:11 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.cd6790ddd10f90685609c200b2ed9c84@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * Attachment "LeakyResetStringTable.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 11:33:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 11:33:09 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.e1588808aba5bd7d82e40c39dd217f60@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): I used to think it's the `FastString` table too because some initial profiling data pointed to retainers being in `FastString.`. After some experimentation I dropped that hypothesis because 1) the memory consuption didn't change when I cleared the table and 2) the retainers actually disappeared from the profile after I made some changes (the details of which I do not recall) to the testcase to yield the current version. See also https://github.com/DanielG/ghc-mod/issues/834#issuecomment-271056632. FYI I patched GHC to export `string_table` and just re-initialized it before going into the loop. See the attached modified test case `LeakyResetStringTable.hs`. I'm not quite sure where this 20M number is coming from. My memory usage observations are based on [1] and [2] for all inclusive memory usage and Haskell heap only usage respectively. [1]: {{{ echo $(( $(ps -eo size,pid,user,command --sort -size | grep Leaky | head -n1 | cut -d " " -f 1) / 1024 )) }}} [2]: {{{ echo $(( $(pmap $(pgrep Leaky) | grep 200000000 | tr -s ' ' | cut -d ' ' -f 2 | sed 's/K$//') / 1024 )) }}} As far as `rts_performMajorGC` goes I tried that of course which is why included it as a comment in the testcase. I just wasn't sure if it was actually necessary especially since I could reproduce the same memory usage with and without it. Thanks for clarifying that though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 11:34:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 11:34:34 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * Attachment "LeakyResetStringTable.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 11:34:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 11:34:34 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.fb218378ff2e4488c0ab5a2a9a839705@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * Attachment "LeakyResetStringTable.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 12:45:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 12:45:59 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.a6179919f3058701bb8c314c5f7b57f2@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: SantiM Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3461 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * differential: Phab:B15301 => Phab:D3461 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 12:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 12:57:00 -0000 Subject: [GHC] #4417: Quasiquoting without bloating In-Reply-To: <047.e50066cfaf438f3edf8ca92ae62625d5@haskell.org> References: <047.e50066cfaf438f3edf8ca92ae62625d5@haskell.org> Message-ID: <062.af5ad5fdd5011f822ef71e9fe29dd16a@haskell.org> #4417: Quasiquoting without bloating -------------------------------------+--------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: executable size Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"a92ff5d66182d992d02dfaad4c446ad074582368/ghc" a92ff5d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a92ff5d66182d992d02dfaad4c446ad074582368" hs_add_root() RTS API removal Before ghc-7.2 hs_add_root() had to be used to initialize haskell modules when haskell was called from FFI. commit a52ff7619e8b7d74a9d933d922eeea49f580bca8 ("Change the way module initialisation is done (#3252, #4417)") removed needs for hs_add_root() and made function a no-op. For backward compatibility '__stginit_' symbol was not removed. This change removes no-op hs_add_root() function and unused '__stginit_' symbol from each haskell module. Signed-off-by: Sergei Trofimovich Test Plan: ./validate Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3460 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 12:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 12:57:00 -0000 Subject: [GHC] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain In-Reply-To: <045.7911c27a1a92708be5cdea967d156927@haskell.org> References: <045.7911c27a1a92708be5cdea967d156927@haskell.org> Message-ID: <060.78c7a51b118de784191694c7e87fc60b@haskell.org> #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain -------------------------------------+--------------------------------- Reporter: duncan | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler (FFI) | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"a92ff5d66182d992d02dfaad4c446ad074582368/ghc" a92ff5d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a92ff5d66182d992d02dfaad4c446ad074582368" hs_add_root() RTS API removal Before ghc-7.2 hs_add_root() had to be used to initialize haskell modules when haskell was called from FFI. commit a52ff7619e8b7d74a9d933d922eeea49f580bca8 ("Change the way module initialisation is done (#3252, #4417)") removed needs for hs_add_root() and made function a no-op. For backward compatibility '__stginit_' symbol was not removed. This change removes no-op hs_add_root() function and unused '__stginit_' symbol from each haskell module. Signed-off-by: Sergei Trofimovich Test Plan: ./validate Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3460 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 15:26:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 15:26:19 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.293eb7851311a06b8e0b9adc37504bfd@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: SantiM Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3461 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by SantiM): Thanks for the tips Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 16:45:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 16:45:43 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ In-Reply-To: <044.319927771157cb149232cac95f75e05c@haskell.org> References: <044.319927771157cb149232cac95f75e05c@haskell.org> Message-ID: <059.c588757e9c138e6db14edf1f938f62a4@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3319 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The announcement is [[https://mail.haskell.org/pipermail/ghc- devs/2017-April/014123.html|here]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 17:04:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 17:04:20 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure Message-ID: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) 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: -------------------------------------+------------------------------------- A followup on comments around https://phabricator.haskell.org/rGHC79848f18805a The following does not work currently: {{{ $ ./configure \ --enable-unregisterised \ --enable-bfd-debug \ NM=gcc-nm \ AR=gcc-ar \ RANLIB=gcc-ranlib ... ar : /usr/bin/ar ld : /usr/bin/ld nm : /usr/bin/nm objdump : /usr/bin/objdump ranlib : /usr/bin/ranlib }}} The workaround is to use {{{ $ ./configure --enable-unregisterised \ --with-nm=gcc-nm \ --with-ar=gcc-ar \ --with-ranlib=gcc-ranlib }}} The plan is to make it work (perhaps by using '''AC_PROG_AR'''?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 17:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 17:50:21 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.1256ffa157a6e5a73e60c690274ee663@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): All right. I believe I've pinned this down to 45d9a15c4b85a2ed89579106bdafd84accf2cb39 ("Fix a huge space leak in the mighty Simplifier"). * Before: 2.5GB allocated in 4.3s * After: 28.2GB allocated in 19s That's over ten times the allocation, and over 4 times the time! I'll start taking a look at why that may be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 19:15:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 19:15:08 -0000 Subject: [GHC] #13584: ghci parse error on operator info Message-ID: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> #13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Keywords: parse, info, | Operating System: Linux operator | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If requested info about some operator, ie `(+)` `:info (+)` is working as expected: {{{#!haskell > :i (+) class Num a where (+) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 + }}} When additional space character is there `:info (+ )` it won't parse: {{{#!haskell > :i (+ ) :1:3: error: parse error (possibly incorrect indentation or mismatched brackets) }}} Note that the same thing is working with `:type` so its strange it doesn't use the same parser here and there:ž {{{#!haskell > :t (+ ) (+ ) :: Num a => a -> a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 19:16:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 19:16:44 -0000 Subject: [GHC] #13584: ghci parse error on operator info In-Reply-To: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> References: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> Message-ID: <061.bcc7a4a70229b4a7889eac8799be4f82@haskell.org> #13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: parse, info, | operator 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: | -------------------------------------+------------------------------------- Description changed by akegalj: @@ -21,1 +21,1 @@ - use the same parser here and there:ž + use the same parser in both places: New description: If requested info about some operator, ie `(+)` `:info (+)` is working as expected: {{{#!haskell > :i (+) class Num a where (+) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 + }}} When additional space character is there `:info (+ )` it won't parse: {{{#!haskell > :i (+ ) :1:3: error: parse error (possibly incorrect indentation or mismatched brackets) }}} Note that the same thing is working with `:type` so its strange it doesn't use the same parser in both places: {{{#!haskell > :t (+ ) (+ ) :: Num a => a -> a -> a }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 17 23:22:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Apr 2017 23:22:58 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.d78c9208638a83c4d1cc9a7f32e747dd@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 nomeata): Is memcpy faster than a local loop? Also, would you memcpy the fields before, then set the field, and the fields after? Or would you rather memcpy the whole thing in one go, and then set the single field? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 00:35:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 00:35:17 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.0e1f4ef799e7f90bbddcb6ae19d3e4eb@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) 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 Ben Gamari ): In [changeset:"1cc82d38759c7a5f527ccc6cb514b8ba576cc3d1/ghc" 1cc82d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1cc82d38759c7a5f527ccc6cb514b8ba576cc3d1" utils: Lazily decode UTF8 strings Reviewers: austin, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #13527 Differential Revision: https://phabricator.haskell.org/D3442 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 00:35:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 00:35:17 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.1d15f140233997dee6100cc63373c69b@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: SantiM Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3461 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"b894f02058a10b5b0a4074020feae2771e793577/ghc" b894f02/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b894f02058a10b5b0a4074020feae2771e793577" Remove redundant flag (-O) registration (fixes #13392) Reviewers: austin, bgamari, dfeuer Reviewed By: bgamari, dfeuer Subscribers: rwbarton, thomie GHC Trac Issues: #13392 Differential Revision: https://phabricator.haskell.org/D3461 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 01:05:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 01:05:19 -0000 Subject: [GHC] #13504: registerTimeout can wait too little because it uses Doubles for times In-Reply-To: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> References: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> Message-ID: <057.8479e589b83dd58620cad051ba3c745f@haskell.org> #13504: registerTimeout can wait too little because it uses Doubles for times -------------------------------------+------------------------------------- Reporter: nh2 | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | 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): Phab:D3417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Resolved in ab2dcb1c474d918efdc875f3cca7ef5b6ebdce1a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 01:06:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 01:06:27 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice In-Reply-To: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> References: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@haskell.org> Message-ID: <061.f94eddf63c463fa6aec86564c07bbe1f@haskell.org> #13392: ghc --show-options lists flags twice ---------------------------------+-------------------------------------- Reporter: ThreeFx | Owner: SantiM Type: bug | Status: closed Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3461 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Thanks for the patch, SantiM! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 02:47:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 02:47:24 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.fd2d505f680f0dca2184eb9b34a1dc2b@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As I suspected, there appears to be a large number of duplicate top-level bindings in the code that gets passed Core Tidy in 8.2. In particular, I count at least 25 copies of the same binding, {{{#!hs $s$wfoldlM_loop :: State# RealWorld-> [] Bool-> Int#-> MutableArray# RealWorld Bool-> Int#-> Int#-> (#,#) (TupleRep ([] RuntimeRep)) LiftedRep (State# RealWorld) (Vector Bool) {- Core Size{terms=209 types=244 cos=466 vbinds=7 jbinds=0} -} $s$wfoldlM_loop = ... }}} I'll need to work out why tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 03:11:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 03:11:08 -0000 Subject: [GHC] #13528: Unqualified export of constructors doesn't work anymore In-Reply-To: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> References: <047.a722cb5fe6e3ea3cd40da5795014a03d@haskell.org> Message-ID: <062.67d83a386f0a673c007dc316321b71af@haskell.org> #13528: Unqualified export of constructors doesn't work anymore -------------------------------------+------------------------------------- Reporter: dmendler | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: module/T13528 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as fd6b7f5619a17aca531e3d8908e36d5961beffd2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:05:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:05:16 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.2bb831c8ffb0410ca3d511a3357874c6@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): #5775 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I've tried both examples with 8.2.1-rc1 and indeed INLINE vs. NOINLINE makes no difference. My original big program is 10% faster than with 8.0.1 (I guess most of that is due to GHC, but some may also be due to newer containers, etc.). Congratulations! Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:05:47 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.7612bdeb82956064f89a82be24659329@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JoinPoints Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): #5775 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:23:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:23:38 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics Message-ID: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Panic.hs: {{{ module Panic where import Control.Lens.Wrapped import Data.Monoid foo :: Maybe String foo = ala Last foldMap [Just "foo"] }}} main.hs: {{{ module Main where import Panic (foo) main :: IO () main = print foo }}} {{{ $ ghc -c -O2 Panic.hs $ ghc -c -O2 main.hs ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170404 for x86_64-unknown-linux): splitTyConApp (Exchange (Unwrapped (Last String)) (Unwrapped (Last String)) |> <* -> * -> *>_N) (Maybe [Char]) ((Identity |> <* -> *>_N) (Maybe [Char])) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1105:34 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The GHC version is 8134f7d4ba2c14b2f24d2f4c1f5260fcaff3304a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:24:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:24:34 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory Message-ID: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | 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) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13379 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is probably not reproducible with a small example.) When I build this project with `cabal build` https://github.com/LambdaHack/LambdaHack/commit/138123ab13edd4db6c8143720af68b6ec4a1726e the peek memory, as observed with `top`, is 10G*. When I instead interrupt the compilation with `^C` at the following point (compilation of this file take a couple of minutes, so it's easy to interrupt): {{{ [123 of 123] Compiling Game.LambdaHack.SampleImplementation.SampleMonadServer ( Game/LambdaHack/SampleImplementation/SampleMonadServer.hs, dist/build/Game/LambdaHack/SampleImplementation/SampleMonadServer.o ) }}} and then restart and continue to the end, peek memory usage in either of the two compilation parts is 5G*. So it seems `ghc --make` keeps some data that is either eventually not used or could as well be read on demand instead of kept in memory. Confirmed with 8.2.1-rc1 as well, but it's not trivial to compile due to restrictive upper bounds of many packages. *exact numerical values are made up -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:34:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:34:03 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.d2e465c956d38baa442d1a8404ca3926@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by fumieval: @@ -46,0 +46,3 @@ + + Control.Lens.Wrapped is from the latest version of lens on GitHub: + https://github.com/ekmett/lens/blob/9c4447de7ef57f67dbe293320d45bd8a546be522/src/Control/Lens/Wrapped.hs New description: Panic.hs: {{{ module Panic where import Control.Lens.Wrapped import Data.Monoid foo :: Maybe String foo = ala Last foldMap [Just "foo"] }}} main.hs: {{{ module Main where import Panic (foo) main :: IO () main = print foo }}} {{{ $ ghc -c -O2 Panic.hs $ ghc -c -O2 main.hs ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170404 for x86_64-unknown-linux): splitTyConApp (Exchange (Unwrapped (Last String)) (Unwrapped (Last String)) |> <* -> * -> *>_N) (Maybe [Char]) ((Identity |> <* -> *>_N) (Maybe [Char])) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1105:34 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The GHC version is 8134f7d4ba2c14b2f24d2f4c1f5260fcaff3304a. Control.Lens.Wrapped is from the latest version of lens on GitHub: https://github.com/ekmett/lens/blob/9c4447de7ef57f67dbe293320d45bd8a546be522/src/Control/Lens/Wrapped.hs -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:35:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:35:21 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.1b70e1383671f3dc836b77392d5f07b2@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry, but I still don't get it. Why don't we fix the bug that makes the Note untrue? I do not understand why it's bad for an evidence term (which the constraint solver never looks at) to be Refl, if it relates two types that are equal after zonking. Your diagnosis concludes > And then, when c2 gets put in the inert set, its kind still mentions unzonked variables. But you do not say why that matters. I think it should not matter. Can you explain more precisely what goes wrong and why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:47:51 -0000 Subject: [GHC] #13581: UNPACK should allow recursion that obviously terminates In-Reply-To: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> References: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> Message-ID: <063.fbff69409705f29e0cd54fbf868f409d@haskell.org> #13581: UNPACK should allow recursion that obviously terminates -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): No, the reason that GHC can't act on the unpacks is that it processes each `data instance` declaration, once and for all, when it encounters it. So it bahveas much as if it saw {{{ type instance BigWord (Succ n) = BigWord_Succ n data BigWord_Succ n = BigWord {-# UNPACK #-}(BigWord n} {-# UNPACK #-}(BigWord n) }}} At this point it can't unpack those fields because it has no idea what `n` is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 07:57:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 07:57:26 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. In-Reply-To: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> References: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> Message-ID: <071.3304690916a95e6ca6e772ebf0e129d0@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you saying that GHC 7.8's error message is better because it mentions `b` rather than `b0`? HEAD also use `b0` rather than `b`. Really there are two unsolved constraint: {{{ [WD] $dFirst_a2yX {1}:: First Int b0_a2yW[tau:1] Int (CDictCan) [WD] $dTypeable_a2yY {1}:: Typeable b0_a2yW[tau:1] (CDictCan) }}} Both mention the same unification variable. I don't know why 7.8 reports it differently. But you are right. The Big Thing is that ''unification variables currently do not record their origin''. Would it be better to say this? {{{ b0 is a unification variable arising from instantiating the call to 'second' on line 18 }}} But actually even that is not right. `b0` arises from using the instance declaration to simplify the constraint `Second Int Int`, which itself arises from the call to `second`. What would you LIKE it to say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 08:53:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 08:53:16 -0000 Subject: [GHC] #13581: UNPACK should allow recursion that obviously terminates In-Reply-To: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> References: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> Message-ID: <063.99c1764dd3c46970dec802d2ee57a87d@haskell.org> #13581: UNPACK should allow recursion that obviously terminates -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryanreich): When you say that it has no idea what `n` is, do you mean that it can't figure out if it is `Zero` or not, or that it can't unpack `BigWord n` at all simply because `n` is polymorphic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 10:05:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 10:05:56 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.6f867d273847b701d119c117b11fd098@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 simonpj): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 10:31:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 10:31:01 -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.6deff3ae9c9b569c4d7b707d59bbafd3@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Using the types from [https://github.com/goldfirere/glambda/blob/master/src/Language/Glambda/Type.hs Glambda], can we use this to implement {{{#!hs refineTy_ :: Ty -> (forall ty. ITy ty => Proxy ty -> r) -> r refineTy_ IntTy k = k @Int Proxy refineTy_ BoolTy k = k @Bool Proxy refineTy_ (Arr a b) k = refineTy a $ \(Proxy :: Proxy a_ty) -> refineTy a $ \(Proxy :: Proxy b_ty) -> k @(a_ty -> b_ty) Proxy }}} without `Proxy ty`? {{{#!hs refineTy_ :: Ty -> (forall ty. ITy ty => r) -> r refineTy_ IntTy k = k @Int refineTy_ BoolTy k = k @Bool refineTy_ (Arr a b) k = refineTy a $ \@a_ty -> refineTy a $ \@b_ty -> k @(a_ty -> b_ty) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 10:33:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 10:33:14 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.0a5d6d74096436da82da35beb1d7d161@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you describe how to reproduce this test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 10:38:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 10:38:52 -0000 Subject: [GHC] #13581: UNPACK should allow recursion that obviously terminates In-Reply-To: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> References: <048.f867a1a4b8d2a91a747709fa6afb4153@haskell.org> Message-ID: <063.81fae78cc20c47e578b56db18fd9a80b@haskell.org> #13581: UNPACK should allow recursion that obviously terminates -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I mean that given {{{ data BigWord_Succ n = BigWord {-# UNPACK #-}(BigWord n} {-# UNPACK #-}(BigWord n) }}} `n` is clearly polymorphic, so GHC can't simplify `(BigWord n)`. And if it can't simplify it, it can't unpack it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 10:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 10:59:12 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.261b54b31395c04b42d26b98ac913c1c@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) 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) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Mikołaj, does that problem happen with earlier versions of GHC? Or: to what extent does this happen with earlier versions? I have run into the same problem on my old laptop with 2GB of RAM. With larger projects I often had to kill the build because the system ran out of memory, but then restarting the build lead to successful completion. One symptom I also experienced was a very long linking time, something that did not happen with GHC 7.10 or 7.8. I speculate that the cause might have been due to cluttering the memory with unnecessary data left from compilation and then running the linker lead to swapping. Again, restarting the build to just finish linking would solve the problem, ie. linking finishing in reasonable time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 11:41:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 11:41:46 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell Message-ID: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- The following untyped Template Haskell works as expected: {{{#!hs --- AddTopDecls.hs --- {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} module AddTopDecls where import Language.Haskell.TH import Language.Haskell.TH.Syntax importDoubleToDouble :: String -> ExpQ importDoubleToDouble fname = do n <- newName fname d <- forImpD CCall unsafe fname n [t|Double -> Double|] addTopDecls [d] varE n --- Main.hs --- {-# LANGUAGE TemplateHaskell #-} module Main where import AddTopDecls main :: IO () main = do let sin' = $(importDoubleToDouble "sin") cos' = $(importDoubleToDouble "cos") -- print (sin' 0) print (cos' pi) }}} However it fails if I convert to the equivalent typed version: {{{#!hs --- AddTopDecls.hs --- {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} module AddTopDecls where import Language.Haskell.TH import Language.Haskell.TH.Syntax importDoubleToDouble :: String -> Q (TExp (Double -> Double)) importDoubleToDouble fname = do n <- newName fname d <- forImpD CCall unsafe fname n [t|Double -> Double|] addTopDecls [d] unsafeTExpCoerce (varE n) --- Main.hs --- {-# LANGUAGE TemplateHaskell #-} module Main where import AddTopDecls main :: IO () main = do let sin' = $$(importDoubleToDouble "sin") cos' = $$(importDoubleToDouble "cos") -- print (sin' 0) print (cos' pi) }}} With the error: {{{ > ghci Main.hs -ddump-splices GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling AddTopDecls ( AddTopDecls.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:9:19-44: Splicing expression importDoubleToDouble "sin" ======> sin_a4s2 Main.hs:1:1: Splicing top-level declarations added with addTopDecls ======> foreign import ccall unsafe "sin" Main.sin :: Double -> Double Main.hs:9:19: error: • GHC internal error: ‘sin_a4s2’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a4dl :-> Identifier[sin'::t1, TopLevelLet [] False], a4dm :-> Identifier[cos'::t1, TopLevelLet [] False], r4cW :-> Identifier[main::IO (), TopLevelLet]] • In the expression: sin_a4s2 In the result of the splice: $importDoubleToDouble "sin" To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(importDoubleToDouble "sin") | 9 | let sin' = $$(importDoubleToDouble "sin") | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Tested with 7.10.3, 8.0.2, and 8.2.0-rc1. Unfortunately I can't use untyped TH in my real use case, so if you have any suggestions for a workaround that would also be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 12:09:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 12:09:45 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.e324d72b9bfa1c14af70f3b7b72a8eb8@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 bgamari): It's best not to view `memcpy` as a "normal" function. C compilers are generally quite eager to inline and unroll small `memcpy`s and will choose from among multiple implementation depending upon the known alignment and size of the copy. Moreover, they also generally have optimization passes which look for code that functionally resembles `memcpy` and replaces it with the builtin. My understanding is that the advantage of `memcpy` is generally felt when you have blocks of multiples of the wordsize as this allows you to leverage the target's SIMD instructions, using its full memory bandwidth. Consequently, the best case here would be that you memcpy the whole heap object and then do whatever updates are necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 12:25:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 12:25:47 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.81632aa9d503a63f16faee11e8e423e1@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd love to reproduce this, but I can't seem to install `lens` with `HEAD`: {{{ cabal install --allow-newer lens --with- ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 Resolving dependencies... Configuring comonad-5... Failed to install comonad-5 Build log ( /home/simonpj/.cabal/logs/comonad-5.log ): cabal: Entering directory '/tmp/cabal-tmp-55183/comonad-5' cabal: Leaving directory '/tmp/cabal-tmp-55183/comonad-5' cabal: Error: some packages failed to install: adjunctions-4.3 depends on comonad-5 which failed to install. bifunctors-5.4.1 depends on comonad-5 which failed to install. comonad-5 failed during the configure step. The exception was: user error ('/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2' exited with an error: /tmp/cabal-tmp-55183/comonad-5/dist/setup/setup.hs:8:31: error: Module ‘Distribution.Package’ does not export ‘PackageName(PackageName)’ | 8 | import Distribution.Package ( PackageName(PackageName), Package, PackageId, InstalledPackageId, packageVersion, packageName ) | ^^^^^^^^^^^^^^^^^^^^^^^^ ) free-4.12.4 depends on comonad-5 which failed to install. kan-extensions-5.0.1 depends on comonad-5 which failed to install. lens-4.15.1 depends on comonad-5 which failed to install. profunctors-5.2 depends on comonad-5 which failed to install. semigroupoids-5.1 depends on comonad-5 which failed to install. simonpj at cam-05-unx:~/code/HEAD-4$ }}} Not sure how to proceed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 12:51:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 12:51:28 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. In-Reply-To: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> References: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> Message-ID: <071.be64393a1a698982ec4f7232944b349f@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes Operating System: 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): > Are you saying that GHC 7.8's error message is better because it mentions b rather than b0? No. It is better because it gives you a clue of how to fix it: Add an instance of `First Int b Int`. In contrast: {{{ No instance for (Typeable b0) arising from a use of ‘second’ }}} gives no clue of what the problem is. How does the user infer from this that the instance `First Int b Int` is missing? Consider that: * Even if `b0` is renamed to `b`, the user stays wondering which of all the `b`s in the program it might be. The class hierarchy might have multiple levels. * Even if we understood which class is introducing the constraint, we might not know which instantiation of the other type class parameters is being attempted. > What would you LIKE it to say? {{{ No instance for (Typeable b0) arising from a use of ‘second’ from instance 'Second Int Int' which needs missing instances 'Typeable b' and 'First Int b Int'. }}} If there are more levels in the class hierarchy, the whole path to the missing instances should be reported from the method that the user called. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:21:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:21:30 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.df0be88dba55e8e7cd6432641bb02060@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): pacak on `#ghc` has also reported this and is currently working on a more minimal reproducer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:25:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:25:52 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.32e1b0f740deb2917db6cffa7c06808f@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Lens.hs {{{ {-# LANGUAGE KindSignatures, RankNTypes, TypeFamilies, MultiParamTypeClasses, FlexibleInstances,UndecidableInstances #-} module Lens where import Data.Monoid (First(..)) import Data.Functor.Identity class Profunctor p where dimap :: (a -> b) -> (c -> d) -> p b c -> p a d dimap f g = lmap f . rmap g {-# INLINE dimap #-} lmap :: (a -> b) -> p b c -> p a c lmap f = dimap f id {-# INLINE lmap #-} rmap :: (b -> c) -> p a b -> p a c rmap = dimap id {-# INLINE rmap #-} data Exchange a b s t = Exchange (s -> a) (b -> t) instance Functor (Exchange a b s) where fmap f (Exchange sa bt) = Exchange sa (f . bt) {-# INLINE fmap #-} instance Profunctor (Exchange a b) where dimap f g (Exchange sa bt) = Exchange (sa . f) (g . bt) {-# INLINE dimap #-} lmap f (Exchange sa bt) = Exchange (sa . f) bt {-# INLINE lmap #-} rmap f (Exchange sa bt) = Exchange sa (f . bt) {-# INLINE rmap #-} withIso :: AnIso s t a b -> ((s -> a) -> (b -> t) -> r) -> r withIso ai k = case ai (Exchange id Identity) of Exchange sa bt -> k sa (runIdentity undefined bt) {-# INLINE withIso #-} type Iso s t a b = forall p f. (Profunctor p, Functor f) => p a (f b) -> p s (f t) type Iso' s a = Iso s s a a type AnIso s t a b = Exchange a b a (Identity b) -> Exchange a b s (Identity t) class (Rewrapped s t, Rewrapped t s) => Rewrapping s t instance (Rewrapped s t, Rewrapped t s) => Rewrapping s t instance (t ~ First b) => Rewrapped (First a) t instance Wrapped (First a) where type Unwrapped (First a) = Maybe a _Wrapped' = iso getFirst First {-# INLINE _Wrapped' #-} class Wrapped s => Rewrapped (s :: *) (t :: *) class Wrapped s where type Unwrapped s :: * _Wrapped' :: Iso' s (Unwrapped s) _Wrapping :: Rewrapping s t => (Unwrapped s -> s) -> Iso s t (Unwrapped s) (Unwrapped t) _Wrapping _ = _Wrapped {-# INLINE _Wrapping #-} iso :: (s -> a) -> (b -> t) -> Iso s t a b iso sa bt = dimap sa (fmap bt) {-# INLINE iso #-} _Wrapped :: Rewrapping s t => Iso s t (Unwrapped s) (Unwrapped t) _Wrapped = withIso _Wrapped' $ \ sa _ -> withIso _Wrapped' $ \ _ bt -> iso sa bt {-# INLINE _Wrapped #-} au :: Functor f => AnIso s t a b -> ((b -> t) -> f s) -> f a au k = withIso k $ \ sa bt f -> fmap sa (f bt) {-# INLINE au #-} ala :: (Functor f, Rewrapping s t) => (Unwrapped s -> s) -> ((Unwrapped t -> t) -> f s) -> f (Unwrapped s) ala = au . _Wrapping {-# INLINE ala #-} }}} Panic.hs {{{ module Panic where import Lens import Data.Monoid extractZonedTime :: Maybe () extractZonedTime = ala First foldMap [Nothing] }}} Main.hs {{{ module Main where import Panic (extractZonedTime) main :: IO () main = print extractZonedTime }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:26:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:26:20 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.642f1b312b56b8173fa37257cdd91d62@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): compile with {{{ #!/bin/sh rm *.hi *.o ghc -c Lens.hs -O ghc -c Panic.hs -O ghc -c Main.hs -O }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:32:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:32:54 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.dc542046fd2cc9bedf4f451a2a12787f@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): ghc 8.0.1: successfull compilation ghc 8.2rc: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170404 for x86_64-unknown-linux): splitTyConApp (Exchange (Unwrapped (First ())) (Unwrapped (First ())) |> <* -> * -> *>_N) (Maybe ()) ((Identity |> <* -> *>_N) (Maybe ())) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1105:34 in ghc:Type 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 Apr 18 13:48:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:48:25 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.6a331ef6505bfcf0decb508a1f3b6583@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) 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) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -24,0 +24,3 @@ + + Edit: this is a regression, GHC 7.10.3 uses < 3G for compilation without + even interrupting New description: (This is probably not reproducible with a small example.) When I build this project with `cabal build` https://github.com/LambdaHack/LambdaHack/commit/138123ab13edd4db6c8143720af68b6ec4a1726e the peek memory, as observed with `top`, is 10G*. When I instead interrupt the compilation with `^C` at the following point (compilation of this file take a couple of minutes, so it's easy to interrupt): {{{ [123 of 123] Compiling Game.LambdaHack.SampleImplementation.SampleMonadServer ( Game/LambdaHack/SampleImplementation/SampleMonadServer.hs, dist/build/Game/LambdaHack/SampleImplementation/SampleMonadServer.o ) }}} and then restart and continue to the end, peek memory usage in either of the two compilation parts is 5G*. So it seems `ghc --make` keeps some data that is either eventually not used or could as well be read on demand instead of kept in memory. Confirmed with 8.2.1-rc1 as well, but it's not trivial to compile due to restrictive upper bounds of many packages. *exact numerical values are made up Edit: this is a regression, GHC 7.10.3 uses < 3G for compilation without even interrupting -- Comment (by MikolajKonarski): Jan, that was a great hunch --- indeed, this is a regression, GHC 7.10.3 uses < 3G for compilation without even interrupting. It's possible, different versions of some packages I use under 7.10.3 may contribute, but I'd be surprised if it wasn't almost completely the change of GHC version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:49:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:49:07 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.059144bd145437dc78339b9f11be1efc@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #13586 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:54:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:54:15 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.eb3bd744c76246da22d7287c9b687c86@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): You should be able to reproduce this with, {{{ $ git clone git://github.com/haskell/vector $ cd vector $ git checkout 1d208ee9e3a252941ebd112e14e8cd5a982ac2bb $ cabal install . --allow-newer=base,directory,process,haskeline,time,unix --disable-library-profiling --enable-test $ time ghc -no-link \ -i \ -idist/build/vector-tests-O2/vector-tests-O2-tmp \ -itests \ -idist/build/vector-tests-O2/autogen \ -idist/build/global-autogen \ -Idist/build/vector-tests-O2/autogen \ -Idist/build/global-autogen \ -Idist/build/vector-tests-O2/vector-tests-O2-tmp \ -optP-include \ -optPdist/build/vector-tests-O2/autogen/cabal_macros.h \ -XHaskell2010 \ -XCPP \ -XScopedTypeVariables \ -XPatternGuards \ -XMultiParamTypeClasses \ -XFlexibleContexts \ -XRank2Types \ -XTypeSynonymInstances \ -XTypeFamilies \ -XTemplateHaskell \ tests/Tests/Vector \ -O2 \ -Wall \ -fno-warn-orphans \ -fno-warn-missing-signatures \ -Wno-name-shadowing \ -Wno-unused-binds \ -Wno-unused-matches \ -Wno-unused-imports \ -ddump-to-file \ -ddump-simpl \ -dsuppress-idinfo \ -fforce-recomp \ -v \ +RTS -t 2>&1 | tee log }}} Then grep for `^\$s\$wfoldlM` in the `dump-simpl` output. You should see a number of top-level bindings of the type that I mention in comment:10. In my case they are all exactly of size, {{{ -- RHS size: {terms: 209, types: 244, coercions: 466, joins: 0/7} }}} and the right-hand sides are identical. It seems that the bindings in question are being excluded from CSE by `CSE.noCSE`. I suspect they may be join points, but I'm still trying to work out the particulars. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 13:54:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 13:54:18 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.8d8e8808a1a027279097f393fa7d394c@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) 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) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -27,0 +27,5 @@ + + Edit2: which actually doesn't prove the `--make` leak is a regression. + There may just be some other regression that makes the difference between + interrupted and non-interrupted compilation under 7.10.3 much smaller and + harder to measure. New description: (This is probably not reproducible with a small example.) When I build this project with `cabal build` https://github.com/LambdaHack/LambdaHack/commit/138123ab13edd4db6c8143720af68b6ec4a1726e the peek memory, as observed with `top`, is 10G*. When I instead interrupt the compilation with `^C` at the following point (compilation of this file take a couple of minutes, so it's easy to interrupt): {{{ [123 of 123] Compiling Game.LambdaHack.SampleImplementation.SampleMonadServer ( Game/LambdaHack/SampleImplementation/SampleMonadServer.hs, dist/build/Game/LambdaHack/SampleImplementation/SampleMonadServer.o ) }}} and then restart and continue to the end, peek memory usage in either of the two compilation parts is 5G*. So it seems `ghc --make` keeps some data that is either eventually not used or could as well be read on demand instead of kept in memory. Confirmed with 8.2.1-rc1 as well, but it's not trivial to compile due to restrictive upper bounds of many packages. *exact numerical values are made up Edit: this is a regression, GHC 7.10.3 uses < 3G for compilation without even interrupting Edit2: which actually doesn't prove the `--make` leak is a regression. There may just be some other regression that makes the difference between interrupted and non-interrupted compilation under 7.10.3 much smaller and harder to measure. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 14:39:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 14:39:15 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.744dddb22aa93559ffd12dfb13fc9e83@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I've confirmed that the bindings in question are join points. I don't see any reason why top-level join points can't be CSE'd. I'll try fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 16:20:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 16:20:28 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.a19d6357c25b2fdad71972954157d028@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps Operating System: 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): Here is a simplified version of the example in the ticket: {{{ class Foo a b c | a b -> c instance Foo (x, a) x ((), a) instance Foo (x, a) a (x, ()) }}} These two instances are accepted by GHC 8.0.1, but should be rejected as they violate the FD on the class. Here is the counter example: {{{ Foo (Int,Int) Int ((), Int) Foo (Int,Int) Int (Int, ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 19:27:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 19:27:33 -0000 Subject: [GHC] #11799: Legend for hpc markup colors In-Reply-To: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> References: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> Message-ID: <062.1fef4fb5f489f03a4554865e12740a5c@haskell.org> #11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: SantiM Type: feature request | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by SantiM): * owner: (none) => SantiM * differential: => Phab:D3465 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 20:11:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 20:11:16 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.66c7aa0312953e122dbf0b8239010aa7@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Please excuse the nonsense in comment:13. My `trace` mislead me into believing that the bindings in question were join points when they were not (and now that I look again at this, I don't believe that such top- level join points could even arise). The problem is instead that the `not (isAlwaysActive (idInlineActivation id))` condition in `noCSE` fires for the bindings in question. This appears to be due to the `INLINE[0]` applied to these bindings by worker/wrapper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 20:49:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 20:49:52 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.1ec158c8b08821fb4fc3b93f555356b4@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 nomeata): * cc: nomeata (added) Comment: So basically `memcpy` always, even if the object is very small, and leave the rest to the compiler? But we only run an optimizing compiler with the LLVM backend, don’t we? So this should not be done in the NGC? (Did trac stop auto-subscribing commentors?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 20:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 20:55:49 -0000 Subject: [GHC] #13588: Simplify StgCase when all alternatives are the case binder Message-ID: <046.df182194446ba60997fc863e88b5b56f@haskell.org> #13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Nudged by rwbarton, simponpj writes in ticket:13536#comment:16: Yes. It's really {{{ case e of w { p1 -> w; ...; pn -> w } ===> e }}} (Core has a more general version involving strictness on x.) I don't know how much it happens in practice. It would not be hard to include this in StgCse though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 20:56:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 20:56:26 -0000 Subject: [GHC] #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 In-Reply-To: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> References: <050.1997eda62cafe8e43a096fa3d6c0894e@haskell.org> Message-ID: <065.dd315f8ef050ed4b41d4025ecb3542da@haskell.org> #13536: Program which terminates instantly in GHC 8.0.2 runs for minutes with 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T13536 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I created a new ticket:13588 for rwbarton's idea from comment:15 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:06:11 -0000 Subject: [GHC] #13588: Simplify StgCase when all alternatives are the case binder In-Reply-To: <046.df182194446ba60997fc863e88b5b56f@haskell.org> References: <046.df182194446ba60997fc863e88b5b56f@haskell.org> Message-ID: <061.141e7fbc04adccf5bec5213f6517a46e@haskell.org> #13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"ebb780f1b384b0d2fa2517c1b8093930ea12b6de/ghc" ebb780f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ebb780f1b384b0d2fa2517c1b8093930ea12b6de" Add failing test case for #13588 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:19:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:19:42 -0000 Subject: [GHC] #13589: Possible inconsistency in CSE's treatment of NOINLINE Message-ID: <046.421ab366916136ec445d79115a39afdf@haskell.org> #13589: Possible inconsistency in CSE's treatment of NOINLINE -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 debugging #13535 I noticed the following inconsistency in CSE: `Note [CSE for INLINE and NOINLINE]` states that we need to take care when adding expressions bound to binders with inline pragmas to the `CSEnv`. To see why, consider the following, {{{#!hs {-# NOINLINE bar #-} bar = -- Same rhs as foo foo = }}} Given this program, we need to avoid producing `foo = bar` since doing so would mean that we would lose the ability to inline `foo`'s original RHS. The note then goes on to give the following rule, > We should not add > > {{{ :-> bar}}} > > to the CSEnv if `bar` has any constraints on when it can inline; > that is, if its 'activation' not always active. Otherwise we > might replace `` by `bar`, and then later be unable to see that it > really was ``. This rule is implemented in `noCSE` with, {{{#!hs not (isAlwaysActive (idInlineActivation id)) }}} However, it's quite unclear to me that this rule avoids the issue we set out to solve. Afterall, `NOINLINE bar` is always active, but it still means that rewriting `foo` to `foo=bar` would lose us the ability to see `foo`'s original RHS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:24:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:24:16 -0000 Subject: [GHC] #13588: Simplify StgCase when all alternatives are the case binder In-Reply-To: <046.df182194446ba60997fc863e88b5b56f@haskell.org> References: <046.df182194446ba60997fc863e88b5b56f@haskell.org> Message-ID: <061.f124f3be18a2f026adb1855979923add@haskell.org> #13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3467 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3467 Comment: I gave it a shot: Phab:D3467 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:31:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:31:56 -0000 Subject: [GHC] #13589: Possible inconsistency in CSE's treatment of NOINLINE In-Reply-To: <046.421ab366916136ec445d79115a39afdf@haskell.org> References: <046.421ab366916136ec445d79115a39afdf@haskell.org> Message-ID: <061.fcb9db0fe2d30518ab3045f850f00389@haskell.org> #13589: Possible inconsistency in CSE's treatment of NOINLINE -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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): I think the rule does address the issue. If CSE fires we'll get {{{ bar = rhs foo = bar }}} Before CSE, if `foo` is inlined, then the context into which it inlines will see ``. After CSE, if we inline `foo` we'll see `bar` not `` so we want `bar` to be able to inline too. > Afterall, NOINLINE bar is always active, No: a NOINLINE pragma cause a `NeverActive` activation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:36:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:36:53 -0000 Subject: [GHC] #13589: Possible inconsistency in CSE's treatment of NOINLINE In-Reply-To: <046.421ab366916136ec445d79115a39afdf@haskell.org> References: <046.421ab366916136ec445d79115a39afdf@haskell.org> Message-ID: <061.cc4994af03bc27d2064e42e312924a91@haskell.org> #13589: Possible inconsistency in CSE's treatment of NOINLINE -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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): That said, it is silly that we can't CSE {{{ {-# INLINE [0] f #-} f x = blah {-# INLINE [0] g #-} g x = blah }}} How could we solve this? Something like this: * Have `cs_map :: CoreMap (OutExpr, Activation)` * Add `blah :-> (f, ActiveAfter 0)` when extending the `cs_map` in `cse_bind`. * In `tryForCSE`, when called from `cse_bind`, pass the `Activation` of the binding (`g` in this example), and check that the `Activation` of the new Id is the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:37:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:37:40 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.afc95e8b51d2369355ba2c0bdc6ab484@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm still a bit boggled by how all these identical functions get created in the first place. I have not yet had a chance to gaze at the repro case. Do you understand why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:38:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:38:57 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.0b95e1e02f12c413484d1d89a2408175@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So it turns out that the failure of CSE isn't actually a regression. I can observe the same repeated bindings produced by 8.0.2. Regardless, I think the CSE failure should probably be considered a bug. Afterall, worker/wrapper originally applies this inline pragma to ensure that the wrapper doesn't inline before any possible specialisations have had a chance to do so. If we CSE'd in this case we aren't going to hide any specialisation opportunities as the bindings we are CSE'ing are all identical and should therefore have the same available specialisations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:40:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:40:40 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.a4ae633770f41d658aa8ab6139c21e67@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): simonpj, they the identical functions come into existence by inlining into numerous distinct call-sites of `foldlM` (which has `foldM_loop` let-bound in its unfolding). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:41:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:41:52 -0000 Subject: [GHC] #12001: RFC: Add pattern synonyms to base In-Reply-To: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> References: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> Message-ID: <066.b91e1dd8bfe87e2c78e8aa3d282a37a9@haskell.org> #12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -46,0 +46,3 @@ + import Data.Complex (Complex, conjugate, polar, mkPolar) + import qualified Data.Complex as C + @@ -56,2 +59,2 @@ - pattern Real r <- r :+ _ - where Real r = r :+ 0 + pattern Real r <- r C.:+ _ + where Real r = r C.:+ 0 @@ -60,2 +63,2 @@ - pattern Imaginary i <- _ :+ i - where Imaginary i = 0 :+ i + pattern Imaginary i <- _ C.:+ i + where Imaginary i = 0 C.:+ i @@ -63,0 +66,2 @@ + pattern (:+) :: a -> a -> Complex a + pattern (:+) { realPart, imagPart } = realPart C.:+ imagPart New description: Since we have pattern synonyms it's worth considering if some belong in base: [https://hackage.haskell.org/package/lens-4.14/docs/Data-Complex-Lens.html Data.Complex.Lens] contains patterns that could be defined in base, here are some more suggestions: === Data.Array === {{{#!hs pattern ArrayIx :: Ix i => (i, i) -> [(i, e)] -> Array i e pattern ArrayIx low'high xs <- ((\arr -> (bounds arr, assocs arr)) -> (low'high, xs)) where ArrayIx low'high xs = array low'high xs }}} === Data.Bits === {{{#!hs pattern ZeroBits :: (Eq a, Bits a) => a pattern ZeroBits <- ((== zeroBits) -> True) where ZeroBits = zeroBits pattern BitSize :: Bits a => Int -> a pattern BitSize n <- (bitSizeMaybe -> Just n) pattern Signed :: Bits a => a pattern Signed <- (isSigned -> True) pattern Unsigned :: Bits a => a pattern Unsigned <- (isSigned -> False) pattern PopCount :: Bits a => Int -> a pattern PopCount n <- (popCount -> n) }}} === Data.Char === {{{#!hs pattern ControlChar :: Char pattern ControlChar <- (isControl -> True) pattern SpaceChar :: Char pattern SpaceChar <- (isSpace -> True) }}} === Data.Complex === {{{#!hs import Data.Complex (Complex, conjugate, polar, mkPolar) import qualified Data.Complex as C pattern Conjugate :: Num a => Complex a -> Complex a pattern Conjugate a <- (conjugate -> a) where Conjugate a = conjugate a pattern Polar :: RealFloat a => a -> a -> Complex a pattern Polar m theta <- (polar -> (m, theta)) where Polar m theta = mkPolar m theta -- See https://github.com/ekmett/lens/issues/653 pattern Real :: Num a => a -> Complex a pattern Real r <- r C.:+ _ where Real r = r C.:+ 0 pattern Imaginary :: Num a => a -> Complex a pattern Imaginary i <- _ C.:+ i where Imaginary i = 0 C.:+ i pattern (:+) :: a -> a -> Complex a pattern (:+) { realPart, imagPart } = realPart C.:+ imagPart }}} === GHC.Float === {{{#!hs pattern NegativeZero :: RealFloat a => a pattern NegativeZero <- (isNegativeZero -> True) where NegativeZero = -0 pattern Denormalized :: RealFloat a => a pattern Denormalized <- (isDenormalized -> True) pattern NaN :: RealFloat a => a pattern NaN <- (isNaN -> True) where NaN = 0 / 0 -- How ever negative infinity is handled pattern Infinity :: RealFloat a => a pattern Infinity <- ((== 1 / 0) -> True) where Infinity = 1 / 0 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:42:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:42:18 -0000 Subject: [GHC] #13589: Possible inconsistency in CSE's treatment of NOINLINE In-Reply-To: <046.421ab366916136ec445d79115a39afdf@haskell.org> References: <046.421ab366916136ec445d79115a39afdf@haskell.org> Message-ID: <061.296d9a5a8dc9ad1120bf4a4aac9a0fcc@haskell.org> #13589: Possible inconsistency in CSE's treatment of NOINLINE -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 bgamari): > No: a NOINLINE pragma cause a NeverActive activation. Ahh, there's my misunderstanding. > How could we solve this? Something like this: Sounds reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 21:44:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 21:44:17 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.2ca024756082a5b1df9986259a7649af@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, but all those call sites must be applied to the same combining- function argument (else the loop would be different in each case). So we just have lots of all to `foldlM k z`, for a particular `k` and `z`? Could we CSE those calls before inlining the `foldlM`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 22:05:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 22:05:13 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.3ea64c28d3b700cc87e2d00300ba6b71@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType * priority: normal => highest * cc: goldfire (added) Comment: Thank you pacak! Core Lint fails when compiling `Panic.hs` with {{{ Data alternative when scrutinee is not a tycon application Scrutinee type: (Exchange (Unwrapped (First ())) (Unwrapped (First ())) |> <*->*->*>_N) (Maybe ()) ((Identity |> <*->*>_N) (Maybe ())) Alternative: Exchange sa_a36Y bt_a36Z -> Exchange @ (Unwrapped (First ())) @ (Unwrapped (First ())) @ (First ()) @ (Identity (First ())) (\ (x_a377 :: First ()) -> sa_a36Y (x_a377 `cast` )) ((\ (x_a377 :: Unwrapped (First ())) -> bt_a36Z x_a377) `cast` ) }}} Richard, this is a live example of where `splitTyConApp` (in `CoreLint.lintCoreAlt`) fails on a type that looks like {{{ (Exchange t1 t2 |> Refl) t3 t4 }}} The `Refl` is getting in the way of the `splitTyConApp`. I think we agreed to make it an invariant that no such `Refl` casts will exist in types. How are you getting on with making it so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 22:08:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 22:08:42 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.6ab6921302fc3add5b970a7d1c4e29e6@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Could we CSE those calls before inlining the foldlM? Perhaps, but It seems like what is happening is this, 1. The specialiser creates an `INLINE` specialisation, {{{ $sunstream :: Bundle Vector Int -> New Vector Int }}} which has `foldlM` (and consequently `foldlM_loop`) let-bound within it 2. FloatOut gets run, but since we are in an `InlineCtxt` we don't float the `foldlM_loop`s out to top-level where CSE might be able to consolidate them (incidentally, is `Note [FloatOut inside INLINE]` in `SetLevels` still correct? It doesn't seem to be referenced from anywhere) 3. The specialisation is inlined into dozens of callsites 4. We do lots of expensive, redundant simplification 5. Eventually we do CSE, but even then we don't eliminate the redundant top-level `foldlM_loop`s for the reason discussed in comment:16 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 22:09:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 22:09:45 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.2f355cf7792bd3a61355efb72dff185f@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 nomeata): The comments in http://stackoverflow.com/q/43481900/946226 also suggest that using `memcpy` always might be an option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 22:28:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 22:28:09 -0000 Subject: [GHC] #13569: Optimise code-gen for field-updates of large products In-Reply-To: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> References: <042.8450930e17f8bf1f6a65498d547d6640@haskell.org> Message-ID: <057.9cfe2c2f90f8d40274b021ab412de8e4@haskell.org> #13569: Optimise code-gen for field-updates of large products -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (CodeGen) | 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 bgamari): Even our NCG (at least on X86, I haven't checked the others) will unroll small `memcpy`s, so I think this should always be a sensible thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 22:47:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 22:47:11 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.fdb82c9b8d7be91cb7270aa4b1d3b26d@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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 me note that the commit in comment:5 added this note {{{ Note [Bogus consistency check] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In checkFunDeps we check that a new ClsInst is consistent with all the ClsInsts in the environment. The bogus aspect is discussed in Trac #10675. Currenty it if the two types are *contradicatory*, using (isNothing . tcUnifyTys). But all the papers say we should check if the two types are *equal* thus not (substTys subst rtys1 `eqTypes` substTys subst rtys2) For now I'm leaving the bogus form because that's the way it has been for years. }}} Would someone like to fix the bogus-ness as suggested, and check what, if anything, goes wrong. (See #9210 comment:4 for some possible testsuite failures. Maybe they SHOULD fail.) It'd be worth checking what Hackage libraries build before, but fail to build after. This has been wrong for a long time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 23:02:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 23:02:04 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.2dffa9f10bdde0f5ca1e6e78fb681eff@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > 1024 specialization rules to -ddump-rules for this module. Really? I compiled the module in comment:22 with HEAD and got no rules at all! What am I doing wrong? {{{ Result size of Tidy Core = {terms: 2,582, types: 63,214, coercions: 20,656, joins: 0/34} }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 23:30:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 23:30:24 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.27a41581769ba57c6dea25f7e607c19f@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > (incidentally, is Note [FloatOut inside INLINE] in SetLevels still correct? It doesn't seem to be referenced from anywhere) It actually appears that the logic associated with this note was refactored in, {{{ commit c0fe534fbf3d3e30a6f35b355da86e6f18601348 Author: simonpj at microsoft.com Date: Tue Apr 22 11:50:03 2008 +0000 Fix a long-standing bug in FloatOut }}} and eventually removed in, {{{ commit 72462499b891d5779c19f3bda03f96e24f9554ae Author: simonpj at microsoft.com Date: Thu Oct 29 14:30:51 2009 +0000 The Big INLINE Patch: totally reorganise way that INLINE pragmas work }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 18 23:30:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Apr 2017 23:30:37 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.0bba31257cca5c60d967c27c287739c2@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Simon, compilation without -c succeeds: {{{ % ghc Main.hs -O [1 of 3] Compiling Lens ( Lens.hs, Lens.o ) [2 of 3] Compiling Panic ( Panic.hs, Panic.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 00:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 00:17:54 -0000 Subject: [GHC] #13588: Simplify StgCase when all alternatives are the case binder In-Reply-To: <046.df182194446ba60997fc863e88b5b56f@haskell.org> References: <046.df182194446ba60997fc863e88b5b56f@haskell.org> Message-ID: <061.9e63aa69e15efe27f8efe1b77fb2132f@haskell.org> #13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3467 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Harbormaster is happy with this commit, so I pushed it. I will report any perf findings once they are in (but I do not expect any). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 00:18:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 00:18:10 -0000 Subject: [GHC] #13588: Simplify StgCase when all alternatives are the case binder In-Reply-To: <046.df182194446ba60997fc863e88b5b56f@haskell.org> References: <046.df182194446ba60997fc863e88b5b56f@haskell.org> Message-ID: <061.d10422c276618db283fa39f6ac862b9b@haskell.org> #13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3467 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"21c35bda8e435cfba1998fa8375a52a73fe570f4/ghc" 21c35bda/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21c35bda8e435cfba1998fa8375a52a73fe570f4" Simplify StgCases when all alts refer to the case binder as proposed in #13588. Differential Revision: https://phabricator.haskell.org/D3467 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 01:52:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 01:52:08 -0000 Subject: [GHC] #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is Message-ID: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: libraries | Version: 8.2.1-rc2 (other) | 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 release blocker and I want to file it here so we don't forget. In fact, 2.0 head has already diverged from 8.2.1-rc1, see https://github.com/haskell/cabal/issues/4453 for some fall out (since we now have multiple "2.0" Cabals floating around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 02:07:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 02:07:03 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.b79079cc0f295158f4cf2f11c9cd6860@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm the TH czar these days, but I'm swamped and won't be able to look at this until the end of the semester -- which is only two weeks away, thankfully. But if someone else can take a peek, that would be great! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 02:58:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 02:58:29 -0000 Subject: [GHC] #13588: Simplify StgCase when all alternatives are the case binder In-Reply-To: <046.df182194446ba60997fc863e88b5b56f@haskell.org> References: <046.df182194446ba60997fc863e88b5b56f@haskell.org> Message-ID: <061.5520cdb0c948dcc0a7d1d9e5c5ad6415@haskell.org> #13588: Simplify StgCase when all alternatives are the case binder -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3467 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): As expected, no change, not evan a single byte of binary size change. But even if code out there makes heavy use of both newtypes in polymorphic data structures, I doubt we would find it in the nofib suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 07:27:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 07:27:53 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.88492139a6d5b6b3bce505de910a7265@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:63 goldfire]: Hi Richard, I think we're already (at GHC 7.10/8.0) pretty close to being able to write your `class Terrible`. > > {{{ > class Terrible a b | a -> b > instance Terrible Int Bool > instance Terrible Int Char > }}} See Iavor's example comment:12:ticket:10675. Or this https://mail.haskell.org/pipermail/glasgow-haskell- users/2017-April/026507.html . Both examples rely on `UndecidableInstances` and overlaps. Not necessrily `OverlappingInstances`: in Iavor's example, the FunDeps are non-full. > > {{{ > foo :: Terrible a b => a -> b > foo = undefined > }}} > > and we call `show (foo (5 :: Int))`. GHC has to figure out what type the argument to `show` has so it can supply the right `Show` instance. In this case, the type inferred for `foo (5 :: Int)` will either be `Bool` or `Char`, depending on the whims of GHC at the moment. In those examples I cited, GHC does make a predictable choice (so not entirely on a whim). But it's inconsistent between the FunDeps, so very sensitive to subtle changes in (apparently) unrelated parts of the program/some distant module. For example, merely adding a type signature could trigger selecting a different instance. > ... Much like with `IncoherentInstances`, it's up to the user not to shoot themselves in the foot. > With a great deal of hindsight, what `Undecidable` means in these cases is: * The type specified in the instance head isn't mechanically derivable from the other type parameters. So the programmer is saying "trust me, at any use site, you'll be able to figure out the right type". * GHC can't follow the trail of instance constraints/instantiation -- especially because it might need looking at other modules and/or a very long chain. * So `Undecidable` means GHC can't/won't decide whether any given FunDep is instantiated consistently across all the instances. I'm not sure that's abundantly well explained in the docos. OTOH, there's some type-level programming that deliberately exploits that inconsistency -- such as anything that despatches on a type-level type-equality condition (the whole of the HList library, as originally developed). Closed type families is nowadays a much more hygienic mechanism. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 09:32:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 09:32:12 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.5554da30c40903d89f386426d3244872@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: 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 Wed Apr 19 10:06:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 10:06:26 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.fb6d707718896beb4ccb079dc1ab734e@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:34 danilo2]: Hi Wojciech/all, this ticket seems to have been stalled for some time. Is it still causing anybody pain? Did something get better in a later release? I've tried to wade through the comments, but I'm left very unsure what the proposal is, or what are the use cases. To look at your proposed test code. (https://phabricator.haskell.org/D69 has a smaller example.) Either the code is not actually testing for how D69 is to change behaviour, or there's already a (simpler?) way to achieve it. > ... I will try to put here another one, a little more complex: > {{{#!haskell > {-# LANGUAGE NoMonomorphismRestriction #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE DysfunctionalDependencies #-} > > class Property a b | a -> b where > property :: a -> b > > data X = X > data Y = Y > > instance Monad m => Property X Y where > property _ = Y > > instance Monad m => Property Y (m Int) where > property _ = return 5 > > main = do > let f = property $ property X > }}} Your O.P. included a Monad as one of the params to the class, and it was determined from the first param. Here the Monad seems to materialise out of thin air. In your first `instance` it's not even used. In the second instance it seems that could be any Monad at all(?) If your class is usually non-monadic, but you happen to use method `property` inside monadic code, you could just wrap the call in `return`. If your class is usually monadic, but you happen to need `property` in a non-monadic context, you could wrap it in the the `Identity` monad and extract the result(?) See my comment:70 above/examples. With `UndecidableInstances` there seems to be plenty of ways to evade the Consistency Condition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 11:05:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 11:05:02 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.d06d56434a69b4b24e5c31c69fe1fca1@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps Operating System: 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): Replying to [comment:7 diatchki]: > Here is a simplified version of the example in the ticket: Thanks Iavor, are you sure this is the ticket you meant? This one is about the order of declaration of instances affecting type inference, and the problem seems to have cleared up, according to comment:5. > {{{ > class Foo a b c | a b -> c > > instance Foo (x, a) x ((), a) > instance Foo (x, a) a (x, ()) > }}} > > These two instances are accepted by GHC 8.0.1, ... You mean the instance decls compile? They partially overlap, so GHC will delay any error reporting until a use site. > ... but should be rejected as they violate the FD on the class. They're inconsistent only for the cases of overlap per your counter- example below, not in general. That is, not when `x` is different to `a`. > Here is the counter example: > {{{ > Foo (Int,Int) Int ((), Int) > Foo (Int,Int) Int (Int, ()) > }}} > I get attempts at those usages roundly rejected by GHC. (It suggested I `AllowAmbiguousTypes`, but that didn't help. I also switched on `UndecidableInstances` to give it maximum help.) {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, FlexibleContexts, AllowAmbiguousTypes, UndecidableInstances #-} class Foo a b c | a b -> c where { foo :: a -> b -> c } instance Foo (x, a) x ((), a) where foo (x, a) x2 = ((), a) instance Foo (x, a) a (x, ()) where foo (x, a) a2 = (x, ()) f1 = foo (True, 'c') False f2 = foo (True, 'd') 'e' f3 = foo (5 :: Int, 7 :: Int) (9 :: Int) main = print $ "results" ++ show f1 ++ show f2 ++ show f3 prog.hs:12:6: error: • Couldn't match type ‘Int’ with ‘()’ arising from a functional dependency between: constraint ‘Foo (Int, Int) Int (Int, ())’ arising from a use of ‘foo’ instance ‘Foo (x, a) x ((), a)’ at prog.hs:7:10-29 • In the expression: foo (5 :: Int, 7 :: Int) (9 :: Int) In an equation for ‘f3’: f3 = foo (5 :: Int, 7 :: Int) (9 :: Int) }}} (Per the O.P., if I switch round the order of those instance declarations, I do get a different error message, essentially just a mirror image.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 11:34:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 11:34:43 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.293ef77999554979c6e7bb9312e59aea@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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): Replying to [comment:15 simonpj]: Thanks Simon. I fear we're in danger of getting two separate issues confused. (I guess that comes with the territory.) On the narrow issue raised in the O.P.: * __If__ both instance decls are to be accepted, nevertheless, at sites where the first `C Bool` instance applies, `op True` should accept any `[alpha]` and return exactly type `[alpha]`. * Note that the `C Bool` instance meets the coverage conditions/doesn't need `UndecidableInstances`. * I'm saying: once the instance is selected, GHC should treat that use site as if that's the only instance. * So where your O.P. says "As a result [of accepting both instance decls], it'll use ''both'' instances for improvement.", I think that's just plain wrong. I don't see anything in the FDs-via-CHRs paper '''Definition 6''' (or in Mark Jones 2000 paper) to suggest attempting mutual improvement. The '''Consitency Condition''' is purely about validating instances. The bulk of your comment is on the different issue of whether those instances should be accepted together. I'll reply separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 12:24:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 12:24:36 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.c9cbaf32dbe73235461af255c2754986@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: 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): Replying to [comment:15 simonpj]: On the broader issue of should those instances be accepted together > Let me note that the commit in comment:5 added this note > {{{ > ... Currenty [checking] if the two types are *contradicatory*, > using (isNothing . tcUnifyTys). But all the papers say > we should check if the two types are *equal* thus ... > }}} Thank you. So that confirms my suspicion in comment:11, bullet 3. > {{{ > For now I'm leaving the bogus form because that's the way it has > been for years. > }}} Yes I think that's wise, given how many fragile programs are out there using FunDeps and overlaps. > Would someone like to fix the bogus-ness as suggested, and check what, if anything, goes wrong. I'm keen to help, but lack the resources or expertise. > It'd be worth checking what Hackage libraries build before, but fail to build after. I would guess that any library using type-level programming switches on `UndecidableInstances` by default, whether or not it actually needs it. > (... Maybe they SHOULD fail.) This has been wrong for a long time. Given the howls every time GHC tries to apply the FunDep rules more strictly; and given how long a time it's been wrong; I wonder if there's a softly-softly strategy? * Move from module-wide `UndecidableInstances` to a per-instance {-# UNDECIDABLE #-} pragma. (Same idea as with {-# OVERLAP* #-}.) * The '''Coverage Condition''' is defined in terms of checks on each instance alone, so it's just more closely targetting the logic. * Being in the instance gives a more in-your-face signal that this instance is suspicious -- essentially the programmer is acknowledging GHC can't necessarily enforce the '''Consistency Condition'''. * And I suspect a large proportion of instances do obey the '''Coverage Conditions'''. Could we go further to a per-parameter-per-instance flag? * The idiom I see is there's a bare type var in the instance decl, for the target of the FunDep. It doesn't appear elsewhere in the head, so it's breaking the '''Coverage Condition'''. But there's an equality constraint on it, where the improved type __would__ meet the '''Coverge Condition'''. Like: {{{ instance (b ~ False) => TTypeEq a a' b -- breaks Coverage, compare: instance TTypeEq a a' False -- Coverage OK }}} * The reason for the bare type var is to ensure this instance is {-# OVERLAPPABLE #-}; and a more specific instance will override it. With `{-# LANGUAGE IrrefutableInstanceParams #-}` (or some equally ugly name), you can go: {{{ instance TTypeEq a a' ~False -- tilde prefix ? maybe too subtle }}} This: 1. Is syntactic sugar for the form with Equality constraint, for a fresh- generated type var. 2. Means the compiler can validate the '''Coverage Condition''', so this doesn't need {-# UNDECIDABLE #-} 3. Lets the dog see the rabbit: the compiler can check the '''Consistency Condition'''. [To bikeshed about syntax, it's pleasing `~` is already the prefix for irrefutable pattern matches, and the operator for type Equality constraints. It appearing within the instance head is currently illegal syntax; but I guess with a very badly formed head, it might be confused with a type operator(?)] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 13:16:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 13:16:10 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot Message-ID: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Keywords: ghci hs-boot | 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 runs into an exception if there is an error in Foo.hs when there exists a Foo.hs-boot (which compiles fine). - First.hs-boot {{{ module First where one :: Int }}} - Second.hs {{{ module Second where import {-# SOURCE #-} First two :: Int two = one + 1 }}} - First.hs {{{ module First where import Second one :: Int one = _ }}} {{{ > ghci Prelude> :l First [1 of 3] Compiling First[boot] ( First.hs-boot, interpreted ) [2 of 3] Compiling Second ( Second.hs, interpreted ) [3 of 3] Compiling First ( First.hs, interpreted ) First.hs:6:7: error: • Found hole: _ :: Int • In the expression: _ In an equation for ‘one’: one = _ • Relevant bindings include one :: Int (bound at First.hs:6:1) *** Exception: expectJust showModule CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:48:27 in ghc:Maybes }}} This happens on ghc-8.0.1, 8.0.2 and 8.2.1-rc1. The above output is from 8.0.2, but the error seems to be essentially the same on 8.2.1-rc1. It did not happen on 7.10.3. While ghci continues to work, the exception appears to clear the loaded- modules list, which in turn breaks tooling (ghcid here, which hangs as a consequence). The expected behaviour would be that other modules (which contain no errors) remain loaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 13:25:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 13:25:18 -0000 Subject: [GHC] #13592: Newtype type class with compiler generated instances Message-ID: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> #13592: Newtype type class with compiler generated instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- Define a `Newtype` class, autmatically generating instances {{{#!hs class Newtype n where type O n :: Type pack :: O n -> n unpack :: n -> O n }}} as defined in Conal's [http://conal.net/papers/generic-parallel-functional /generic-parallel-functional.pdf Generic parallel functional programming] but also found in the [https://hackage.haskell.org/package/newtype-0.2 newtype] and [https://hackage.haskell.org/package/lens-4.15.1/docs /Control-Lens-Wrapped.html lens] packages. I run into this class every once in a while -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:21:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:21:46 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. In-Reply-To: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> References: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> Message-ID: <071.07c35af45b244bd3e44edc80855b5673@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes Operating System: 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): > No. It is better because it gives you a clue of how to fix it: Add an instance of First Int b Int. Alas, all that will happen then is that the missing `Typeable b` constraint will be reported. There really are two missing constraints, but GHC tries to avoid saturating the user by reporting only one per birth site. Reporting the entire path to a constraint is quite painful/voluminous, but I can see the point. Good ideas in here for better error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:27:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:27:10 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.7cdf8b1f3621192906595e76088f515f@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies 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: TypeFamilies, Injective => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:27:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:27:25 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.9e1e20466f2054dad06174fc988171c5@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | CustomTypeErrors, TypeFamilies, | InjectiveFamilies 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: CustomTypeErrors, TypeFamilies, Injective => CustomTypeErrors, TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:27:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:27:44 -0000 Subject: [GHC] #12199: GHC is oblivious to injectivity when solving an equality constraint In-Reply-To: <050.8b18860f28fadb7400553ef29ec1b26c@haskell.org> References: <050.8b18860f28fadb7400553ef29ec1b26c@haskell.org> Message-ID: <065.36461a81c8d23a46e1bf09c3103ac0f6@haskell.org> #12199: GHC is oblivious to injectivity when solving an equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10833 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies, Injective => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:27:54 -0000 Subject: [GHC] #13571: Injective type family syntax accepted without TypeFamilyDependencies In-Reply-To: <048.555a912faf2a1ac128c4b78fd974a910@haskell.org> References: <048.555a912faf2a1ac128c4b78fd974a910@haskell.org> Message-ID: <063.adc7201a5d2f4be7698e0c37e91338cd@haskell.org> #13571: Injective type family syntax accepted without TypeFamilyDependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies 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: TypeFamilies, Injective => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:28:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:28:15 -0000 Subject: [GHC] #10227: Type checker cannot deduce type In-Reply-To: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> References: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> Message-ID: <062.4e595caf93c065424183189ea635f222@haskell.org> #10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | InjectiveFamilies 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: => InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:28:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:28:27 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.a6e1cac46277780bce008bede7f9a0c4@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:28:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:28:45 -0000 Subject: [GHC] #4259: Relax restrictions on type family instance overlap In-Reply-To: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> References: <044.e5eb645c3ea4a197b93ff685f55f7550@haskell.org> Message-ID: <059.742b54b593e98b4806e54d02a5371973@haskell.org> #4259: Relax restrictions on type family instance overlap -------------------------------------+------------------------------------- Reporter: lilac | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 6.12.1 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8423 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:29:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:29:31 -0000 Subject: [GHC] #10833: Use injective type families (decomposition) when dealing with givens In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.2f535244c5283ac3cc5822e820d8d78d@haskell.org> #10833: Use injective type families (decomposition) when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018, #11511, | Differential Rev(s): #12199 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:30:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:30:19 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.59f51ca01818ccc77d0759c3fcec0da0@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, | InjectiveFamilies 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeFamilies, Injective => TypeFamilies, InjectiveFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:33:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:33:05 -0000 Subject: [GHC] #13592: Newtype type class with compiler generated instances In-Reply-To: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> References: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> Message-ID: <066.50ea704b232df217bafa99b41cf53fa7@haskell.org> #13592: Newtype type class with compiler generated instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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 RyanGlScott): I'm leery about adding more magic classes to GHC, but fortunately, this magic already exists as `Data.Coerce.Coercible`: {{{#!hs import Data.Coerce pack :: Coercible on n => on -> n pack = coerce unpack :: Coercible n on => n -> on unpack = coerce newtype Example = Example String deriving Show main :: IO () main = do print (pack "hello" :: Example) print (unpack (Example "world") :: String) }}} Does this suit your needs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:33:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:33:18 -0000 Subject: [GHC] #13582: Confusing error message with multiparameter type classes. In-Reply-To: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> References: <056.87efd9b5c11b970afb6c4d37d138bcc4@haskell.org> Message-ID: <071.d73b5269be1c4a46f28dc597bdca2028@haskell.org> #13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes, | TypeErrorMessages 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: type-checking errors multiparameter type classes => type- checking errors multiparameter type classes, TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:33:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:33:52 -0000 Subject: [GHC] #10450: Poor type error message when an argument is insufficently polymorphic In-Reply-To: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> References: <049.441b7888d2051456b0bc3468f4c53dc6@haskell.org> Message-ID: <064.24d1d52875053bff8e714045aaba799e@haskell.org> #10450: Poor type error message when an argument is insufficently polymorphic -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: RankNTypes, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: RankNTypes => RankNTypes, TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:34:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:34:18 -0000 Subject: [GHC] #9605: Misleading error message with forgotten "do" In-Reply-To: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> References: <043.4d0a36fa55a61f7a0e16739341de4daf@haskell.org> Message-ID: <058.f89b40bb928fa5e98c42d5894a8c83e7@haskell.org> #9605: Misleading error message with forgotten "do" -------------------------------------+------------------------------------- Reporter: owst | Owner: Yuras Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7869 | Differential Rev(s): Phab:D556 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:34:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:34:29 -0000 Subject: [GHC] #9456: Weird behavior with polymorphic function involving existential quantification and GADTs In-Reply-To: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> References: <044.fb24ca221fd2910705f4b79d0805518a@haskell.org> Message-ID: <059.8740e699792fca057e68ea6d66be2171@haskell.org> #9456: Weird behavior with polymorphic function involving existential quantification and GADTs -------------------------------------+------------------------------------- Reporter: haasn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: GADTs, Resolution: | TypeErrorMessages 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 simonpj): * keywords: GADTs => GADTs, TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:34:37 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.6d518ed286e749e1431b976367540c45@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539, #12716 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:34:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:34:48 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.d185c23072888cb80a1fdf3b14522cfd@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: | TypeErrorMessages 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 simonpj): * keywords: => TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:34:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:34:56 -0000 Subject: [GHC] #1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD In-Reply-To: <044.214a91fada19b9f526f1cce3318d683b@haskell.org> References: <044.214a91fada19b9f526f1cce3318d683b@haskell.org> Message-ID: <059.cb66bcaecb62e5eca559f06c7744ebf2@haskell.org> #1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.7 checker) | Keywords: Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Church2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeErrorMessages * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:35:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:35:02 -0000 Subject: [GHC] #1928: Confusing type error message In-Reply-To: <044.f9461ffda18a680ac6c0c9255dfab544@haskell.org> References: <044.f9461ffda18a680ac6c0c9255dfab544@haskell.org> Message-ID: <059.c86004bd870033e9e1cf38828e5db2e8@haskell.org> #1928: Confusing type error message -------------------------------------+------------------------------------- Reporter: josef | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler (Type | Version: 6.8.1 checker) | Keywords: Resolution: | TypeErrorMessages 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: => TypeErrorMessages * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:35:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:35:06 -0000 Subject: [GHC] #2648: Report out of date interface files robustly In-Reply-To: <046.fcbe859a05356d3f8331ef4b72030e02@haskell.org> References: <046.fcbe859a05356d3f8331ef4b72030e02@haskell.org> Message-ID: <061.4cfb9133f38bc8b877872d74c4050972@haskell.org> #2648: Report out of date interface files robustly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.6.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): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:35:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:35:12 -0000 Subject: [GHC] #2648: Report out of date interface files robustly In-Reply-To: <046.fcbe859a05356d3f8331ef4b72030e02@haskell.org> References: <046.fcbe859a05356d3f8331ef4b72030e02@haskell.org> Message-ID: <061.52b0a88ace439432326e188b76918efd@haskell.org> #2648: Report out of date interface files robustly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 14:46:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 14:46:03 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.2c7713cb8d910f9d9396ea79c72f87fb@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => goldfire * priority: high => highest Comment: Bumping the priority of this; I don't think we'll want to cut an 8.2-rc2 until this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:04:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:04:55 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.c7fdc76aad2737a5414f0f141379ef06@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So it turns out that the failure of CSE isn't actually a regression. I can observe the same repeated bindings produced by 8.0.2. But nevertheless, regardless of CSE, things got worse between 8.0 and 8.2 and we do not yet know why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:17:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:17:39 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.ab54e556f496a6f183e1abdf3178c3f5@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): ToDo: 1. Vector library author: do we really need to INLINE `unstream` and friends, or would INLINABLE do? 2. Why is 8.2 worse than 8.0? 3. Maybe we could do a better job of CSE as discussed in #13589. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:29:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:29:53 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.d4288aba0653ce80f3b6ee312a3635a2@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Simon says, "undersaturated hasNoBinding things need to behave as though there was a lambda". See Note [Levity polymorphism checking] in DsMonad -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:33:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:33:34 -0000 Subject: [GHC] #13500: GHCi preprocesses every source file on :reload In-Reply-To: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> References: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> Message-ID: <062.0af61fa89a3803ac78009a23c36f02a9@haskell.org> #13500: GHCi preprocesses every source file on :reload -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3398 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:35:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:35:49 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.daaae384c48d68223c70129739a9a249@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:37:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:37:11 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.d9d97497b1409e1970f1a3ce8b4175bf@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:42 simonpj]: > > 1024 specialization rules to -ddump-rules for this module. > > Really? I compiled the module in comment:22 with HEAD and got no rules at all! What am I doing wrong? > > {{{ > Result size of Tidy Core > = {terms: 2,582, types: 63,214, coercions: 20,656, joins: 0/34} > }}} > Simon Yes, it seems that a subsequent change removed those, so maybe that's not relevant anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:37:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:37:12 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.d6590d669cffe4e001e36cf3850999e4@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:40:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:40:27 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.46b8aa85ffe5e0191b23501cf22148f6@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bgamari): One approach to fix for the threaded runtime this would be to use `threadWaitRead` in conjunction with `System.timeout`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 15:41:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 15:41:12 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.72bb5415a4cf8db2a7d6711d3ba88811@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so is there now a regression wrt 7.8 or not? If not let's close. If so, let's investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 16:25:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 16:25:57 -0000 Subject: [GHC] #13592: Newtype type class with compiler generated instances In-Reply-To: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> References: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> Message-ID: <066.47476f7e6d644471eee1d85030997c8a@haskell.org> #13592: Newtype type class with compiler generated instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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): The thing missing from that is the dependency, if I use [https://hackage.haskell.org/package/newtype-0.2/docs/Control- Newtype.html#v:ala ala] I can use {{{#!hs ala Sum foldMap [1,2] :: Num o => o }}} While with your formulation I get {{{#!hs ala Sum foldMap [1,2] :: (Coercible o o', Num o) => o }}} but it could certainly re-use `Coercible` {{{#!hs class Newtype n where type O n pack :: O n -> n pack = coerce default pack :: Coercible (O n) n => O n -> n unpack :: n -> O n unpack = coerce default unpack :: Coercible n (O n) => n -> O n }}} so that the compiler only needs to generate {{{#!hs instance Newtype (Sum a) where type O (Sum a) = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 16:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 16:33:22 -0000 Subject: [GHC] #13592: Newtype type class with compiler generated instances In-Reply-To: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> References: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> Message-ID: <066.3682c52fbc3ef3c5e27287da1551bbb6@haskell.org> #13592: Newtype type class with compiler generated instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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): In a way it's a subset of `Coercible` but I don't know if there is any way to specify that more forcefully than ''default signatures''.. a `Coercible` superclass '''might''' work if we use fundeps {{{#!hs class (Coercible on n, Coercible n on) => Newtype n on | n -> on where }}} or {{{#!hs class (Coercible (O n) n, Coercible n (O n)) => Newtype n where type O n pack :: O n -> n pack = coerce unpack :: n -> O n unpack = coerce }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 16:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 16:37:02 -0000 Subject: [GHC] #13592: Newtype type class with compiler generated instances In-Reply-To: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> References: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> Message-ID: <066.6c2f1faaaae2a2d57ee168a242e9364a@haskell.org> #13592: Newtype type class with compiler generated instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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): '''Even''' if we remove `type O` from the class the compiler only needs to generate the `type instance`s for `O` {{{#!hs type family O n class (Coercible (O n) n, Coercible n (O n)) => Newtype n where pack :: O n -> n pack = coerce unpack :: n -> O n unpack = coerce instance (Coercible (O n) n, Coercible n (O n)) => Newtype n }}} if you want to make `Sum` into a newtype, all the compiler has to do is generate {{{#!hs type instance O (Sum a) = a }}} pretty nifty! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 19:39:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 19:39:36 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.1b7c1c9397afe49e2d2a6dc1cf407d54@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge Comment: I'd say this is worth merging to 8.2, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 20:10:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 20:10:15 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.d38a7fa67a39a212214a5cf34a86834f@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps Operating System: 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): I mean that the example I gave should be rejected, but the program is accepted. The check for FD consistency is done when multiple instances come together, not when you use them. This is necessary, because it ensures that the FD invariant on the class holds, and then we can use the invariant in whatever context we want. For the same reason, you can't have instances be consistent only in some cases. Currently GHC is very conservative in its use of FDs---it uses them only for type inference. This is why having inconsistent instances like the example I showed is not the end of the world: it may result in odd behavior where GHC sometimes infers the one type and sometimes the other, but the final result is still a sound Haskell program. For example, if GHC encountered a constraint `Foo (Int,Int) Int a`, where `a` is a unification variable, it might instantiate `a` as either `((),Int)` or `(Int,())` depending on in what order it happened to consult the instances. This is essentially the problem that was reported in the ticket. However, if GHC was to start using the FDs fully as they were intended, having inconsistent instances would lead to unsound type-checking. For example, in this case, GHC should be able to prove that `((),Int) ~ (Int,())`, which is obviously bogus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 20:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 20:27:54 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy Message-ID: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- I was hoping that {{{#!hs let notBoth1 a b = not (a == 1 && b == 1) in groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1] }}} would give me {{{ [[1],[1,2,3,1],[1,4,5,6,1]] }}} but instead I get {{{ [[1],[1,2,3],[1],[1,4,5,6],[1]] }}} It seems that groupBy assumes transitivity in the argument function. I have a new implementation that does not make this assumption. Of course, the implications of changing this function's behavior are troubling. {{{#!hs groupBy' :: (a -> a -> Bool) -> [a] -> [[a]] groupBy' p (x : xs) = go [x] xs where go (x : xs) (y : zs) | p x y = go (y : x : xs) zs go g (y : zs) = reverse g : go [y] zs go g [] = [reverse g] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 20:45:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 20:45:31 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.13563be7f81836c1e04b865d151bb234@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch 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: | Differential Rev(s): Phab:D3472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3472 Comment: I took a shot at option (1) (documenting the current behavior as correct) in Phab:D3472. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 20:59:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 20:59:42 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.d98b7ad78df972190140b241d653db33@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 dsf): Also needs a clause {{{groupBy' _ [] = []}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 21:22:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 21:22:53 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.ffa177180771085b562887df8a0a32ab@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: merge 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 bgamari): I suppose; I've been trying to be a bit more strict about merging to stable, but given that this is a new feature we should probably make it work correctly out of the box. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 22:13:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 22:13:54 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.05660f2f142645b32f32a4dce92f4ecc@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 dsf): To be fair, the documentation says "supply your own equality function", and what I'm supplying above is not an equality function. But a better interface might be something like {{{#!hs groupOn :: Eq b => (a -> b) -> [a] -> [[a]] groupOn f xs = groupBy ((==) `on` f) xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 23:04:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 23:04:17 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.9dbe857e33d9f38e720445a5b7b417bb@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 bgamari): The behavior of `groupBy` is defined by the [[https://www.haskell.org/onlinereport/list.html|Haskell Report]]. We really can't unilaterally change it in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 19 23:55:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Apr 2017 23:55:13 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.b510fe31bf26f8613b97acefbcc56dd9@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bgamari): For the record, this was originally broken by f46369b8a1bf90a3bdc30f2b566c3a7e03672518. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 00:09:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 00:09:07 -0000 Subject: [GHC] #13458: Panic with unsafeCoerce and -dcore-lint In-Reply-To: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> References: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> Message-ID: <060.a3004b1f76e6c5719116f0d96e660861@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13458 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The lint check from comment:12 was fixed and reenabled in f3af0463c81002a64a3b3e9a01351e64460c490f. `T13458` now passes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 00:47:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 00:47:14 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.13e61b5c2802704045ae0a305feda1ab@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 dsf): Of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 00:48:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 00:48:29 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.63d327bcf07fc36306f443ac2deca4d5@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: wontfix | 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 dsf): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 02:03:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 02:03:42 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.253236d577e161df8328c3c45a31826f@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: wontfix | 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 Iceland_jack): Hold on, it's at least worth documenting this infelicity. Ideally the user would be directed to a correct version -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 02:06:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 02:06:43 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 Message-ID: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Try running this code in GHCi: {{{ λ> :set -XBangPatterns -XRankNTypes -XTypeFamilies λ> let x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b); !x = (1, 2) }}} In GHC 8.0.1 and 8.0.2, this works. But in GHC 8.2.1: {{{ :3:74: Couldn't match expected type ‘forall a. (a ~ Integer) => forall b. (b ~ Integer) => (a, b)’ with actual type ‘(Integer, Integer)’ In the expression: (1, 2) In a pattern binding: !x = (1, 2) }}} If you put this code into a source file: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) !x = (1, 2) }}} Then it also works in GHC 8.0.1. and 8.0.2, but it errors on GHC 8.2 (this time with a different error): {{{ GHCi, version 8.2.0.20170413: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:1: error: Overloaded signature conflicts with monomorphism restriction x :: forall a. a ~ Integer => forall b. b ~ Integer => (a, b) | 6 | x :: forall a . a ~ Integer => forall b. b ~ Integer => (a, b) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 02:44:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 02:44:52 -0000 Subject: =?utf-8?b?W0dIQ10gIzEzNTk1OiBTaG91bGQg4oCYY29lcmNl4oCZIGJlIGxl?= =?utf-8?q?vity_polymorphic=3F?= Message-ID: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #13592 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not able to write `coerce @Int# @Int#` or `coerce :: Double# -> Double#`, just checking to see if its intentional or not {{{ >>> :set -XTypeApplications >>> :set -XMagicHash >>> import Data.Coerce >>> import GHC.Exts >>>> :t coerce @Int coerce @Int :: Coercible b Int => Int -> b >>> :t coerce @Int# :1:1: error: Couldn't match a lifted type with an unlifted type When matching types b :: * Int# :: TYPE 'IntRep :1:9: error: • Expecting a lifted type, but ‘Int#’ is unlifted • In the type ‘Int#’ In the expression: coerce @Int# }}} This was needed for #13592. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:27:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:27:12 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.1f5c9f4beeec82a87d007b810079548a@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Phab:D3473 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3473 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:32:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:32:34 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.7a37e41fe5cdc630ae9c54f77d7735d2@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I've just confirmed this in git HEAD (21c35bda8e). Even pulling `sin'` and `cos'` out to the top level and giving them explicit type signatures doesn't help. {{{ • GHC internal error: ‘cos_a4gy’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r34Z :-> Identifier[sin'::Double -> Double, TopLevelLet], r372 :-> Identifier[cos'::Double -> Double, TopLevelLet], r373 :-> Identifier[main::IO (), TopLevelLet]] • In the expression: cos_a4gy In the result of the splice: $importDoubleToDouble "cos" To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(importDoubleToDouble "cos") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:37:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:37:06 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.ee62198325c8207c11eba71080c0792d@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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 dsf): * status: closed => new * failure: Incorrect result at runtime => Documentation bug * resolution: wontfix => * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:37:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:37:51 -0000 Subject: [GHC] #13596: Try disabling inlining of DynFlags combinators Message-ID: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> #13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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: -------------------------------------+------------------------------------- `DynFlags` requires a surprisingly amount of effort to compile. One thing I've been meaning to try is disabling inlining of `make_ord_flag` and such to characterize how much of an impact these inlinings have on simplification effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:37:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:37:59 -0000 Subject: [GHC] #13596: Try disabling inlining of DynFlags combinators In-Reply-To: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> References: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> Message-ID: <061.7b903726eb31cb154ce1456b884b7e7b@haskell.org> #13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- 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: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:40:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:40:24 -0000 Subject: [GHC] #13501: TH segmentation fault on Linux when calling function from another package In-Reply-To: <044.d86696700d9151a875e7fe29f91a002c@haskell.org> References: <044.d86696700d9151a875e7fe29f91a002c@haskell.org> Message-ID: <059.56bd64ddad199b616ae3c85f32fb4061@haskell.org> #13501: TH segmentation fault on Linux when calling function from another package -------------------------------------+------------------------------------- Reporter: jmaki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | DynamicLinking Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DynamicLinking Comment: Well, that essentially confirms that the issue is related to dynamic linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:44:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:44:28 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.3f76660cd8b36fa9ab01352b046b2b2d@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by dsf): I would add: It is assumed that the argument function is transitive. A function like `not (a == 1 && b == 1)` will give a result you might not expect: {{{#!hs > let notBoth1 a b = not (a == 1 && b == 1) > groupBy notBoth1 [1,1,2,3,1,1,4,5,6,1] [[1],[1,2,3],[1],[1,4,5,6],[1]] }}} rather than {{{#!hs [[1],[1,2,3,1],[1,4,5,6,1]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 03:45:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 03:45:41 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.0acf24e81255b3f7ed2956b91896a2e6@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: merge 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 bgamari): comment:7 addresses comment:6. With this patch and 065be6e9eb5114c5f0e3a20626ec93042ce47f13 the test in comment:1 runs to completion without a stack overflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 04:08:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 04:08:39 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.340f60f917003041ba7c77d7f43af09e@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): The `-ddump-splices` output is: {{{ main.hs:11:11-36: Splicing expression importDoubleToDouble "cos" ======> cos_a4gy main.hs:1:1: Splicing top-level declarations added with addTopDecls ======> foreign import ccall unsafe "cos" Main.cos :: Double -> Double }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 04:30:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 04:30:39 -0000 Subject: [GHC] #13578: Incorrect Record Pattern Synonym example in users guide In-Reply-To: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> References: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> Message-ID: <066.6b13f7eeb41ae991485e26b0ff55fe2e@haskell.org> #13578: Incorrect Record Pattern Synonym example in users guide -------------------------------------+------------------------------------- Reporter: cjholdbrooks | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.2.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.2.1 Comment: Thanks for pointing this out! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 04:32:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 04:32:56 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) In-Reply-To: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> References: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> Message-ID: <064.d2244e1d4eee9f32227c815fcbc322a0@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------+------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by bgamari): * priority: normal => high * cc: angerman (added) * architecture: Unknown/Multiple => aarch64 * milestone: => 8.4.1 @@ -12,1 +12,1 @@ - {{{ + {{{#!make @@ -39,1 +39,1 @@ - {{{ + {{{#!hs New description: I compiled GHC from source (ff84d052850b637b0) with a few modifications to create a cross-compiler for arm64. This was the configuration: {{{ CC=aarch64-apple-darwin14-clang ./configure --prefix=/usr/local/ghc-ios --target=aarch64-apple-darwin14 --disable-large-address-space --enable- bootstrap-with-devel-snapshot }}} Here's my "mk/build.mk": {{{#!make HADDOCK_DOCS=NO WITH_TERMINFO=NO DYNAMIC_BY_DEFAULT=NO DYNAMIC_GHC_PROGRAMS=NO DYNAMIC_TOO=NO }}} I used the stage1 compiler to export an arm64 library. The application (which links the library) crashes when run on my device (iOS 10.2.1). The application runs without issue on x86 and arm32. When I initialize with -DS, I get the following error: {{{ internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 88 (GHC version 8.3.20170408 for aarch64_apple_ios) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug // SIGABRT at line 182 in RtsMessages.c }}} To narrow down the offending code, I replaced all my functions with print statements and slowly added the functionality back until I could reproduce the crash. It looks like the crash happens around a call to this function: {{{#!hs foreign export ccall hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm :: StablePtr AA.PublicKey -> IO CString hs_AAPublicKeyAlgorithm = hs_toAlgorithmIdentifier hs_toAlgorithmIdentifier :: (ToAlgorithm t a, AlgorithmId a) => StablePtr t -> IO CString hs_toAlgorithmIdentifier ptr = do algId <- fmap (toAlgorithmId . toAlgorithm) $ deRefStablePtr ptr newCString algId }}} Oddly, when I add print statements around this call, I get a EXC_BREAKPOINT instead of a SIGABRT. Here's the output for this case: {{{ ****************TEST************ ****************TEST************ ****************TEST************ ****************TEST************ v1K_FZuskg6Bkm-whFvkQ8IzHxnXDSGibCwbqZpM0fk= here ****************TEST************ here1 here2 }}} I've disabled dead code stripping. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 04:38:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 04:38:18 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.7aa62b666410e880e6fa58e81318eb2c@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): The `-ddump-rn` output is: {{{ ==================== Renamer ==================== Main.sin' :: Double -> Double Main.sin' = $$(importDoubleToDouble "sin") Main.cos' :: Double -> Double Main.cos' = $$(importDoubleToDouble "cos") Main.main :: IO () Main.main = do print (Main.sin' 0) print (Main.cos' pi) ==================== Renamer ==================== ==================== Renamer ==================== foreign import ccall unsafe "cos" Main.cos :: Double -> Double }}} Not sure where to go with this now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 04:41:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 04:41:48 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) In-Reply-To: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> References: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> Message-ID: <064.53d766c8a05d7d75ae45c56f237de9be@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------+------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Comment (by angerman): Does this happen when applying https://phabricator.haskell.org/D3290 prior to building the cross compiler, as well? {{{ 82 static void 83 checkClosureShallow( const StgClosure* p ) 84 { 85 const StgClosure *q; 86 87 q = UNTAG_CONST_CLOSURE(p); 88 ASSERT(LOOKS_LIKE_CLOSURE_PTR(q)); 89 } 90 }}} The crash indicates that q doesn't look like a closure. One of the cases where this happens is `-dead_strip`. However as noted in the ticket, dead_strip is disabled. This is basically a shot in the dark, e.g. if the addition of dead_strip prevention markers retains the symbol. could you try to see if `nm` lists different symbols for the crashing and the not crashing binary? `nm -j` should list the symbols without the address. `sort` should straighten them and `diff` could potentially be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 04:55:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 04:55:11 -0000 Subject: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# In-Reply-To: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> References: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> Message-ID: <060.d72038788edca4fe19c8efd2adf1dc32@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.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:D3358 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: This was implemented in: {{{ commit aa206346e6f12c9f88fdf051185741761ea88fbb Author: Erik de Castro Lopo Date: Wed Apr 12 14:09:49 2017 -0400 base: Implement bit casts between word and float types Test Plan: Test on x86 and x86_64 Reviewers: duncan, trofi, simonmar, tibbe, hvr, austin, rwbarton, bgamari Reviewed By: duncan Subscribers: Phyx, DemiMarie, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3358 }}} Unfortunately too late for the ghc-8.2 release, but it will make the ghc-8.4 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 06:23:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 06:23:38 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.752108da633ebdbf7edb6632fbd6f9cb@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps Operating System: 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): Replying to [comment:9 diatchki]: > I mean that the example I gave should be rejected, but the program is accepted. > Sorry, Iavor, I'm not following. GHC as at 8.0.1 seems to be behaving as documented here http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html #instance-resolution * It is fine for there to be a ''potential'' of overlap (...); an error is only reported if a particular constraint matches more than one [instance]. . > > The check for FD consistency is done when multiple instances come together, not when you use them. Are you saying this is what you'd like to see happening? What GHC is actually doing is checking FD consistency when it sees the instance decls, and only rejecting if the instances are outright contradictory. If there's only a ''potential'' inconsistency (due to overlap), GHC only rejects at the use site if it can't resolve to a particular instance. . > > This is necessary, because it ensures that the FD invariant on the class holds, and then we can use the invariant in whatever context we want. For the same reason, you can't have instances be consistent only in some cases. > Again, I think you're saying you'd like to be able to "use the invariant"/rely on them being consistent(?) . > > Currently GHC is very conservative in its use of FDs---it uses them only for type inference. Yes GHC is conservative. Whereas in the FDs-via-CHRs paper, it is expected that under an FD `C a b | a -> b` if we have `C a b` and `C a b'` we can conclude `b = b'` (that's type equality, not just unifiability); GHC does not arrive at any such conclusion. . > > This is why having inconsistent instances like the example I showed is not the end of the world: it may result in odd behavior where GHC sometimes infers the one type and sometimes the other, but the final result is still a sound Haskell program. > > For example, if GHC encountered a constraint `Foo (Int,Int) Int a`, where `a` is a unification variable, it might instantiate `a` as either `((),Int)` or `(Int,())` depending on in what order it happened to consult the instances. This is essentially the problem that was reported in the ticket. > Yes that is the problem reported on the ticket. AFAICT is was still a problem at 7.10. I see no evidence it is still happening at 8.0. (I've tried the same code at both versions.) I agree with @Reid it's rather discomforting this change of behaviour can't be nailed down to a specific mod. What you can still do in 8.0 is put a type signature, to get inconsistent behaviour: {{{ f4 = foo (5 :: Int, 7 :: Int) (9 :: Int) :: ((), Int) -- results in ((), 7) f5 = foo (5 :: Int, 7 :: Int) (9 :: Int) :: (Int, ()) -- results in (5, ()) }}} . > However, if GHC was to start using the FDs fully as they were intended, having inconsistent instances would lead to unsound type-checking. For example, in this case, GHC should be able to prove that `((),Int) ~ (Int,())`, which is obviously bogus. Hmm. "as they were intended" is rather debatable. For each of the examples you're bringing forward, you're using several extensions of Haskell beyond Haskell 2010: `UndecidableInstances` or non-full dependencies (in a way that breaks the FDs-via-CHRs rules) or overlap -- either `OverlappingInstances` or overlap of the types in a non-full dependency. In this case we're now discussing you need `FlexibleInstances`, again not envisaged in the paper. I think each of those extensions is justifiable. Furthermore for GHC to be using FD inference as per the FDs-via-CHRs rules would block separate compilation. (The CHRs assume you can see all instance decls.) So I think it's prudent GHC does not try to go that far, and therefore avoids the risk of unsound type-checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 06:56:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 06:56:37 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.398bc1f7505341973e273fd01242f420@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by svenpanne): The Haskell report is very explicit about these functions: > When the "By" function replaces an Eq context by a binary predicate, the predicate is assumed to define an equivalence; when the "By" function replaces an Ord context by abinary predicate, the predicate is assumed to define a total ordering. And the `Data.List` documentation repeats these requirements, so I propose to close this issue as "invalid". As a side note, I wouldn't call this an "infelicity": If your `Eq`/`Ord` instances don't obey the required laws, you would have similar fun with plain `group`. The `By` functions just make an implicit argument explicit, and I would be very surprised if they behaved differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 06:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 06:56:52 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ In-Reply-To: <044.319927771157cb149232cac95f75e05c@haskell.org> References: <044.319927771157cb149232cac95f75e05c@haskell.org> Message-ID: <059.d3be3f02cd7b5e9ea1083ac10ee568d6@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3319 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Also noting that to upgrade an existing GHC installation, just replace the distributed MinGW `gcc.exe` with one of [https://github.com/Mistuke/ghc- compat these]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 07:48:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 07:48:48 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.e78da856a6c03788a7223ab7386ee105@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism Comment: Yes, you are right: I think `coerce` (and similarly `Coercible`) should have type {{{ coerce :: forall l (a::TYPE l) (b::Type l). a -> b }}} More realistically than your example, I think we might reasonably want {{{ newtype Age = MkAge Int f :: Array# Age -> Array# Int f a = coerce a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 09:03:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 09:03:50 -0000 Subject: [GHC] #13578: Incorrect Record Pattern Synonym example in users guide In-Reply-To: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> References: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> Message-ID: <066.7d39820179acb6e8277bd57fcdc37b9f@haskell.org> #13578: Incorrect Record Pattern Synonym example in users guide -------------------------------------+------------------------------------- Reporter: cjholdbrooks | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.2.1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks for reporting this, it has already been fixed I think. Where are you viewing the docs? https://github.com/ghc/ghc/blob/master/docs/users_guide/glasgow_exts.rst#L4788 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 09:18:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 09:18:35 -0000 Subject: [GHC] #13592: Newtype type class with compiler generated instances In-Reply-To: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> References: <051.27867f10826897009c0eb6210d7ad90b@haskell.org> Message-ID: <066.c663f5ebaa89843f9abf78db388ca783@haskell.org> #13592: Newtype type class with compiler generated instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 09:41:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 09:41:17 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.32020faded469b0527cbee753a5e68e1@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 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): Gah! GHC has two sorts of bindings: `FunBind` and `PatBind`: * `FunBind` is used for function bindings, obviously, but also for bindings of form `x = e`. As the comments in `HsBinds.hs` say: {{{ -- FunBind is used for both functions @f x = e@ -- and variables @f = \x -> e@ -- -- Reason 1: Special case for type inference: see 'TcBinds.tcMonoBinds'. -- -- Reason 2: Instance decls can only have FunBinds, which is convenient. -- If you change this, you'll need to change e.g. rnMethodBinds }}} * `PatBind` is used for all other pattern bindings So `!x = e` is treated as a `PatBind`. And that means that it will take the `InferGen` patch (see `TcBinds.decideGeneralisationPlan`); and that means that it will behave differently type-inference-wise than `x = e; x :: sig`. And that is bad: bangs aren't supposed to affect typing. Best solution (I think): add a bang-flag to `FunRhs` (c.f. the `LexicalFixity` flag) in `HsExpr.HsMatchContext`. Then * `!x = e` would be a "simple" pattern binding * `FunBind` would handle all simple pattern bindings (as well as true function binding) NB: `(x) = e` would not be a "simple" pattern binding, and would still go via `PatBind`. Maybe that's even a feature. We could instead put the flag in `FunBind` itself, but I'm influenced by that `LexicalFixity` flag, which Alan migraed from `FunBind` to the `HsMatchContext` place (I forget why). I'm too swamped work on this, but I'll happily offer guidance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 09:41:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 09:41:40 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.00bdaf4a8cb0508fb30ab6771a6ba3a8@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | 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 simonpj): * keywords: => BangPatterns, RankNTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 11:42:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 11:42:21 -0000 Subject: [GHC] #13589: Possible inconsistency in CSE's treatment of NOINLINE In-Reply-To: <046.421ab366916136ec445d79115a39afdf@haskell.org> References: <046.421ab366916136ec445d79115a39afdf@haskell.org> Message-ID: <061.2a0f14bf34aeed2eedd063815d5ae190@haskell.org> #13589: Possible inconsistency in CSE's treatment of NOINLINE -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: CSE 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: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 13:26:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 13:26:09 -0000 Subject: [GHC] #13597: ghc: panic! (the 'impossible' happened) Message-ID: <043.13cf07504feb615a254f0537f1d73315@haskell.org> #13597: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: rzil | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Downloading stack-1.4.0... Configuring stack-1.4.0... Building stack-1.4.0... Failed to install stack-1.4.0 Build log ( /Users/ruben/.cabal/logs/stack-1.4.0.log ): cabal: Entering directory '/var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T/cabal- tmp-4956/stack-1.4.0' [1 of 1] Compiling Main ( /var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T/cabal- tmp-4956/stack-1.4.0/dist/setup/setup.hs, /var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T/cabal- tmp-4956/stack-1.4.0/dist/setup/Main.o ) Linking /var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T/cabal- tmp-4956/stack-1.4.0/dist/setup/setup ... Configuring stack-1.4.0... Building stack-1.4.0... Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, dist/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, dist/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, dist/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, dist/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, dist/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( dist/build/autogen/Paths_stack.hs, dist/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, dist/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, dist/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/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(/var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T/ghc17927_0/libghc_85.dylib, 5): no suitable image found. Did find: /var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T/ghc17927_0/libghc_85.dylib: malformed mach-o: load commands size (39456) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/var/folders/sr/jktws8p56m58qw9h6k53dbfr0000gn/T /cabal-tmp-4956/stack-1.4.0' cabal: Error: some packages failed to install: stack-1.4.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 13:35:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 13:35:25 -0000 Subject: [GHC] #13597: ghc: panic! (the 'impossible' happened) In-Reply-To: <043.13cf07504feb615a254f0537f1d73315@haskell.org> References: <043.13cf07504feb615a254f0537f1d73315@haskell.org> Message-ID: <058.2e29f8d07b3c4907baa3ef628ee4a145@haskell.org> #13597: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: rzil | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: This is a duplicate of #12479. **tl;dr** This is fixed in GHC 8.0.2. Simply download a `stack` binary that was built with 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 14:23:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 14:23:13 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.a8fff1e9b7a6755b304f2efc33dd9cb1@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by dsf): Yes, the Haskell report does contain this specification. I'm just trying to improve the documentation which is typically used by someone who is in the process of building Haskell code and is perhaps somewhat removed (at that moment) from the design decisions discussed in the Haskell report. I have found that the requirements of the reference documentation used while writing code is very different from those of the documents defining the language. The name and signature of groupBy give the impression that what I tried to do above would work, so I'm assuming that my mistake and consequent loss of time might be one that others would also make. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 14:25:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 14:25:02 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? Message-ID: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 constraint `Coercible o (T a)` is ambiguous if the role of `a` is representational (provided `a` is not otherwise constrained, of course), but unambiguous if `a` is a phantom type: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RoleAnnotations #-} module CoerceTest where import Data.Coerce type role A phantom data A a = MkA Int type role B representational data B a = MkB Int -- accepted by the type checker (as it should be) fooA :: Coercible o (A a) => o -> () fooA _ = () -- rejected by the type checker (as it should be) with -- "Couldn't match representation of type ‘a0’ with that of ‘a’" -- fooB :: Coercible o (B a) => o -> () -- fooB _ = () }}} However, for `newtype`s something odd happens: {{{#!hs type role C representational newtype C a = MkC Int -- accepted by the type checker (but should not be) fooC :: Coercible o (C a) => o -> () fooC _ = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 14:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 14:39:55 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.2feeca370fbe40e11766954ff6719fd1@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): My suspicion is that this is a result of the rather hacky way that we do dependency analysis for typed splices (where we just add everything in scope to the free variable set of the splice; see `Note [Free variables of typed splices]` in `RnSplice`) coupled with the fact that we don't run typed splices until type-checking (see `rnSpliceExpr`). This means that the declaration generated by the splice isn't present in the free variable set associated with the splice, causing us to fail during typechecking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 14:50:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 14:50:47 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.6136fc730b9ca5c24163576225d71e53@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, we should absolutely update the documentation to reflect this. I'll add a variant of the language in comment:8 to the Haddocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 14:55:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 14:55:13 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.4cdfd29e034f9911855b740d096b8d2b@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: 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): Role annotations on newtypes are less interesting when the newtype constructor is in scope. In your case, GHC reduces `Coercible (C a) Int` to `Coercible o Int` and away it goes. And indeed if you hide the `MkC` constructor (via the usual import/export mechanism), `fooC` fails because of ambiguity. I do see how this is potentially confusing, however. A concrete suggestion for improvement in documentation is always welcome. If you agree with my analysis, please close the ticket. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 14:58:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 14:58:29 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.43f1bc16a63c0e20ce558a6b2039c7c3@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by svenpanne): Hmmm, does that mean that every single function under 'The "By" operations' will get the sentence 'The predicate is assumed to define an equivalence.' '/ The function is assumed to define a total ordering.'? It's a little bit like repeating similar sentences for every function taking an Eq/Ord context... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:08:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:08:15 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.828875c6ae63aaeb4d130d7962f052a1@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, my plan was just to point this out for `groupBy` (see Phab:D3475), but I suppose you are right that this theme applies to many of the `*By` functions. Frankly, Haskell's core library documentation is often accused of being too sparse, so I don't consider a bit (perhaps slightly repetitious) detail to be a problem. However, if we did want to avoid repeating ourselves we could just add a general discussion of the expectations of the `By` functions to the documentation at the head of the module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:28:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:28:01 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.3d862cbaa271b1f5dcc4c1f814dc3f85@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 edsko): * status: new => closed * resolution: => invalid Comment: Hmmm, okay. So that explains why I had to import some constructors into my code in various places to make type errors mysteriously disappear.. even though I was not using those constructors anywhere in that code... Fair enough. I did and do find that very counter-intuitive but if that's how it's supposed to work.. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:28:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:28:10 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.b70a657010929ffeb70b56373da3d152@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire * milestone: => 8.2.1 Comment: Following a conversation with Richard, I'm assigning this to him and milestoning for 8.2.1. It should be fixed automatically when he commits the changes to `mkCastTy` and fixes for #13333. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:28:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:28:44 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.d2be193ab95584bbfb9de1184cbb79a9@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typeable, Resolution: | 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): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: typeable => typeable, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:30:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:30:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.c31e801c0c2719649bad683ca40782d1@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree that this is a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:33:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:33:14 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.4c332c6637fcc619886fa769c538caad@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > even though I was not using those constructors anywhere in that code The rationale (explained in the paper) is this. Without the built-in support for `Coercible` you could do everything by unpacking and repacking newtype constructors. Eg {{{ newtype Age = MkAge Pos newtype Pos = MkPos Int foo1, foo2 :: Age -> Int foo1 (MkAge (MkPos n)) = n foo2 n = coerce n }}} The `foo1` route requires `MkAge` and `MkPos` to be in scope; and you might hide them specifically to prevent you looking inside the abstraction (e.g. you might anticipate changing the representation of `Age` in the future). If so, then for the same reasons `foo2` should fail if `MkAge` or `MkPos` are not in scope. Does that help explain? Should we add something to the user manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:35:45 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.f6e539d049239f2e30f3ee08f1c30acc@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): goldfire, do you know why do we have this exceptional treatment for newtypes? It is not obvious what importance does having the data constructor in scope, regarding the meaning of roles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 15:47:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 15:47:47 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.1b94a8a91029ac1fea43aaed537ad6b3@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It looks like perhaps comment:4 and comment:3 were written concurrently. Facundo, does comment:3 adequately answer your question? If you want it the paper is [http://cs.brynmawr.edu/~rae/papers/2016/coercible-jfp /coercible-jfp.pdf here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 17:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 17:01:17 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.2301cfd0c26b388fbe67b48abae884ac@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps Operating System: 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): The check for overlapping is done when GHC resolves instances. This is unrelated to this example. You can easily modify it, so that there are no overlapping instances: {{{ class Foo tag a b c | a b -> c instance Foo Int (x, a) x ((), a) instance Foo Bool (x, a) a (x, ()) }}} The check for the consistency of FDs ought to be done whenever instances exist in the same scope, and there are two ways in which this can happen: 1. they were declared in the same module, in which case GHC will try to check their consistency---as this example illustrates, we have a bug in the checking code, as the instances are not reported as inconsistent; 2. when instances are imported into the same module. In this case GHC doesn't try to validate the comparability of the instances at all, which leads to obviously inconsistent FDs (e.g., `F Int Int` in one module, `F Int Char` in another, and both are OK when imported in a third module). It also leads to the fairly well-known bug of incoherent instances where GHC will happily allow two different instances for the same type tp be used in different modules. As far as I can tell, the new behavior in 8 is how GHC uses FDs to perform improvements. Instead of just using one of the instances, it will now try to improve with all of the instances. As a result, if there are inconsistencies, it will try to improve in two different ways, and report a delayed error. The underlying bug of failing to detect the inconsistency of the instances is still present. The thing that we should be checking is: {{{ forall x1 a2 x2 a2. ( (x1,a1) ~ (x2,a2), x1 ~ a2 ) => ( ((), a1) ~ (x2, ()) ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 17:17:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 17:17:37 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.ce697583caa375ea4dac2d80bc0324e3@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): From what the paper says, I gather that the reason to enable coercions between `C a` and `C b` when the constructors are in scope is to offer zero-cost coercions which wouldn't be possible to achieve if only the `foo1` route is allowed. I guess the user guide could discuss the newtype nuances for Coercible. Otherwise it looks like GHC is allowing coercions when it shouldn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 17:24:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 17:24:49 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.1771b5abae14568ceecc7976eab00aa3@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by dsf): Replying to [comment:12 svenpanne]: > Hmmm, does that mean that every single function under 'The "By" operations' will get the sentence 'The predicate is assumed to define an equivalence.' '/ The function is assumed to define a total ordering.'? It's a little bit like repeating similar sentences for every function taking an Eq/Ord context... Definitely not - this is a recipe for teaching people to ignore stuff. Elsewhere I said it makes sense to put it in the header, but consider that the particularly unexpected results come from groupBy. In the other cases you probablyu wouldn't consider using a non-transitive function argument: {{{#!hs -- What do these mean? > nubBy notBoth1 [1,1,2,3,1,1,4,5,6,1] [1,1,1,1,1] > deleteBy notBoth1 3 [1,1,2,3,1,1,4,5,6,1] [1,2,3,1,1,4,5,6,1] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 18:05:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 18:05:38 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.28953aeff932ea856589c7e1e048f3ff@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by svenpanne): I still claim that `groupBy` is by no means special: We have literally tons of functions which expect that some argument, be it implicit or explicit, obeys some laws, and those laws are not enforced by the type (so you can actually write down the type without having a Ph.D. in theoretical CS ;-). Take e.g. `Functor`: We expect that the Functor laws are obeyed by all instances. If they're broken, all odds are off and probably most of the function expecting such an argument do strange things. Non-transitive comparison for `sortBy`? Have fun... etc. etc. Nevertheless, we don't repeat such law-breaking examples all over the library documentation. Do we really know which of the 10 `fooBy` functions do something remotely sensible if they don't get an equivalence/total ordering? I doubt that. Without looking at the implementation I would have a hard time figuring that out. Putting the `notBoth1` example below the 'User-supplied equality (replacing an Eq context)' header and just repeating the equivalence requirement in each function documentation is probably the right thing. Similarly for `Ord`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 19:20:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 19:20:46 -0000 Subject: [GHC] #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC In-Reply-To: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> References: <042.01198c06f32ffd32a946f96081bf35de@haskell.org> Message-ID: <057.57f704f77f724346d4015ebeb4646072@haskell.org> #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC -------------------------------------+------------------------------------- Reporter: jms | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"a18f58d2290c5d5d44c7850ea04de279110d228b/ghc" a18f58d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a18f58d2290c5d5d44c7850ea04de279110d228b" testsuite: disable 'optllvm' for unregisterised compiler commit 74615f412ad3de2910a156ff494bfe5497fada7e ("UNREG: ignore -fllvm (Trac #13495)") enabled 'optllvm' tests to be ran in 'make fulltest' mode. As a result many (~1000) tests fail due to stderr misamatch: +when making flags consistent: warning: + Compiler unregisterised, so compiling via C The change removes 'optllvm' tests for unregisterised compiler. Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 20:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 20:26:23 -0000 Subject: [GHC] #13599: Something is fishy in Windows hLock implementation Message-ID: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> #13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- Ever since we merged the package database locking patch (#13194) I have suspected that something isn't quite right in the locking logic on Windows. The first suspicious sign is that we had to limit the locking range (7e273ea28fe3630a8fede75ed28f471b7be21b5f) due to mysterious `ERROR_LOCK_INVALID_RANGE` errors on Harbormaster. While the fix in 7e273ea28fe3630a8fede75ed28f471b7be21b5f seemed to make the issue disappear, we never were able to pin down the issue. However, now I'm seeing the `ERROR_LOCK_INVALID_RANGE` issue once again on my local Windows during `binary-dist-prep`. In particular, it `binary- dist-prep` seems to reliably fail while registering the `compiler` directory. Watching the system calls performed by `ghc-pkg` with `procmon` suggests that the issue is a negative offset being passed to `LockFile`. Moreover, `LockFile` calls from previous `ghc-pkg` invocations show other, apparently random offset values being passed. The offset is passed to `LockFileEx` (the interface used by our `hLock` implementation) via an `OVERLAPPED` structure, which we locally allocate and zero prior to the `LockFileEx` call. I still haven't worked out where these random values are coming from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 20:35:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 20:35:51 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.8703c1f7e4858c3f882149f11edf8cf4@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by dsf): That seems satisfactory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 22:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 22:21:28 -0000 Subject: [GHC] #13599: Something is fishy in Windows hLock implementation In-Reply-To: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> References: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> Message-ID: <061.8588786e331fa48bf5f9bf9b34d71246@haskell.org> #13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): Well, this is embarrassing. I just took a look at the definition of `fillBytes` and it looks like the arguments in `lockImpl` are passed backwards, so instead of filling sizeof_OVERLAPPED bytes with value 0 it fills 0 bytes with value sizeof_OVERLAPPED, leaving it effectively uninitialized. I believe the following should do the trick: {{{#!diff diff --git a/libraries/base/GHC/IO/Handle/Lock.hsc b/libraries/base/GHC/IO/Handle/Lock.hsc index 5608c1810c..3e790a233a 100644 --- a/libraries/base/GHC/IO/Handle/Lock.hsc +++ b/libraries/base/GHC/IO/Handle/Lock.hsc @@ -123,7 +123,7 @@ lockImpl h ctx mode block = do FD{fdFD = fd} <- handleToFd h wh <- throwErrnoIf (== iNVALID_HANDLE_VALUE) ctx $ c_get_osfhandle fd allocaBytes sizeof_OVERLAPPED $ \ovrlpd -> do - fillBytes ovrlpd (fromIntegral sizeof_OVERLAPPED) 0 + fillBytes ovrlpd 0 sizeof_OVERLAPPED let flags = cmode .|. (if block then 0 else #{const LOCKFILE_FAIL_IMMEDIATELY}) -- We want to lock the whole file without looking up its size to be -- consistent with what flock does. According to documentation of LockFileEx @@ -131,7 +131,7 @@ lockImpl h ctx mode block = do -- not an error", however some versions of Windows seem to have issues with -- large regions and set ERROR_INVALID_LOCK_RANGE in such case for -- mysterious reasons. Work around that by setting only low 32 bits. - fix $ \retry -> c_LockFileEx wh flags 0 0xffffffff 0x0 ovrlpd >>= \case + fix $ \retry -> c_LockFileEx wh flags 0 0xffffffff 0xffffffff ovrlpd >>= \case True -> return True False -> getLastError >>= \err -> if | not block && err == #{const ERROR_LOCK_VIOLATION} -> return False }}} Should I make a Phab patch or you can do it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 20 22:34:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Apr 2017 22:34:55 -0000 Subject: [GHC] #13599: Something is fishy in Windows hLock implementation In-Reply-To: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> References: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> Message-ID: <061.09bdce5a321c7a093fc99d5c9c7e0a60@haskell.org> #13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Great catch! I can take it from here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 01:49:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 01:49:20 -0000 Subject: [GHC] #11799: Legend for hpc markup colors In-Reply-To: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> References: <047.314ffbb861201aff98726d88b5f478b7@haskell.org> Message-ID: <062.158f902a740cb2b74d40474bf02bcb02@haskell.org> #11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: SantiM Type: feature request | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3465, Wiki Page: | Phab:D3479 -------------------------------------+------------------------------------- Changes (by SantiM): * differential: Phab:D3465 => Phab:D3465, Phab:D3479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 02:17:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 02:17:51 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.d1af358ce3f6b59b04f66dd5b2c996ae@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: FunDeps Operating System: 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): Replying to [comment:11 diatchki]: > The check for overlapping is done when GHC resolves instances. This is unrelated to this example. You can easily modify it, so that there are no overlapping instances: > > {{{ > class Foo tag a b c | a b -> c > > instance Foo Int (x, a) x ((), a) > instance Foo Bool (x, a) a (x, ()) > }}} No, that class decl is not allowed, according to the FDs-via-CHRs paper, Section 6.2 on Non-full dependencies. (And this example is similar to yours on #10675 -- which I think is also disallowed.) If the FD is non- full, the class must have a super-class constraint to enforce the FD. Otherwise we still get inconsistent behaviour, which is your complaint on #10675. . > > The check for the consistency of FDs ought to be done whenever instances exist in the same scope, ... You mean like dear old Hugs? Yes I miss it for that reason. But I think you can still get inconsistent behaviour with overlapping instances, if some instances are in scope in one module but different instances in scope in a different module. I think what it needs is to ban overlap altogether. (And that means for non-full FDs, banning overlap of the params involved with that FD. We have to be canny there: allow identical params, modulo alpha renaming.) Then we just reject any instance that attempts to overlap. (Again Hugs in effect did that with its check "Instance is inconsistent with FunDeps".) But what we can do currently with overlapping instances is useful. We need a more expressive way to say in the instance: yes I know this looks like it overlaps, but actually I don't want it to; when the use site appears to be ambiguous, always pick that instance. For example with instance guards: {{{ class Foo a b c | a b -> c instance Foo (x, a) x ((), a) | x /~ a instance Foo (x, a) a (x, ()) }}} The guard on that first instance says: `x` must not be unifiable with `a`, so do not select this instance if unifiable. That's the same as Richard's apartness check for Closed Type Families selecting equations. More discussion here https://typesandkinds.wordpress.com/2013/04/29/coincident- overlap-in-type-families/ . > > As far as I can tell, the new behavior in 8 is how GHC uses FDs to perform improvements. Instead of just using one of the instances, it will now try to improve with all of the instances. As a result, if there are inconsistencies, it will try to improve in two different ways, and report a delayed error. "New"? You're describing the behaviour Simon raises in #10675, which was at 7.10. And judging by "Examples in the testsuite that exploit this loophole ", it's been around for some time. I agree with you that GHC should not try to merge or mingle/mangle type improvements from different instances. The behaviour in #10675 is just nuts. (But trying to cure it might be worse than the disease. It does seem to be a swamp.) . > > The underlying bug of failing to detect the inconsistency of the instances is still present. > > The thing that we should be checking is: > {{{ > forall x1 a2 x2 a2. ( (x1,a1) ~ (x2,a2), x1 ~ a2 ) => ( ((), a1) ~ (x2, ()) ) > }}} Yes, which we can do with a superclass constraint, such as a type function with equality constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 08:21:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 08:21:11 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.34a0212fb65c63ee472843c2908dabbc@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): To make this work, don't we need the kind to express that values (lifted or not) are represented by pointers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 09:33:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 09:33:46 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.270513ea118f25a7e954287dcc95f793@haskell.org> #8996: mark more things as const in C codegen -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (CodeGen) | 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:D3481 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D3481 Comment: Three years later I now have a vague idea how things fit togeter now :) Sent https://phabricator.haskell.org/D3481 for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 09:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 09:55:17 -0000 Subject: [GHC] #13600: surprising error message with bang pattern Message-ID: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 10:25:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 10:25:50 -0000 Subject: [GHC] #13601: GHC errors but hangs Message-ID: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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 TypeFamilies, DataKinds, TypeInType #-} import GHC.Exts import Prelude (Bool(True,False),Integer,Ordering,undefined) import qualified Prelude import Data.Kind -------------------- -- class hierarchy type family Rep (rep :: RuntimeRep) :: RuntimeRep where -- Rep IntRep = IntRep -- Rep DoubleRep = IntRep -- Rep PtrRepUnlifted = IntRep -- Rep PtrRepLifted = PtrRepLifted class Boolean (Logic a) => Eq (a :: TYPE rep) where type Logic (a :: TYPE rep) :: TYPE (Rep rep) (==) :: a -> a -> Logic a class Eq a => POrd (a :: TYPE rep) where inf :: a -> a -> a class POrd a => MinBound (a :: TYPE rep) where minBound :: () -> a class POrd a => Lattice (a :: TYPE rep) where sup :: a -> a -> a class (Lattice a, MinBound a) => Bounded (a :: TYPE rep) where maxBound :: () -> a class Bounded a => Complemented (a :: TYPE rep) where not :: a -> a class Bounded a => Heyting (a :: TYPE rep) where infixr 3 ==> (==>) :: a -> a -> a class (Complemented a, Heyting a) => Boolean a (||) :: Boolean a => a -> a -> a (||) = sup (&&) :: Boolean a => a -> a -> a (&&) = inf }}} hangs with {{{ $ ghci a.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:18:16: error: C-c C-cInterrupted. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 10:30:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 10:30:04 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.04c7346f7e3b971285f6c0d6f9b562b3@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): You need to turn on the `BangPatterns` extension, otherwise you are defining an infix operator `!`. The error message is then accurate as you have given a type signature for `f4` but then defined `!`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 12:06:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 12:06:48 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.f68a7612ec0eefe3d4f5faf42767f443@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha, Matthew is right! Maybe it would help if, when GHC sees an infix definition for `(!)`, and the `!` immediately precedes the second argument, we suggested the possibility of bang patterns? To suppress the warning, we'd suggest adding a space, thus {{{ f4 ! x = ... }}} I think that'd be useful, if someone wants to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 12:15:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 12:15:46 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.d2357c3f735747baec65e66143e2e4f2@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewufrank): Thank you very much for the clarification. As i said, i have not much experience with bang patterns and did not see in the manual the hint that I would have to turn on an extension. Perhaps somebody could revise the relevant parts of the ghc docs. andrew -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 12:36:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 12:36:52 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.4f63026370e9ffc9aacbcbb1e80538b4@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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 was running out the door when I submitted that, here is a more minimal example {{{#!hs {-# Language TypeFamilies, DataKinds, TypeInType #-} -- {-# Language FlexibleContexts, UndecidableSuperClasses #-} import GHC.Exts -- (TYPE, RuntimeRep) import Data.Kind type family Rep (rep :: RuntimeRep) :: RuntimeRep class Boolean (Logic a) => Eq' (a :: TYPE rep) where type Logic (a :: TYPE rep) :: TYPE (Rep rep) class Eq' a => MinBound (a :: TYPE rep) where class Eq' a => Lattice (a :: TYPE rep) where class (MinBound a, Lattice a) => Boolean a }}} It is fixed by uncommenting the final two pragmas and writing {{{#!hs class (MinBound a, Lattice a) => Boolean (a :: TYPE rep) }}} ---- Alternatively, only commenting out `import GHC.Exts (TYPE, RuntimeRep)` gives us an ever-so-slightly different error {{{ c.hs:10:16: error: • Expected kind }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 12:37:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 12:37:56 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.3dce2385f71b39db2ac935372254de31@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => TypeInType, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 15:01:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 15:01:29 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.f89eb3812e473e6b0e1c6ba0c2af9c34@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Re comment:3: Why? The `coerce` gets completely compiled away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 15:35:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 15:35:19 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.0ff2ab691aaf0cbdb5a092b38d46eb8c@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 goldfire]: > Re comment:3: Why? The `coerce` gets completely compiled away. Oh, is that guaranteed these days? Last I read about the mechanism I don't think it was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 16:32:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 16:32:26 -0000 Subject: [GHC] #13527: ghc has a stack space leak when prints warnings In-Reply-To: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> References: <045.5a0c316dbaa8e26db5090b5d71d4a131@haskell.org> Message-ID: <060.f9c6906bc9cfa51dff954e1216c92003@haskell.org> #13527: ghc has a stack space leak when prints warnings -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged as ec5a49fe34180da0adcd7956ad60a9f8ba04c775 and 0eb5004ae3d58032bb48d77a19bed556af7c4f72. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 17:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 17:24:01 -0000 Subject: [GHC] #13599: Something is fishy in Windows hLock implementation In-Reply-To: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> References: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> Message-ID: <061.4c4d6350cbd476b94f3c125377fb805c@haskell.org> #13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e134af010bdd0d2a94fbfd68e0605dc55e1be3a8/ghc" e134af01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e134af010bdd0d2a94fbfd68e0605dc55e1be3a8" base: Fix offset initialization of Windows hLock implementation The previous implementation swapped the buffer size with the byte to be set, essentially resulting in an uninitialized buffer. Test Plan: Validate on Windows Reviewers: austin, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #13599 Differential Revision: https://phabricator.haskell.org/D3478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 17:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 17:24:01 -0000 Subject: [GHC] #13252: Perf: Make dep_finsts a map from type family Name to Module In-Reply-To: <045.b72311e30e9fb5fc5e3bed039056d14b@haskell.org> References: <045.b72311e30e9fb5fc5e3bed039056d14b@haskell.org> Message-ID: <060.dc7b947278ac33ca8de01fec72992957@haskell.org> #13252: Perf: Make dep_finsts a map from type family Name to Module -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e5732d2a28dfb8a754ee73e124e3558222a543bb/ghc" e5732d2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5732d2a28dfb8a754ee73e124e3558222a543bb" base: Fix hWaitForInput with timeout on POSIX This was previously broken (#13252) by f46369b8a1bf90a3bdc30f2b566c3a7e03672518, which ported the fdReady function from `select` to `poll` and in so doing dropping support for timeouts. Unfortunately, while `select` tells us the amount of time not slept (on Linux anyways; it turns out this is implementation dependent), `poll` does not give us this luxury. Consequently, we manually need to track time slept in this case. Unfortunately, portably measuring time is hard. Ideally we would use `clock_gettime` with the monotonic clock here, but sadly this isn't supported on most versions of Darwin. Consequently, we instead use `gettimeofday`, running the risk of system time changes messing us up. Test Plan: Validate Reviewers: simonmar, austin, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13252 Differential Revision: https://phabricator.haskell.org/D3473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 17:24:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 17:24:44 -0000 Subject: [GHC] #13599: Something is fishy in Windows hLock implementation In-Reply-To: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> References: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> Message-ID: <061.8797e9bceb4324903ed2dc98c7df69f6@haskell.org> #13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 17:25:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 17:25:54 -0000 Subject: [GHC] #13599: Something is fishy in Windows hLock implementation In-Reply-To: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> References: <046.da3b07af8fdf8de809a5ed5a212fddab@haskell.org> Message-ID: <061.0e18cf005734c69b7785f17fcf8da11c@haskell.org> #13599: Something is fishy in Windows hLock implementation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged in e5732d2a28dfb8a754ee73e124e3558222a543bb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 19:19:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 19:19:09 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.c6f1835d18f5c9b076afb14046c0affa@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Phab:D3473 Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bgamari): Merged to `master` as, In [changeset:"e5732d2a28dfb8a754ee73e124e3558222a543bb/ghc" e5732d2/ghc]: {{{ base: Fix hWaitForInput with timeout on POSIX This was previously broken (#13252) by f46369b8a1bf90a3bdc30f2b566c3a7e03672518, which ported the fdReady function from `select` to `poll` and in so doing dropping support for timeouts. Unfortunately, while `select` tells us the amount of time not slept (on Linux anyways; it turns out this is implementation dependent), `poll` does not give us this luxury. Consequently, we manually need to track time slept in this case. Unfortunately, portably measuring time is hard. Ideally we would use `clock_gettime` with the monotonic clock here, but sadly this isn't supported on most versions of Darwin. Consequently, we instead use `gettimeofday`, running the risk of system time changes messing us up. Test Plan: Validate Reviewers: simonmar, austin, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13252 Differential Revision: https://phabricator.haskell.org/D3473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 19:19:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 19:19:32 -0000 Subject: [GHC] #13252: Perf: Make dep_finsts a map from type family Name to Module In-Reply-To: <045.b72311e30e9fb5fc5e3bed039056d14b@haskell.org> References: <045.b72311e30e9fb5fc5e3bed039056d14b@haskell.org> Message-ID: <060.b34f857e96afd2473ebc15f34bd574fc@haskell.org> #13252: Perf: Make dep_finsts a map from type family Name to Module -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): N.B. the above was intended for #13525. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 20:34:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 20:34:45 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.580a349b865ba4f161eb1c88c207c67f@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | 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 bgamari): * owner: (none) => bgamari * priority: normal => high * milestone: => 8.2.1 Comment: I have a patch validating for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 21 20:57:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Apr 2017 20:57:10 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.d499ceb55aa28a0d67e08bcb36a5975e@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/StrictBinds Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: goldfire => (none) * status: closed => new * resolution: fixed => Comment: But top-level banged patterns (as in the example program in the ticket) are still accepted, despite the new note `[Strict binds checks]` and existing documentation to the contrary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 00:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 00:57:44 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.cf3ae03bc19e48b09e8c83329dfc1a68@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 00:57:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 00:57:57 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.594cbd5047151dde9d2d763bd00f59e2@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Update: I removed some cruft from the previous attached file, so now it's down to 633 lines (originally 1367). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 02:27:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 02:27:20 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.9cff1024b1276b0b3a0a27e5861e9205@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Phab:D3473 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: patch => merge Comment: Merged to `ghc-8.2` as 91c4e6b6531db59b0cd4386cf0ba8f9db35728ba. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 02:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 02:30:12 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.a8d08c2c466dbdff0859d10884acf3be@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12912, #8684 | Differential Rev(s): Phab:D3473 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 03:04:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 03:04:42 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.dc0210500c0da68fafc18c4f1b15139e@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug3.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 03:05:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 03:05:17 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.16c8850dd89bbc8329d1de4280969c94@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I pushed some more, and managed to get it down to 158 lines. And I think that's probably the limit of my ability to debug this :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 14:05:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 14:05:13 -0000 Subject: [GHC] #13602: Pattern syntax in expression context must be clarified Message-ID: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> #13602: Pattern syntax in expression context must be clarified -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To simonpj\\ see tickets {{{#13557}}} and {{{#13579}}}\\ Typed Holes does not exist if we compile with GHC version 7.6.3. Instead of "error found holes" it indicates "pattern syntax in expression context: _".\\ I then understood that to improve Typed Holes it was first necessary to remove the ambiguity of the error in GHC 7.6.3 about pattern syntax in expression.\\ {{{let f = [True | x <- [_, _]]}}} raise the error {{{pattern syntax in expression context: _}}}\\ But as Typed Holes, this error has no sense here.\\ {{{let f' = [_ | x <- [1,2]]}}}will give a result like {{{"__"}}} And this calculation also makes sense if one refers to the rule of inference, as the function {{{f}}} .\\ \\ The compiler should not impose its way.\\ The programmer must be the master of his code. Here the rule of inference seems flouted.\\ Good sense or reason is argued to be the same in all people, yet differences in opinion are not due to differences in intelligence but to the fact that we use different approaches and consider different things.\\ Here you will find some ideas:\\ Instead of "underscore _" as "pattern syntax" we could use a new type called "indefinite" in expression.\\ Any calculation with "indefinite" will result in "indefinite".\\ In another calculation, the "indefinite" type could have a type defined according to a directive applied to the compiler.\\ example:\\ indefinite :: Int\\ f = [1,2,3,indefinite,5,6]\\ I took a look at ticket {{{#9497}}} and find it very interesting.\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 15:26:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 15:26:35 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.236ed7efe202ea4eb3bf6b730484f1f7@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:9 RyanGlScott]: > And I think that's probably the limit of my ability to debug this :) OK, I lied. I //was// able to discover a workaround by placing kind signatures at random places until I found a trick that worked reliably. Here's how you can fix each of the files I posted: {{{#!diff diff --git a/Bug.hs b/Bug.hs index d534fe0..52163b8 100644 --- a/Bug.hs +++ b/Bug.hs @@ -1127,7 +1127,7 @@ src/Data/Singletons/Prelude/List.hs:(260,3)-(806,4): Splicing declar lambda_a33gY xs0_a33gZ = let sPerms :: - forall arg_a33h0 arg_a33h1. + forall (arg_a33h0 :: [a_a337f]) arg_a33h1. Sing arg_a33h0 -> Sing arg_a33h1 -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) ar @@ -1153,7 +1153,7 @@ src/Data/Singletons/Prelude/List.hs:(260,3)-(806,4): Splicing declar lambda_a33ha t_a33hb ts_a33hc is_a33hd = let sInterleave' :: - forall arg_a33he arg_a33hf arg_a33hg. + forall (arg_a33he :: TyFun [a_a337f] k -> Type) arg_a33hf a Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg }}} {{{#!diff diff --git a/Bug2.hs b/Bug2.hs index 98fbbf0..75c4523 100644 --- a/Bug2.hs +++ b/Bug2.hs @@ -393,7 +393,7 @@ src/Data/Singletons/Prelude/List.hs:(260,3)-(806,4): Splicing declarat lambda_a33gY xs0_a33gZ = let sPerms :: - forall arg_a33h0 arg_a33h1. + forall (arg_a33h0 :: [k]) arg_a33h1. Sing arg_a33h0 -> Sing arg_a33h1 -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) ar @@ -419,7 +419,7 @@ src/Data/Singletons/Prelude/List.hs:(260,3)-(806,4): Splicing declarat lambda_a33ha t_a33hb ts_a33hc is_a33hd = let sInterleave' :: - forall arg_a33he arg_a33hf arg_a33hg. + forall (arg_a33he :: TyFun [k] j -> Type) arg_a33hf arg_a33 Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg }}} {{{#!diff diff --git a/Bug3.hs b/Bug3.hs index 77484b2..a286b43 100644 --- a/Bug3.hs +++ b/Bug3.hs @@ -115,7 +115,7 @@ lambda_a33gY _ lambda_a33ha _ _ _ = let sInterleave' :: - forall arg_a33he arg_a33hf arg_a33hg. + forall (arg_a33he :: TyFun [k] j -> Type) (arg_a33hf :: [y]) (arg_a33hg :: z). Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg }}} The `Bug3` fix is interesting, since I didn't have to specify the kind of a type variable in `sPerms`. But perhaps that's just because I had replaced so many things by `undefined` by that point that the kind inference behavior had changed. So now the question is: is this just another occurrence of #13555 in disguise? Or is there an actual bug here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 15:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 15:42:39 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.4c09a4eb55e5fef138a1cebdedff09d4@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Regarding adding `implies` (`(==>)`), [https://ghc.haskell.org/trac/ghc/ticket/10592#comment:12 here is the hierarchy] I'm most intrigued by {{{#!hs class Boolean (Logic a) => Eq a where type Logic a :: Type (==) :: a -> a -> Logic a class Eq a => POrd a where inf :: a -> a -> a class POrd a => MinBound a where minBound :: a class POrd a => Lattice a where sup :: a -> a -> a class (Lattice a, MinBound a) => Bounded a where maxBound :: a class Bounded a => Complemented a where not :: a -> a class Bounded a => Heyting a where infixr 3 ==> (==>) :: a -> a -> a class (Complemented a, Heyting a) => Boolean a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 16:59:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 16:59:22 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass Message-ID: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works {{{#!hs {-# Language PolyKinds, TypeInType #-} import GHC.Exts (TYPE, RuntimeRep) class A (a :: TYPE rep) class A a => B (a :: TYPE rep) instance A b => A (a -> (b :: TYPE rep)) instance B b => B (a -> b) }}} but the moment you add (`b :: TYPE rep`) to the last line it stops working {{{#!hs -- t3I7.hs:9:10-40: error: … -- • Could not deduce (A b) -- arising from the superclasses of an instance declaration -- from the context: B b -- bound by the instance declaration at /tmp/t3I7.hs:9:10-40 -- • In the instance declaration for ‘B (a -> b)’ -- Compilation failed. {-# Language PolyKinds, TypeInType #-} import GHC.Exts (TYPE, RuntimeRep) class A (a :: TYPE rep) class A a => B (a :: TYPE rep) instance A b => A (a -> (b :: TYPE rep)) instance B b => B (a -> (b :: TYPE rep)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 19:23:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 19:23:17 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.f42a9ffe9f295f31b76289a96bf94dd6@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I believe it is. There's no other implementation for `coerce` than no-op. What might not be compiled away is a call like `map coerce`, but we have RULES for that. Regardless, levity polymorphism does not complicate that story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 19:52:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 19:52:23 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.d486b986902349a98aac255987f412b2@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I still think this is #13555. In all cases, the extra kind signatures mention kind variables, which GHC is now not generalizing. What surprises me about this case is that no generalization should be necessary to compile the singled `permutations`. My best guess is that untouchable type variables induced by some GADT pattern matching prevent GHC from inferring the correct kinds of the functions. If their kinds are generalized, then all works out. But since they are not being generalized any more, we run into a problem. I'm inclined to try to understand this as an infelicity in singletons, that it produces code that GHC can't infer the kinds of. I doubt singletons can fix the problem, but it would be nice to be able to characterize what exactly is the cause of the problem and then document the infelicity. In the meantime, I'd bet that adding a type annotation to `perms` and `interleave` in the `Data.Singletons.Prelude.List` implementation would allow singletons to compile. I'm happy to do the further digging, but not for a few weeks, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 20:02:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 20:02:33 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.e8d3e0f7452e903f1f19953ea6350767@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism, 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): Seems to be fixed in HEAD; I can't reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 21:33:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 21:33:14 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.945ccd857914d93dc79e60ea16067e23@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Source level `coerce` takes a boxed coercion and unboxes it before it is a no-op. In most cases, the compiler will optimize this unboxing away, but I am actually not sure what guarantees we have here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 22:43:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 22:43:09 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.b225be43217c938b74c3c4f284bc2aed@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: high => normal * milestone: 8.2.1 => 8.4.1 Comment: You are correct that adding more type signatures to the `where`-bound functions of `permutations` (specifically, `interleave'`) resolves the issue upstream in `singletons`. Given that there's a viable workaround, I'm going to reduce the priority of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 22 23:56:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Apr 2017 23:56:10 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.e5fc682388dc3ae5c65cf2a96432f592@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 George): * failure: Other => Runtime performance bug Comment: In the context of ghci, the ignored -O in the .ghci file results in a runtime performance bug. Thus I changed the type of failure to runtime performance bug (in the context of ghci which is the component). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 00:31:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 00:31:44 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) Message-ID: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- In 8.2.1-rc1 loading a file compiled with -O2 into ghci results in ghci recompiling the file into interpreted byte code. In 8.0.2 it simply loads the compiled object file. 8.2.1 {{{ ghc -dynamic -O2 eh2.hs [1 of 1] Compiling Main ( eh2.hs, eh2.o ) Linking eh2 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help Prelude> :load eh2 [1 of 1] Compiling Main ( eh2.hs, interpreted ) [flags changed] Ok, modules loaded: Main. }}} 8.0.2 {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 bash-3.2$ pwd /Users/gcolpitts/haskell bash-3.2$ ghc -dynamic -O2 eh2.hs [1 of 1] Compiling Main ( eh2.hs, eh2.o ) Linking eh2 ... bash-3.2$ ghci -ignore-dot-ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load eh2 Ok, modules loaded: Main (eh2.o). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 00:34:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 00:34:09 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.2e61adc525025f7af55e3de08a46005e@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 George): This was on a Mac with 8.2.1-rc1 compiled from source. Setting OS and architecture to Unknown/Multiple as I don't see any reason why this would be Mac specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 00:48:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 00:48:53 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.8b8a92c4d26a3653c5dca0e28f90564e@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.2017040) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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): * version: 8.0.1 => 8.2.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 00:49:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 00:49:34 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) (was: regression in ghc 8.2.1-rc1 (8.2.0.2017040)) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.822a3297de4eebe6d7a9b157e440afcd@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 03:05:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 03:05:02 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.b1c4d9bdf555a449af48a586fc4781a1@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: I think I understand this now. This is a fundamental difference between inference for types and inference for kinds. Here is the original, unsingletonized code in question: {{{#!hs permutations :: [a] -> [[a]] permutations xs0 = xs0 : perms xs0 [] where -- perms :: forall a. [a] -> [a] -> [[a]] perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where -- interleave :: [a] -> [[a]] -> [[a]] interleave xs r = let (_,zs) = interleave' id xs r in zs -- interleave' :: ([a] -> [a]) -> [a] -> [[a]] -> ([a],[[a]]) interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) }}} Note that the local function signatures are commented out. This code compiles, although if you uncomment the type signatures, you'd need `ScopedTypeVariables`. Let's consider type-checking this with `MonoLocalBinds` on (that is, "let should not be generalized"). The body of `interleave'` mentions `t`, a variable that's not local to `interleave'`. Thus, according to `MonoLocalBinds`, its type should not be generalized. The problem is that the type cannot be fully figured out solely by looking at the definition of `interleave'`: by the time type inference is done with `interleave'`, we know only that its type looks like `([a1] -> a2) -> [a1] -> [a2] -> ([a1], [a2])`. Later, we will learn that `a2` is really `[a1]`. This is just fine for type inference, but it's bad for kind inference. The problem is that when GHC sees a type signature `x :: ty`, it interprets `ty` independent of any definition or usage of `x`. After processing that statement, `ty` has been desugared and is set in stone -- including the kinds of any type variables in `ty`. After singletonizing, the type of the singletonized version of `interleave'` will mention the type family `Interleave'`, whose body is just like that of `interleave'`. This type family's kind ''will'' mention both `a1` and `a2`, as it has no reason not to. So `sInterleave'` would also have to have a generalized kind for it all to work out. But with the improvement in `decideKindGeneralisationPlan`, this doesn't happen. So, here is the characterization of the infelicity in singletons: if a local function's type would be different depending on the presence of `MonoLocalBinds`, then it needs a type signature in order for singletons to work. In the case of `interleave'`, without `MonoLocalBinds`, `a2` is quantified over, leading to a different type than it would have otherwise. (Note that the kind for the `Interleave'` type family is generalized, regardless of `MonoLocalBinds`.) I'm fairly confident in this analysis. I'm going to close the ticket as a dup of #13555. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 09:57:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 09:57:55 -0000 Subject: [GHC] #1952: Max and Min for Monoid In-Reply-To: <044.1b83eeaeebb32eb932d16a30464c2990@haskell.org> References: <044.1b83eeaeebb32eb932d16a30464c2990@haskell.org> Message-ID: <059.eb8ec3e143d34557db5744e2bdd8cd47@haskell.org> #1952: Max and Min for Monoid -------------------------------------+------------------------------------- Reporter: conal | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Semigroup.html Semigroup instances] for `Min` and `Max` have been added to base -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 10:36:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 10:36:10 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.a03383267fb590497b75a749fc6fafa5@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"f446f6a3cff21bb709ea501c5be87b0282d5da1c/ghc" f446f6a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f446f6a3cff21bb709ea501c5be87b0282d5da1c" First update mingw-w64 packages for 8.4 Summary: Updating to get latest binutils etc. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, snowleopard GHC Trac Issues: #12913 Differential Revision: https://phabricator.haskell.org/D3382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 11:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 11:59:10 -0000 Subject: [GHC] #13605: GHC Bug when updating stack Message-ID: <045.f70570ae2959e92920bc485a9be079c8@haskell.org> #13605: GHC Bug when updating stack -------------------------------------+------------------------------------- Reporter: pighcu | Owner: (none) 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: -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/y5/cc8zwjz12w1567wglxgzt05c0000gn/T/ghc39074_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/y5/cc8zwjz12w1567wglxgzt05c0000gn/T/ghc39074_0/libghc_68.dylib: malformed mach-o: load commands size (49368) > 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 Sun Apr 23 13:55:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 13:55:31 -0000 Subject: [GHC] #13605: GHC Bug when updating stack In-Reply-To: <045.f70570ae2959e92920bc485a9be079c8@haskell.org> References: <045.f70570ae2959e92920bc485a9be079c8@haskell.org> Message-ID: <060.1efc39aada9ac4815d4a3c3e96123af6@haskell.org> #13605: GHC Bug when updating stack -------------------------------------+------------------------------------- Reporter: pighcu | Owner: (none) 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 regression in Mac OS X Sierra's linker. The issue is worked around by GHC 8.0.2 and later. See #12479 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:00:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:00:41 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.c6292a0937983d7c51b38709b0eb54a9@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: typecheck/should_fail/StrictBinds => typecheck/should_fail/T13075 Comment: In fact, it's not clear that the `StrictBinds` test actually tests this issue at all. I've added the program in the ticket description as `T13075`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:06:04 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.e828c465f688ea914dc10b3106850407@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch 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: | Differential Rev(s): Phab:D3472 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"18c3a7ea0f7577514721feadefd9a62c228edb60/ghc" 18c3a7e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18c3a7ea0f7577514721feadefd9a62c228edb60" Document the kind generalization behavior observed in #13555 The conclusion of #13555 was that a program which began to fail to typecheck (starting in GHC 8.2) was never correct to begin with. Let's document why this is the case with respect to `MonoLocalBinds`' interaction with kind generalization. Also adds the reported program as a `compile_fail` testcase. Test Plan: make test TEST=T13555 # Also, read the docs Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: goldfire, simonpj, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13555 Differential Revision: https://phabricator.haskell.org/D3472 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:06:04 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.e03ea93fbe4f06435b3a6a5a83d2b2ee@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"907b0f3da6f8fafaa39caba92a5611040f5de786/ghc" 907b0f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="907b0f3da6f8fafaa39caba92a5611040f5de786" testsuite: Add testcase for #13587 Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13587 Differential Revision: https://phabricator.haskell.org/D3474 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:06:04 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.734a76f6f3a578642cc5fc5681e3f588@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"868bdcc8f152935803f6ff133766719ada077bdb/ghc" 868bdcc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="868bdcc8f152935803f6ff133766719ada077bdb" testsuite: Add testcase for #13075 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:06:04 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.5f4f5cb4b4e65f1687e4c5a8a4053ee1@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f6eaf01c14960f9d600d5e4c743efc59c37bd4e3/ghc" f6eaf01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f6eaf01c14960f9d600d5e4c743efc59c37bd4e3" testsuite: Add test for #13591 Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13591 Differential Revision: https://phabricator.haskell.org/D3470 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:27:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:27:41 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.07a1021e67e61ee03b4904ab689922b9@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge 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: | Differential Rev(s): Phab:D3472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge Comment: I added a section about this behavior in the [https://ghc.haskell.org/trac/ghc/wiki/Migration/8.2?version=21#KindgeneralizationandMonoLocalBinds GHC 8.2 migration guide]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:40:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:40:30 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.a7306515b205825029e770f518c51206@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3489 * milestone: => 8.2.1 Comment: It works in GHC 8.2 too! Commit b207b536ded40156f9adb168565ca78e1eef2c74 (Generalize kind of the (->) tycon) was what fixed it. I've added a regression test in Phab:D3489. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 15:47:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 15:47:34 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.18fd8ed24222e389d08f2aa8022e6c87@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 RyanGlScott): I wonder if this bug has the same underlying cause as #13500? The `[flags changed]` part makes me suspect so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 16:13:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 16:13:55 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.e79b6af053f5a5462a2e198547000e40@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 RyanGlScott): Ah, never mind. I tried using GHC HEAD with Phab:D3398 (the proposed fix for #13500) applied, but this bug was still present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 17:20:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 17:20:21 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.081f1f301a1ce50d458e646d949c04e0@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): tl;dr: Implementing this efficiently is non-obvious. But I think I found a way in the process of writing this comment. So I finally sat down this morning to fix this. But I can't think of a way to do so reasonably efficiently. The challenge is: Figure out when an Id which `hasNoBinding` is used with levity polymorphic arguments. The problem is that, in both the zonker and the desugarer (really, the only places to detect levity polymorphism problems), by the time we're looking at an Id, it's too late. We've lost all the context, including any type arguments (that is, `HsWrapper`s) that will instantiate the Id's levity polymorphic polytype. We could do the usual thing and accumulate arguments as we descend, but that seems fragile within the complexity of `HsSyn`, needing to deal with `HsWrap`, sections, and other horrors. We could check the desugared expression, but when? And how to do so without unwrapping all the `App`s that have accumulated? To solve that last question, we could add an extra return value to `dsExpr` stating when we're desugaring an applied `hasNoBinding` Id... but it's still unclear when to run the check. My most promising idea was to check whenever desugaring an `HsWrap`, figuring that a use of a polymorphic `hasNoBinding` Id would always be directly within an `HsWrap`. If we cleverly use composition to avoid `HsWrap foo (HsWrap bar ...)`, we can quickly detect when an `HsWrap` surrounds a `hasNoBinding` Id -- but only if the typechecker always puts such an Id in an `HsWrap`. Alas, since we have the lazy instantiation of `TypeApplications`, that's no longer true. If a polymorphic `hasNoBinding` Id is used as the argument to a higher-rank function, it's possible there will be no `HsWrap`. And insisting on instantiating `hasNoBinding` Ids right away means that these will no longer be usable with `TypeApplications`, which would be a shame. Perhaps a small tweak on the above idea will work: `dsExpr` gets an additional parameter saying whether or not the expr being desugared is immediately wrapped in an `HsWrap`. If we find a `HsVar` with a levity- polymorphic `hasNoBinding` Id inside and we're ''not'' in an `HsWrap`, issue an error. Additionally, every time we desugar an `HsWrap`, check if it's immediately wrapping a `hasNoBinding` id; if so, so the levity polymorphism check, using the type of the desugared expression to do the check. This might just work. It's heavier than I'd like, but not unreasonably so. I like it enough to implement. Thanks for listening. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 17:37:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 17:37:20 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.1f55e5b64c85f1a3d19a4696e59d053c@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Fantastic, I have to get the latest version -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 18:18:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 18:18:11 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.e8d3a5e15bc7ae9b40f4f2561bfd4a06@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D3490 Comment: Patch submitted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 18:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 18:20:55 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.92c34dfb46994b9a1b951c5d40e158d9@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh good. Needless to say, I found that my attempt at a patch didn't fix the issue and I didn't have a chance to look any farther. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 18:56:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 18:56:16 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.e9ec0ba1cfef6dd914fb1c7f5bdb4b7c@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 RyanGlScott): * cc: ezyang (added) Comment: I've identified commit 818760d68c0e5e4479a4f64fc863303ff5f23a3a (Fix #10923 by fingerprinting optimization level) as the culprit. cc'ing ezyang, the author of that commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 19:09:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 19:09:41 -0000 Subject: [GHC] #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs In-Reply-To: <050.5d31f2d5b2c6551b4fa57618c68943dd@haskell.org> References: <050.5d31f2d5b2c6551b4fa57618c68943dd@haskell.org> Message-ID: <065.8c5ec2b041dc4f6fb44adf74a7dae3b6@haskell.org> #13553: GHC 8.2.1 preprocesses __GLASGOW_HASKELL__ incorrectly with cpphs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) 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 RyanGlScott): * status: upstream => closed * resolution: => invalid Comment: An update: Malcolm Wallace released `cpphs-1.20.5`, which does not exhibit this problem anymore on //Linux//. On Windows, however, it still does. See https://github.com/malcolmwallace/cpphs/issues/11#issuecomment-294297975 I'm going to close this issue, as the ball is entirely in `cpphs`'s court when it comes to fixing the Windows issue. See https://github.com/malcolmwallace/cpphs/issues/11#issuecomment-294299458 for a patch which fixes the problem on `cpphs-1.20.5`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 19:47:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 19:47:23 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.b41ff1f820524db6daa9f845a940731c@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 ezyang): Makes sense: GHCi asks for no optimization, but the object files are optimized, so GHCi has no choice but to reinterpret the files. It would be an easy matter to revert this patch, but if we also want to keep #10923 fixed, we will need to have a discussion about what the intended semantics here are. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 21:15:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 21:15:13 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.6d3197bf0987f484d1a4cdab299efc30@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 George): Suppose I wanted ghci for optimization, specifically -O2, how would I specify that? See #13002 as mentioned above. Assuming I could specify it then ghci would simply load the compiled file, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 21:21:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 21:21:50 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.a9dbc4e5c219f26baa5c17ca6e0d99c5@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 ezyang): In principle, one ought to be able to pass `-O2` to GHCi to make this happen. However, it turns out you also must pass `-fobject-code`, at which the desired behavior is seen. {{{ ezyang at sabre:~$ ghc-8.2 -O2 -c A.hs ezyang at sabre:~$ ghc-8.2 -O2 -c A.hs -dynamic ezyang at sabre:~$ ghc-8.2 --interactive -O2 when making flags consistent: warning: -O conflicts with --interactive; -O ignored. GHCi, version 8.2.0.20170413: http://www.haskell.org/ghc/ :? for help Prelude> :load A.hs [1 of 1] Compiling A ( A.hs, interpreted ) [flags changed] Ok, modules loaded: A. *A> Leaving GHCi. ezyang at sabre:~$ ghc-8.2 --interactive -O2 -fobject-code GHCi, version 8.2.0.20170413: http://www.haskell.org/ghc/ :? for help Prelude> :load A.hs Ok, modules loaded: A (A.o). Prelude A> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 22:01:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 22:01:34 -0000 Subject: [GHC] #13606: GHCi segfaults on Windows with D3D code Message-ID: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> #13606: GHCi segfaults on Windows with D3D code ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Warning: this is about as Windows-specific of a bug as it possibly gets, since it requires the use of D3D. I noticed this when trying to run [https://github.com/jwvg0425/d3d11binding examples] from the `d3d11binding` library in GHCi, as they all failed. First, to conjure up the code needed for this: * `Main.hs`: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE ScopedTypeVariables #-} module Main (main) where import Data.Bits (Bits(..)) import Data.Int (Int32) import Data.Word (Word32) import Foreign.C.String (CString, peekCString, withCString, withCStringLen) import Foreign.Marshal.Alloc (alloca) import Foreign.Ptr (Ptr, castPtr, nullPtr) import Foreign.Storable (Storable(..)) import System.IO (IOMode(..), hGetContents, withFile) #if defined(i386_HOST_ARCH) # define WINDOWS_CCONV stdcall #elif defined(x86_64_HOST_ARCH) # define WINDOWS_CCONV ccall #else # error Unknown mingw32 arch #endif foreign import WINDOWS_CCONV "D3DCompile" c_d3dCompile :: Ptr () -> Word32 -> CString -> Ptr D3DShaderMacro -> Ptr ID3DInclude -> CString -> CString -> D3DCompileFlag -> D3DCompileEffectFlag -> Ptr (Ptr ID3DBlob) -> Ptr (Ptr ID3DBlob) -> IO HRESULT maybePoke :: (Storable a) => Maybe a -> (Ptr a -> IO b) -> IO b maybePoke Nothing proc = proc nullPtr maybePoke (Just m) proc = alloca $ \ptr -> do poke ptr m proc ptr maybeWithCString :: Maybe String -> (CString -> IO a) -> IO a maybeWithCString Nothing proc = proc nullPtr maybeWithCString (Just m) proc = withCString m proc type HRESULT = LONG data ID3DBlob = ID3DBlob data ID3DInclude = ID3DInclue type LONG = Int32 data D3DShaderMacro = D3DShaderMacro { _name :: String , _definition :: String } instance Storable D3DShaderMacro where sizeOf _ = 8 alignment _ = 8 peek ptr = do n <- peekByteOff ptr 0 d <- peekByteOff ptr 4 n' <- peekCString n d' <- peekCString d return $ D3DShaderMacro n' d' poke ptr (D3DShaderMacro n d) = do withCString n $ \n' -> withCString d $ \d' -> do pokeByteOff ptr 0 n' pokeByteOff ptr 4 d' type D3DCompileFlag = Word32 type D3DCompileEffectFlag = Word32 d3dCompileEnableStrictness :: D3DCompileFlag d3dCompileEnableStrictness = shift 1 11 d3dCompile :: String -> Maybe String -> Maybe D3DShaderMacro -> Ptr ID3DInclude -> Maybe String -> String -> [D3DCompileFlag] -> [D3DCompileEffectFlag] -> IO (Either (HRESULT, Ptr ID3DBlob) (Ptr ID3DBlob)) d3dCompile source sourceName defines pInclude entryPoint target compileFlags effectFlags = do withCStringLen source $ \(csource, len) -> withCString target $ \pTarget -> maybeWithCString sourceName $ \pSourceName -> maybePoke defines $ \pDefines -> maybeWithCString entryPoint $ \pEntryPoint -> alloca $ \ppCode -> alloca $ \ppErrorMsgs -> do let sFlag = foldl (.|.) 0 compileFlags let eFlag = foldl (.|.) 0 effectFlags putStrLn "Before d3dCompile" hr <- c_d3dCompile (castPtr csource) (fromIntegral len) pSourceName pDefines pInclude pEntryPoint pTarget sFlag eFlag ppCode ppErrorMsgs putStrLn "After d3dCompile" if hr < 0 then do pErrorMsgs <- peek ppErrorMsgs return $ Left (hr, pErrorMsgs) else do pCode <- peek ppCode return $ Right pCode d3dCompileFromFile :: String -> Maybe String -> Maybe D3DShaderMacro -> Ptr ID3DInclude -> Maybe String -> String -> [D3DCompileFlag] -> [D3DCompileEffectFlag] -> IO (Either (HRESULT, Ptr ID3DBlob) (Ptr ID3DBlob)) d3dCompileFromFile fileName sourceName defines pInclude entryPoint target compileFlags effectFlags = withFile fileName ReadMode $ \handle -> do contents <- hGetContents handle d3dCompile contents sourceName defines pInclude entryPoint target compileFlags effectFlags main :: IO () main = do _vb <- compileShaderFromFile "Triangle.fx" "VS" "vs_4_0" return () compileShaderFromFile :: String -> String -> String -> IO (Ptr ID3DBlob) compileShaderFromFile fileName entryPoint shaderModel = do Right res <- d3dCompileFromFile fileName Nothing Nothing nullPtr (Just entryPoint) shaderModel [d3dCompileEnableStrictness] [] return res }}} * `Triangle.fx` {{{ float4 VS( float4 Pos : POSITION ) : SV_POSITION { return Pos; } float4 PS( float4 Pos : SV_POSITION ) : SV_Target { return float4( 1.0f, 1.0f, 0.0f, 1.0f ); // Yellow, with Alpha = 1 } }}} Make sure that `Triangle.fx` is in the same directory as `Main.hs` when running this program. When compiled, this program works OK: {{{ $ C:\Users\RyanGlScott\Software\ghc-8.2.0.20170404\bin\ghc -lD3DCompiler Main.hs -fforce-recomp [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ .\Main.exe Before d3dCompile After d3dCompile }}} But with GHCi, it crashes: {{{ $ C:\Users\RyanGlScott\Software\ghc-8.2.0.20170404\bin\runghc -lD3DCompiler Main.hs Before d3dCompile Access violation in generated code when writing 0000000000000000 }}} I ran these tests on GHC 8.2.1, but I've also reproduced this bug in the past on GHC 8.0.2, so I don't think this is a new bug by any means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 22:53:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 22:53:15 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.fae4256be1a1c20e9b01362a5f0c8405@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f799df59d5f7e9fb683f2c71e25b65412afc53a7/ghc" f799df5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f799df59d5f7e9fb683f2c71e25b65412afc53a7" testsuite: Mark T13075 as broken due to #13075 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 23:29:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 23:29:22 -0000 Subject: [GHC] #13607: Panic with profiled compiler: Dynamic linker not initialised Message-ID: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> #13607: Panic with profiled compiler: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are several Trac tickets floating around which mention this panic, including: * #9868 (ghc: panic! Dynamic linker not initialised) * #10355 (Dynamic linker not initialised) * #10919 (ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised) * #13137 (Dynamic linker not initialised.) * #13531 (GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file) However, none seem particularly simple to reproduce. I have a (marginally) easier way to trigger this panic. You'll need the following: * A copy of GHC HEAD built with the `prof` flavor. For reference, I am using GHC HEAD built against 1f4fd37efac4795493677d5df81c83d22eac5f74. * A single package built with `cabal-install`. For simplicity, I used `random`: {{{ $ cabal install random-1.1 -w ~/Software/ghc3/inplace/bin/ghc-stage2 }}} Once it's installed, you'll need to learn `random`'s package ID, which can be done with `ghc-pkg`. For instance: {{{ 3$ ~/Software/ghc3/inplace/bin/ghc-pkg describe random name: random version: 1.1 id: random-1.1-Gnn89iTXDuaz90MEyLmyr ... }}} * You'll need these three Haskell files: {{{#!hs -- Foo.hs {-# LANGUAGE TemplateHaskell #-} module Foo where import Language.Haskell.TH foo :: Bool foo = $(conE 'True) }}} {{{#!hs -- Foo2.hs {-# LANGUAGE TemplateHaskell #-} module Foo2 where import Language.Haskell.TH foo2 = $(conE 'False) }}} {{{#!hs -- Bar.hs module Bar where import Foo import Foo2 bar :: () bar = foo `seq` foo2 `seq` () }}} Once you have all of these, you can trigger the bug by invoking GHC like so: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -fforce-recomp Bar.hs -j2 -package-id random-1.1-Gnn89iTXDuaz90MEyLmyr [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) : error: : can't load .so/.DLL for: libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so (libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so: cannot open shared object file: No such file or directory) [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170423 for x86_64-unknown-linux): Dynamic linker not initialised CallStack (from -prof): Linker.CAF () Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In case it's important, this is using 64-bit Linux. cc'ing angerman, who requested an easier way to reproduce this panic in https://ghc.haskell.org/trac/ghc/ticket/13137#comment:6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 23 23:30:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Apr 2017 23:30:25 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file In-Reply-To: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> References: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> Message-ID: <057.6ac9d62ca12f87c8aae1c2bdf2cb2c45@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13137, #9868, | Differential Rev(s): #10355, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13137, #9868, #10355 => #13137, #9868, #10355, #13607 Comment: See also #13607, which experiences the same panic with `-j2` (but using a profiled compiler). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 00:20:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 00:20:30 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.c737860e7d5af4893e95e169419256fa@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 George): present in 8.2.1-rc1 also -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 00:26:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 00:26:58 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.00620c820f0f36273d788324b757663e@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, are you still hoping to make `ImpredicativeTypes` work, or should you'd be closed as WONTFIX, or something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 00:28:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 00:28:57 -0000 Subject: [GHC] #11384: Error says to fix incorrect return type In-Reply-To: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> References: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> Message-ID: <066.c7545d4a251271ecdd67d46631633749@haskell.org> #11384: Error says to fix incorrect return type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: 8258 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Compiler (Type checker) * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 00:44:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 00:44:16 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.5f8d4fb18656c2de19262bedd67971a8@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 George): Thanks, that answers my question, you can do it as you described. Also you can specify those options in your .ghci file and that works as would be expected. So the question seems to be, if you have an object file compiled with flags different than the ghci flags (possibly the default ones) should ghci load it (as it did in 8.0.2) or should it compile the source into interpreted byte code and load that (as it does now) I think I prefer the old behavior, if you want interpreted byte code, remove the object file otherwise load will load your object file as is. However if we want to change this behavior to what it is currently I could live with that as long as the documentation is clear about the change and the current behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 02:18:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 02:18:58 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes Message-ID: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: QuasiQuotes | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12778 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the context in which the quasiquote is used would allow to build the later variant. However, GHC provides no way to grab the type that it expects of the quasiquote. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(parseExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_ = $(parseExp java " 0.0 ") in __ghc_qq_ }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback about the proposal meanwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 02:20:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 02:20:22 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.1b2e7c405c5d9122a4399d3a9c5a217d@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3003 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Would abandon this in favor of #13608. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 02:25:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 02:25:47 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.fbb6ad08b38d128df1be0ffb7670bd6b@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * owner: (none) => facundo.dominguez -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 02:31:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 02:31:52 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.b9edfa14fb01baee3fe1b32948acdd57@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -16,3 +16,2 @@ - Examining the context in which the quasiquote is used would allow to build - the later variant. However, GHC provides no way to grab the type that it - expects of the quasiquote. + Examining the type that GHC expects of the quasiquote would allow to build + the later variant. However, GHC provides no access to it. @@ -52,1 +51,1 @@ - to provide some feedback about the proposal meanwhile. + to provide some feedback meanwhile. New description: It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the type that GHC expects of the quasiquote would allow to build the later variant. However, GHC provides no access to it. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(parseExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_ = $(parseExp java " 0.0 ") in __ghc_qq_ }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback meanwhile. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 03:14:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 03:14:17 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.34ecc056ecdd17ebd240a8f878a14366@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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 ezyang): So, the motivating principle for the change in behavior for `ghc --make` is that, if you run a `ghc` command, the end result should always be the same as if you had run GHC on a clean project. This means that, yes, if the optimization level changed, you better recompile your files. I don't think this is necessarily what GHCi users are looking for. Without `-fobject-code`, optimization level doesn't matter at all and I can definitely see an argument for the semantics, "Please ignore my flags and use the on-disk compiled products as much as possible, so long as they accurately reflect the source code of my program." This interpretation is supported by the fact that `-O` flag doesn't do anything right now. (But, it is probable that `-fobject-code` should shunt us back into the `--make` style semantics.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 04:14:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 04:14:55 -0000 Subject: [GHC] #13551: Support DEPRECATED and WARNING pragmas on Template Haskell In-Reply-To: <046.8214fb888c851366791de7713707655e@haskell.org> References: <046.8214fb888c851366791de7713707655e@haskell.org> Message-ID: <061.89d4ff3fa6643db3279600eefce79ad7@haskell.org> #13551: Support DEPRECATED and WARNING pragmas on Template Haskell -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: feature request | Status: new Priority: low | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by utdemir): Just to have some fun, I will try to implement this myself. It will be the first time I'm trying to modify GHC and I am not sure if I will succeed. I plan to send a patch within this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 06:56:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 06:56:40 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.83ddf0db8488a77c1280e40b3a204fe2@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3003 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Here's a clarification as to the scope of this ticket. The example in the description shows that `addModFinalizer` only knows about variables bound in the source code, but not variables introduced by a splice. This ticket is about making the types of all variables queryable in `addModFinalizer`. Whereas #13608 is much less ambitious: it only seeks to name all quasiquotes so that the type of each quasiquote can be queried in `addModFinalizer`, without resolving this ticket in its entirety. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 07:31:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 07:31:47 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.adab3749532ade1eaa6ffe8f885341b9@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3003 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): In the attached Diff, Simon PJ admits to, understandably, being very confused by the original use case. The description in this ticket doesn't expatiate that, so here's a quick summary. inline-java defines the `java` quasiquoter, which stands for a call to a *typed* static Java method (with the antiquotation variables being the arguments): {{{ jadd :: Int32 -> Int32 -> IO Int32 jadd x y = do [java| { return $x + $y } |] }}} At compile time, we need to add somewhere the definition of this static method. Something like: {{{ public static int wrapperFun(int x, int y) { return x + y; } }}} At runtime, we need to call this method. Note that the user doesn't need to specify the Java types of antiquotation variables, nor the Java return type. Those are inferred from the types in the Haskell context of quasiquote (`Int32` maps to Java's `int`, `Bool` maps to `boolean` etc). We use `addModFinalizer` to compute the signature of the Java method at the very end of type checking a module, at a time when the full types of all the local variables in all contexts are known. Getting the type of antiquotation variables this way works fine in 8.0.2. But getting the expected return type of a quasiquotation and inferring a Java return type is not currently possible. So e.g. above, we can know that `x` and `y` are `int`, because we know that Haskell side `x` and `y` have type `Int32`. But we can't know that the return type is also `int`, because even if the quasiquote expansion is something like {{{ let result = in result }}} The type of `result` isn't available, even at the point where module finalizers are executed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:17:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:17:10 -0000 Subject: [GHC] #11514: Impredicativity is still sneaking in In-Reply-To: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> References: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> Message-ID: <062.10c4a8e663d4e1d5d33410ff32c32842@haskell.org> #11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | ImpredicativeTypes 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: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:17:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:17:23 -0000 Subject: [GHC] #10619: Order matters when type-checking In-Reply-To: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> References: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> Message-ID: <062.42c119ea9d7c10a7f7b7dfeaf813c400@haskell.org> #10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T10619 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:17:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:17:30 -0000 Subject: [GHC] #4281: Make impredicativity work properly In-Reply-To: <046.3b19a66bacdcb3f1860762e167ec6d54@haskell.org> References: <046.3b19a66bacdcb3f1860762e167ec6d54@haskell.org> Message-ID: <061.19f3eb96163db99874472a40f2d5e3ec@haskell.org> #4281: Make impredicativity work properly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: | ImpredicativeTypes 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: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:17:41 -0000 Subject: [GHC] #4295: Review higher-rank and impredicative types In-Reply-To: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> References: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> Message-ID: <061.5fb1f07cfad9777c46aabc0c2963d886@haskell.org> #4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 6.12.3 checker) | Keywords: Resolution: | ImpredicativeTypes 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: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:17:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:17:49 -0000 Subject: [GHC] #4347: Bug in unification of polymorphic and not-yet-polymorphic type In-Reply-To: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> References: <044.ff04e8084e7aca9611c332ca30665a4b@haskell.org> Message-ID: <059.588f8ceee7c383e5e8862a9a932df0a5@haskell.org> #4347: Bug in unification of polymorphic and not-yet-polymorphic type -------------------------------------+------------------------------------- Reporter: dolio | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.1 checker) | Keywords: Resolution: wontfix | ImpredicativeTypes Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:17:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:17:57 -0000 Subject: [GHC] #7264: Adding GHC's inferred type signatures to a working program can make it fail with Rank2Types In-Reply-To: <044.6f25d0ac1492e40e5523b819eeaf7327@haskell.org> References: <044.6f25d0ac1492e40e5523b819eeaf7327@haskell.org> Message-ID: <059.da9fbddf06c4691882053b9c182fafde@haskell.org> #7264: Adding GHC's inferred type signatures to a working program can make it fail with Rank2Types -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T7264 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:18:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:18:05 -0000 Subject: [GHC] #8808: ImpredicativeTypes type checking fails depending on syntax of arguments In-Reply-To: <044.1b0554fe8d821cf54101cba5a613a396@haskell.org> References: <044.1b0554fe8d821cf54101cba5a613a396@haskell.org> Message-ID: <059.c9f36bc473ccc83747c7064c40b0b8f3@haskell.org> #8808: ImpredicativeTypes type checking fails depending on syntax of arguments -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 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 simonpj): * keywords: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:18:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:18:13 -0000 Subject: [GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes In-Reply-To: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> References: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> Message-ID: <062.33d642ae25b80e1c24d2f7823a4e70a3@haskell.org> #9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | ImpredicativeTypes 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: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:18:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:18:35 -0000 Subject: [GHC] #10709: Using ($) allows sneaky impredicativity on its left In-Reply-To: <047.69b727f09e59d3453594f8d03a6e522d@haskell.org> References: <047.69b727f09e59d3453594f8d03a6e522d@haskell.org> Message-ID: <062.4c6624b8e714a615f4617cf1f04d7596@haskell.org> #10709: Using ($) allows sneaky impredicativity on its left -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ImpredicativeTypes 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: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:19:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:19:05 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.298e465f2cfe1afa1b3519f9cb1eb640@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Leave it open as a useful test case. Alejandro is still thinking about impredicativity, making some progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:20:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:20:59 -0000 Subject: [GHC] #4295: Review higher-rank and impredicative types In-Reply-To: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> References: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> Message-ID: <061.d5d22f011e8027a2df1081533a66b95d@haskell.org> #4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 6.12.3 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:25:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:25:30 -0000 Subject: [GHC] #1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD In-Reply-To: <044.214a91fada19b9f526f1cce3318d683b@haskell.org> References: <044.214a91fada19b9f526f1cce3318d683b@haskell.org> Message-ID: <059.203482a937a7c06c0293130e07b18652@haskell.org> #1330: Impredicativity bug: Church2 test gives a rather confusing error with the HEAD -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.7 checker) | Keywords: Resolution: | TypeErrorMessages, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Church2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeErrorMessages => TypeErrorMessages, ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:25:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:25:55 -0000 Subject: [GHC] #11384: Error says to fix incorrect return type In-Reply-To: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> References: <051.535b2ac8e0caff122ec926cb161b298b@haskell.org> Message-ID: <066.e7c515972c021225850e6cbd857bacf7@haskell.org> #11384: Error says to fix incorrect return type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: GADTs, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: 8258 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: GADTs => GADTs, TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:27:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:27:34 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.495ccbd0c8d55997b5d8efa5d32b00f2@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 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): Whether or not it is the "right" behaviour, it would be good if the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:30:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:30:53 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.64b5871560d826d01c805c2e62d16185@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you fill in the details? What does `parseExp` do? What does the finaliser do? What if the type mentions in-scope type variables (existentially or lambda bound)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 08:37:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 08:37:06 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.3ea95acba10bf7d1b87301d2e303ca07@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3003 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's helpful. So you can do it today, like this: {{{ jadd :: Int32 -> Int32 -> IO Int32 jadd x y = let r = [java| { return $x + $y } |] in r }}} But that's a bit painful to write. All this `addModFinalizer` stuff needs careful documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 09:52:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 09:52:24 -0000 Subject: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread In-Reply-To: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> References: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> Message-ID: <057.441a3c524a950e05e11bf280f62ace8a@haskell.org> #5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): A few of us at nstack have been getting this error lately with ghc 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 10:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 10:07:01 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.37ad67f7f13cb4749e63a05cf585f048@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3003 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:9 simonpj]: > That's helpful. So you can do it today, [...] but that's a bit painful to write. That's right. And not something I'm keen to ask my users to have to write. #13608 proposes to make the exact style of your example (giving a name to quasiquote results) the default desugaring for all quasiquotes. The semantics I'd expect for `addModFinalizer` is: * Runs ''after'' all variables everywhere in the module have a type (including after TH expansion). * Like any `Q` action, the finalizer is allowed to perform I/O. * ''Any'' variable that is in context of the finalizer at the creation site can have its type reified. * The order of execution of each finalizer, if there are several, is undefined. This ticket proposes to extend the set of reifiable variables to include in addition: * variables in the scope of the `Q` action that created the finalizer. Not all of these will have types by the time the finalizer runs, because some variables might never be spliced in. But those that do, should have their type available in the finalizer. #13608 is a much more modest change in comparison. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 10:37:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 10:37:31 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas for TH-less GHCs no longer ignored in GHC 8.2.1 Message-ID: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> #13609: regression: `ANN` pragmas for TH-less GHCs no longer ignored in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- Consider {{{#!hs module M where {-# ANN myId "HLint: ignore" #-} myId :: a -> a myId x = x }}} GHC 8.0.2 would simply ignore them: {{{ $ ghc-8.0.2 -c M.hs M.hs:3:1: warning: Ignoring ANN annotation, because this is a stage-1 compiler or doesn't support GHCi }}} however, with a recent GHC 8.2 snapshot this just fails with {{{ $ ghc-8.2 -c M.hs ghc: this operation requires -fexternal-interpreter }}} This is a serious problem because `hlint` annotations are quite popular, and this would require us to retrofit `other-extensions: TemplateHaskell` into the meta-data of quite a few packages on Hackage to declare that a package no longer works with a TH-less GHC (which would basically mean that ports of GHC such as the one for AIX that don't support TH will become very inconvenient to use and require to pester package authors to explicitly guard `ANN` pragmas with CPP... which I'm not looking forward to ;-) ). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 10:40:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 10:40:31 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 (was: regression: `ANN` pragmas for TH-less GHCs no longer ignored in GHC 8.2.1) In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.aba60bcc2ebcbb07a0525acd7617c999@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 10:51:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 10:51:41 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.89801f2915086e081b902a7466a9bb90@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 hvr): And btw, `-fexternal-interpreter` doesn't work on AIX either, for the same reason there's no GHCi or TH support: `loadArchive` doesn't support XCOFF (which is even worse than Windows' COFF flavour - i.e. not going to happen), and adding support for the dynamic linker on AIX isn't going to happen any time soon either (partly because XCOFF imposes quite a lot of limitations one would have to workaround). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 11:36:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 11:36:52 -0000 Subject: [GHC] #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is In-Reply-To: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> References: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> Message-ID: <060.7be365784c1ebd1c077c425417688058@haskell.org> #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: libraries | Version: 8.2.1-rc2 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 11:43:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 11:43:50 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.526925d78f8e5582b2499e9e32bb0f0d@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): > What does parseExp do? In the case of the `java` quasiquoter: * it adds a finalizer which generates the java method to call, e.g. `Object fresh_name() { return 0.0; }` * it inserts at the quasiquote location some foreign calls to have the generated java method invoked, and the result marshaled to Haskell. > What if the type mentions in-scope type variables (existentially or lambda bound)? In that case, the variables will likely show up in the type returned by `reify`. We don't care much about that case, as the user of inline-java would be asked to add enough of a type signature to provide as much information as necessary to infer a reasonable type in java. Also, if you want to explore it, there would be an alternative design where it is possible to avoid introducing the variable `__ghc_qq_`. This would involve extending the `Quasi` monad with a method {{{ qTypeOfCurrentQuasiQuote :: m TH.Type }}} which must be invoked in a module finalizer and yields the type of the quasiquote, which would require some interaction with the typechecker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 12:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 12:24:14 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.1155395a395074bc5a11476d0767d7c6@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is just fine for type inference, but it's bad for kind inference. I don't understand this. With `MonoLocalBinds` we don't generalise and all is well, no? > So, here is the characterization of the infelicity in singletons: if a local function's type would be different depending on the presence of MonoLocalBinds, then it needs a type signature in order for singletons to work. I don't understand this either. Could you give a small example? Looking at the `Bug3.hs` it looks as if there ''is'' a type signature, generated by Template Haskell. Perhaps you are saying that this type signature is insufficiently kind-generalised? In which case shouldn't the TH code simply add the necessary kind generalisation? > I'm going to close the ticket as a dup of #13555. But #13555's conclusion was "not a bug". So is this not a bug goo? If so what about the singletons library? Very confused! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 13:39:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 13:39:43 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.b82fb88947fb217224ede896bae23631@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | 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): Phab:D3472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with b73b89c9cf8ebffd8438fd48844cffe78e59de48. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 13:46:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 13:46:46 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.e2db390517a80a8972368e97143e0f51@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: shlevy (added) Comment: Commit 27f79255634d9789f367273504545c1ebfad90a0 (Allow use of the external interpreter in stage1) is the culprit. cc'ing shlevy, the author. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 13:48:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 13:48:30 -0000 Subject: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread In-Reply-To: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> References: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> Message-ID: <057.11f6ba4865eb5e01de629ba2997fa8b1@haskell.org> #5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.4.2 => 8.2.2 Comment: We should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 13:49:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 13:49:57 -0000 Subject: [GHC] #13593: Unexpected behavior from Data.List.groupBy In-Reply-To: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> References: <042.8a45dc7e5b117613ad06bfb66c8f24b5@haskell.org> Message-ID: <057.e90aaa887774a8258f73de5f8fa1a001@haskell.org> #13593: Unexpected behavior from Data.List.groupBy -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I haven't read these comments through to their conclusion but perhaps someone could offer a patch implementing what was agreed upon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 13:54:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 13:54:11 -0000 Subject: [GHC] #13551: Support DEPRECATED and WARNING pragmas on Template Haskell In-Reply-To: <046.8214fb888c851366791de7713707655e@haskell.org> References: <046.8214fb888c851366791de7713707655e@haskell.org> Message-ID: <061.52e2d69b9677e0485c78f3d4c7043f0b@haskell.org> #13551: Support DEPRECATED and WARNING pragmas on Template Haskell -------------------------------------+------------------------------------- Reporter: utdemir | Owner: (none) Type: feature request | Status: new Priority: low | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yay, great! Let me know if you get stuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 13:58:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 13:58:23 -0000 Subject: [GHC] #13316: Bad inlining cascade leads to slow optimisation In-Reply-To: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> References: <046.06d19c6b686ed4c069a0d4be72a57a44@haskell.org> Message-ID: <061.fb7709877b31a8da7b72bf989ad7779a@haskell.org> #13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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): I've just discovered that this inline cascade happens in a module of GHC itself: `StgCmmBind`. Here's the output if you compile with `-fmax- simplifier-iterations=8`: {{{ WARNING: file compiler/simplCore/SimplCore.hs, line 700 Simplifier bailing out after 8 iterations [2478, 266, 16, 1, 1, 1, 2, 1] Size = {terms: 2,793, types: 8,470, coercions: 529, joins: 4/77} WARNING: file compiler/simplCore/SimplCore.hs, line 700 Simplifier bailing out after 8 iterations [990, 166, 9, 4, 2, 4, 2, 3] Size = {terms: 4,605, types: 13,273, coercions: 302, joins: 21/138} }}} The cascade of iterations with only one or two ticks each time comes from exactly the kind of nested data constructor applications in the description. To be specific, in `closureCodeBody`, at some point we see code like this, and those `wild` variables get inlined one by one: {{{ let { wild1_so1n :: CLabel [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] wild1_so1n = closureLocalEntryLabel ipv_anWK cl_info_aegJ } in let { wild1_so1m :: CmmLit [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] wild1_so1m = CmmExpr.CmmLabel wild1_so1n } in let { wild1_so1l :: CmmExpr [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] wild1_so1l = CmmExpr.CmmLit wild1_so1m } in let { wild1_so1k :: CmmNode hoopl-3.10.2.2:Compiler.Hoopl.Block.O hoopl-3.10.2.2:Compiler.Hoopl.Block.C [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 70}] wild1_so1k = CmmNode.CmmCall @ hoopl-3.10.2.2:Compiler.Hoopl.Block.O @ hoopl-3.10.2.2:Compiler.Hoopl.Block.C @~ (_N :: (hoopl-3.10.2.2:Compiler.Hoopl.Block.O :: *) ghc-prim-0.5.0.0:GHC.Prim.~# (hoopl-3.10.2.2:Compiler.Hoopl.Block.O :: *)) @~ (_N :: (hoopl-3.10.2.2:Compiler.Hoopl.Block.C :: *) ghc-prim-0.5.0.0:GHC.Prim.~# (hoopl-3.10.2.2:Compiler.Hoopl.Block.C :: *)) wild1_so1l (GHC.Base.Nothing @ BlockId) ww2_ao10 ww1_ao0Z MkGraph.mkFinalCall1 updfr_off_alrO } in case wild_ao13 of wild2_ao15 { __DEFAULT -> OrdList.Snoc @ CgStmt wild2_ao15 (MkGraph.CgLast wild1_so1k); OrdList.One a1_ao1b -> OrdList.Cons @ CgStmt a1_ao1b (OrdList.One @ CgStmt (MkGraph.CgLast wild1_so1k)) }; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 14:31:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 14:31:08 -0000 Subject: [GHC] #13404: Derive instances for classes with associated types In-Reply-To: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> References: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> Message-ID: <066.7d3cda7753b0aefd39490e3f5fbc600c@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 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: #2721, #4083, | Differential Rev(s): #8165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: #4083 => #2721, #4083, #8165 * milestone: => 8.2.1 Comment: You're in luck, because this works in GHC 8.2. (In fact, I'll mark this as a duplicate of #2721/#8165.) This is the what the derived `Representable PAIR` instance is in the first example: {{{#!hs instance Representable PAIR where type Rep PAIR = Rep Pair tabulate = coerce @(forall (a :: Type). (Rep Pair -> a) -> Pair a) @(forall (a :: Type). (Rep PAIR -> a) -> PAIR a) tabulate index = coerce @(forall (a :: Type). Pair a -> Rep Pair -> a) @(forall (a :: Type). PAIR a -> Rep PAIR -> a) index }}} And in the second example: {{{#!hs instance (Representable h, Representable g, Representable f) => Representable (P f g h) where type Rep (P f g h) = Rep (Product (f · (g · f)) (h · (f · g))) tabulate = coerce @(forall (a :: Type). (Rep Product (·) f (·) g f (·) h (·) f g -> a) -> Product (·) f (·) g f (·) h (·) f g a) @(forall (a :: Type). (Rep P f g h -> a) -> P f g h a) tabulate index = coerce @(forall (a :: Type). Product (·) f (·) g f (·) h (·) f g a -> Rep Product (·) f (·) g f (·) h (·) f g -> a) @(forall (a :: Type). P f g h a -> Rep P f g h -> a) index }}} As you can see, the algorithm works by taking the newtype's underlying type and sticking the associate type family in front of it, so you get `type Rep PAIR = Rep Pair` and `type Rep (P f g h) = Rep (Product (f · (g · f)) (h · (f · g)))` (which expand to `Bool` and `Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g))`, respectively). This requires `UndecidableInstances` to use, but then again, so does a bunch of other code that involves type families ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 14:48:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 14:48:47 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.10a5f92cf53360c49ebba87aeede51f7@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ab27fdcfe26759f3e4cd7e2105e7e7e83e269e48/ghc" ab27fdcf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab27fdcfe26759f3e4cd7e2105e7e7e83e269e48" Add regression test for #13603 Summary: Commit b207b536ded40156f9adb168565ca78e1eef2c74 (#11714) happened to fix #13603 as well. Let's add a regression test so that it stays fixed. Test Plan: make test TEST=T13603 Reviewers: bgamari, austin, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13603 Differential Revision: https://phabricator.haskell.org/D3489 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 14:48:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 14:48:48 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.668ecffe2163b167e7a0dab076f5dc6f@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ab27fdcfe26759f3e4cd7e2105e7e7e83e269e48/ghc" ab27fdcf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab27fdcfe26759f3e4cd7e2105e7e7e83e269e48" Add regression test for #13603 Summary: Commit b207b536ded40156f9adb168565ca78e1eef2c74 (#11714) happened to fix #13603 as well. Let's add a regression test so that it stays fixed. Test Plan: make test TEST=T13603 Reviewers: bgamari, austin, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13603 Differential Revision: https://phabricator.haskell.org/D3489 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 14:50:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 14:50:04 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.fab5f6916d1419f808360f45b0b412aa@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13603 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T13603 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 15:02:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 15:02:08 -0000 Subject: [GHC] #13404: Derive instances for classes with associated types In-Reply-To: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> References: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> Message-ID: <066.4c54bd277fac1e6f0e13a2f483f7f4eb@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 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: #2721, #4083, | Differential Rev(s): #8165 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Does the user manual explain this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 15:03:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 15:03:42 -0000 Subject: [GHC] #13404: Derive instances for classes with associated types In-Reply-To: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> References: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> Message-ID: <066.88c34faf2996754b93b16c3ecd908acb@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 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: #2721, #4083, | Differential Rev(s): #8165 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 simonpj]: > Does the user manual explain this? Yes, see http://git.haskell.org/ghc.git/blob/ab27fdcfe26759f3e4cd7e2105e7e7e83e269e48:/docs/users_guide/glasgow_exts.rst#l4324 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 15:35:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 15:35:04 -0000 Subject: [GHC] #13404: Derive instances for classes with associated types In-Reply-To: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> References: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> Message-ID: <066.31910c8a3371063f241cc34b78a7437d@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 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: #2721, #4083, | Differential Rev(s): #8165 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes!! Jolly good -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 15:45:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 15:45:40 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.cebc93fc5f03c84260fc69b6356ca20f@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 shlevy): Ack, will look at it ASAP -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 16:53:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 16:53:53 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.5ec42ea212d65990e05be9c119b090ae@haskell.org> #8996: mark more things as const in C codegen -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (CodeGen) | 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:D3481 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b68697e579d38ca29c2b84377dc2affa04659a28/ghc" b68697e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b68697e579d38ca29c2b84377dc2affa04659a28" compiler/cmm/PprC.hs: constify labels in .rodata Consider one-line module module B (v) where v = "hello" in -fvia-C mode it generates code like static char gibberish_str[] = "hello"; It resides in data section (precious resource on ia64!). The patch switches genrator to emit: static const char gibberish_str[] = "hello"; Other types if symbols that gained 'const' qualifier are: - info tables (from haskell and CMM) - static reference tables (from haskell and CMM) Cleanups along the way: - fixed info tables defined in .cmm to reside in .rodata - split out closure declaration into 'IC_' / 'EC_' - added label declaration (based on label type) right before each label definition (based on section type) so that C compiler could check if declaration and definition matches at definition site. Signed-off-by: Sergei Trofimovich Test Plan: ran testsuite on unregisterised x86_64 compiler Reviewers: simonmar, ezyang, austin, bgamari, erikd Reviewed By: bgamari, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #8996 Differential Revision: https://phabricator.haskell.org/D3481 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 16:54:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 16:54:09 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.df8cc595951a0ad553f493aea17c4855@haskell.org> #8996: mark more things as const in C codegen -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.8.2 (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:D3481 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 16:54:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 16:54:45 -0000 Subject: [GHC] #8996: mark more things as const in C codegen In-Reply-To: <045.8247ddb295df41a75076302911e81bc2@haskell.org> References: <045.8247ddb295df41a75076302911e81bc2@haskell.org> Message-ID: <060.b7057aa1664b7385436f4ec2738acb63@haskell.org> #8996: mark more things as const in C codegen -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.8.2 (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:D3481 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): trofi, feel free to reopen if you know of anything else that hasn't yet been marked as const. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 16:59:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 16:59:37 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types Message-ID: <046.43439217ad237220365df4287ab639e3@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- I wrote this code: {{{ {-# LANGUAGE MagicHash #-} import GHC.Prim import GHC.Types main = do let primDouble = 0.42## :: Double# let double = 0.42 :: Double IO (\s -> mkWeakNoFinalizer# double () s) }}} and I get this error message: {{{ WeakDouble.hs:8:15: error: • Couldn't match a lifted type with an unlifted type Expected type: (# State# RealWorld, Weak# () #) Actual type: (# State# RealWorld, Weak# () #) • In the expression: mkWeakNoFinalizer# double () s In the first argument of ‘IO’, namely ‘(\ s -> mkWeakNoFinalizer# double () s)’ In a stmt of a 'do' block: IO (\ s -> mkWeakNoFinalizer# double () s) }}} with `-fprint-explicit-kinds`. (Without the flag, it looks the same, but tells me to use this flag…). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 17:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 17:02:44 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.24841646cf23191d09e305520a72f901@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ah, the problem is that `IO`’s type expects the second component of the tuple to be lifted, but `Weak#` is not. So the code is indeed bogus, but the error message is not very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 17:11:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 17:11:10 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# Message-ID: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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: -------------------------------------+------------------------------------- This code segfaults: {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} import GHC.Prim import GHC.Types main = do let local = () let null = 0## :: Word# let triple = (# local, null, null #) IO (\s -> case mkWeakNoFinalizer# triple () s of (# s, r #) -> (# s, () #)) }}} The problem is that `mkWeakNoFinalizer#` has a levity polymorphic type for its first argument, but the implementation really requires the first argument to be a pointer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 18:25:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 18:25:48 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.be00cfc0782d64b8964742b35dee8e2e@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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 RyanGlScott): Is this addressed by Phab:D3490? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 18:27:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 18:27:04 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.6e74c88866ac4fd443649a071073d0a1@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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 nomeata): I don’t think so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 18:52:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 18:52:12 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.9573c02a6f9a7e252cadce6b2e21379e@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I guess the question is this: should `-fprint-explicit-kinds` print unboxed tuple types in prefix so that the levity arguments are displayed? I think: no. But perhaps `-fprint-explicit-runtime-reps` should, and GHC should be taught to tell the user about this flag instead of `-fprint- explicit-kinds` in this scenario. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 19:30:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 19:30:17 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.27a1621e118af886c685ad1e829cf635@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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 goldfire): Neither do I. Though what guarantees do we provide when a user writes the `IO` constructor explicitly? This is tantamount to `unsafePerformIO`, is it not? While I conjecture that the segfault is possible without unsafe features, this test case isn't terribly convincing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 19:53:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 19:53:38 -0000 Subject: [GHC] #13612: ghc.exe: panic! (the 'impossible' happened) Message-ID: <046.a206ea24023269e74c866fb6b6d630cd@haskell.org> #13612: ghc.exe: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hmemcpy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Full output: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] n_a1qA :: t_a1qz[tau:1] (CHoleCan: n)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This failed on a trivial (albeit incorrect) "Hello world" code, while trying to execute it with stack: **stack Main.hs** The code file is attached. Note that this error happens when it incorrectly specifies the non- existing value **n** (instead of **name**) in the last expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 19:53:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 19:53:54 -0000 Subject: [GHC] #13612: ghc.exe: panic! (the 'impossible' happened) In-Reply-To: <046.a206ea24023269e74c866fb6b6d630cd@haskell.org> References: <046.a206ea24023269e74c866fb6b6d630cd@haskell.org> Message-ID: <061.6a6b7a9850d0f466372a602b908bc5d0@haskell.org> #13612: ghc.exe: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hmemcpy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hmemcpy): * Attachment "Main.hs" added. Offending code file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 20:17:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 20:17:29 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.333486b41f211fed0c404e8fd736da45@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low Comment: I am not sure if printing type prefixes would have improved manners. What would it say? Maybe {{{ Expected type: (#,#) VoidRep LiftedRep (State# RealWorld) (Weak# ()) Actual type: (#,#) VoidRep PrimRep (State# RealWorld) (Weak# ()) }}} But the “actual type” is not well-kinded; it cannot really be the “actual type” of anything. So it seems that something went wrong earlier during type inference? I guess something along these lines would have been more helpful: {{{ WeakDouble.hs:8:15: error: • Couldn't match a lifted type with an unlifted type Expected type representation: LiftedRep Actual type representation: PrimRep • In the second element of the unlifted tuple • In the type of the expression: mkWeakNoFinalizer# double () s }}} Anyways; this was not triggered by writing real code, so I’ll lower the priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 20:26:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 20:26:14 -0000 Subject: [GHC] #13613: Simplify fixIO Message-ID: <045.c07b977628342bd8755457ac2cab62eb@haskell.org> #13613: Simplify fixIO -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Now that we have `noDuplicate#`, I think we can make `fixIO` much simpler, and perhaps also faster, using something like what we do for `ST`. {{{#!hs data Res a = Res (# State# RealWorld, a #) fixIO f = IO $ \s -> let Res r@(# _s', a #) = unIO (noDuplicate >> f a) s in r }}} If `f` forks an `IO` thread demanding `a`, the `noDuplicate` should ensure that the computation is not re-entered, and the thread should wait for the main computation to complete. So I believe, anyway. The comment about eager blackholing here is a bit vague and doesn't give an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 20:27:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 20:27:26 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.c0f3432f1664bc4c32ab2a695d1fd660@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) 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 nomeata): > This is tantamount to unsafePerformIO, is it not? Not quite, I am not producing a `RealWorld#` token out of thin air. Normal user code calls `mkWeak#` via `mkWeak` in `GHC.Weak`, which is not levity polymorphic. But there is one use of `mkWeak#` in the libraries that seems to use a different `TypeRep`: {{{ addForeignPtrConcFinalizer_ :: ForeignPtrContents -> IO () -> IO () addForeignPtrConcFinalizer_ (PlainForeignPtr r) finalizer = do noFinalizers <- insertHaskellFinalizer r finalizer if noFinalizers then IO $ \s -> case r of { IORef (STRef r#) -> case mkWeak# r# () (unIO $ foreignPtrFinalizer r) s of { (# s1, _ #) -> (# s1, () #) }} else return () }}} The `r#` here is of type `MutVar# s a`, which is `UnliftedRep`; there are similar calls in the modules for for `MVar` and `IORef`. So this is a use case where we want levity polymorphism that allows any *boxed* type, whether lifted or not. Or, the easy way out, is to have two copies of the `mkWeak#` primop, one for `LiftedRep` and one for `UnliftedRep`. They could use the same code and info-pointer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 21:53:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 21:53:45 -0000 Subject: [GHC] #13606: GHCi segfaults on Windows with D3D code In-Reply-To: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> References: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> Message-ID: <065.9b1b6274f2c3918dd7f231c0828e1a84@haskell.org> #13606: GHCi segfaults on Windows with D3D code ----------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12499 #12498 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * related: => #12499 #12498 Comment: This has to do with the fact that we don't recognize import libraries that are named anything other than ".dll.a" or ".lib". Unfortunately, msys2 names all import libraries that they generate using `gendef` with a `.a` extension. It's currently trying to treat the library as a normal archive, resulting in the segfault because there's no executable code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 22:01:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 22:01:59 -0000 Subject: [GHC] #13612: ghc.exe: panic! (the 'impossible' happened) In-Reply-To: <046.a206ea24023269e74c866fb6b6d630cd@haskell.org> References: <046.a206ea24023269e74c866fb6b6d630cd@haskell.org> Message-ID: <061.c037549b68a0dd4a72a1c2fb433a131c@haskell.org> #13612: ghc.exe: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hmemcpy | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the report. This is a duplicate of #13106, which will be fixed in GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 22:27:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 22:27:35 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.487b00729a8f2bf98d03d1aa59ebc79a@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This may be fixed by the fix to #11198. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 24 22:27:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Apr 2017 22:27:57 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.2573084a38423b964c99391376daa39d@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Another case (possibly): #13610. -- Ticket URL: GHC The Glasgow Haskell Compiler From matthew at wellquite.org Tue Apr 25 00:27:05 2017 From: matthew at wellquite.org (matthew) Date: Tue, 25 Apr 2017 02:27:05 +0200 Subject: =?utf-8?B?4piRaXQncyBuZXZlciB0b28gbGF0ZQ==?= Message-ID: <1665812804.20170425032705@wellquite.org> Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hey! It's never too late to read some interesting info here http://www.mrphuchoi.com/pool.php?4243 matthew [...] Content analysis details: (6.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [14.186.146.6 listed in zen.spamhaus.org] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL 1.0 RCVD_IN_CSS RBL: Received via a relay in Spamhaus CSS 0.0 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.net/Why?s=mfrom;id=matthew%40wellquite.org;ip=14.186.146.6;r=mail.haskell.org] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4967] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "matthew" Subject: ?it's never too late Date: Tue, 25 Apr 2017 02:27:05 +0200 Size: 997 URL: From ghc-devs at haskell.org Tue Apr 25 00:28:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 00:28:49 -0000 Subject: [GHC] #13610: Unhelpful error messages about lifted and unlifted types In-Reply-To: <046.43439217ad237220365df4287ab639e3@haskell.org> References: <046.43439217ad237220365df4287ab639e3@haskell.org> Message-ID: <061.5cc57a7b0fd949ebf9192a096ef46b33@haskell.org> #13610: Unhelpful error messages about lifted and unlifted types -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 00:29:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 00:29:38 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.db61cfd37ac01e6208c0017a79d91aee@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: 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 Tue Apr 25 01:54:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 01:54:44 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.8a7b5ca2ff37dbacde8d3012e26621d4@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: It would be nice if we could get this fixed for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 04:32:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 04:32:14 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.67ab2c8509841a8a8df978bb140e7342@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The first weird thing to notice about this problem is that 45d9a15c4b85a2ed89579106bdafd84accf2cb39 is all about LHSes of `RULES`, but there ''aren't any'' rules in the test module. So something seems to have gone wrong with one of the "knock on" changes. Compiling before and after with `-v3` indicates that the simplifier iteration immediately after float out takes ''much'' longer, and produces somewhat more coercions. That iteration takes many times longer than any other. Most of the coercions, before and after, go away after that iteration, stabilizing quickly at 19. Surprisingly, `-dverbose-core2core` looks exactly the same before and after that commit, suggesting something went funny with the size calculations, although I can't see how. In HEAD, the number of coercions never goes up above 19. Furthermore, the time problem has ''moved''. Now, the long iteration is the very first one after desugaring! Ugh. I haven't yet tried to find where the time shift took place. But the fact that there ''was'' one makes me suspect that the new implementation could have accidentally strictified something it shouldn't have. I don't understand what's going on well enough to know what. Perhaps the fact that a couple pure functions have turned monadic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 06:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 06:14:26 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.184d4fc3e5e7db3cd5a49cd1971ebea0@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 06:26:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 06:26:20 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.f918e687fd9060af2ed6bf7d9b3b9027@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors 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 kosmikus): This is a problem for me as well, in https://github.com/kosmikus/records- sop/blob/13e3f76b511fd11f7e3b120d696a0a136cccb2fb/tests/Examples.hs#L163-L172 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 07:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 07:19:16 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.f207825e8626a7eca99d54feb6aa71b5@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): > In HEAD [...] the time problem has moved. Now, the long iteration is the very first one after desugaring May it have anything to do with the "early inlining" changes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 08:09:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 08:09:25 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.4d574ec850294463ba35130be189f5ec@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors 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): Works ok in HEAD. I don't have an 8.2 branch to hand to check. Can someone add this as a regression test, pls? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 08:25:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 08:25:17 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.19bd3ead649aca95c7e90662f619ecd1@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: > Though what guarantees do we provide when a user writes the IO constructor explicitly? This is tantamount to unsafePerformIO, is it not? You might get sequencing or concurrency errors, but not seg-faults. > But there is one use of mkWeak# in the libraries that seems to use a different TypeRep Actually ''all'' the uses in `base` are on `UnliftedRep` except the single use in `GHC.Weak.mkWeak`. > Or, the easy way out, is to have two copies of the mkWeak# primop, one for LiftedRep and one for UnliftedRep. Yes, let's do that. In principle we could further structure `RuntimeRep` to have {{{ data RuntimeRep = IntRep | WordRep | PtrRep Liftedness data Liftedness = Lifted | Unlifted }}} and now we could have polymorphism over liftedness, but I just don't think it's worth it. BTW I think that (like `dataToTag#`) `mkWeak#` probably requires its argument to be evaluated. (I don't think it does and eval itself, though perhaps it should.) Reason: `mkWeak#` should not make a weak pointer to a thunk. I think. So I am pretty suspicious of this `GHC.Weak.mkWeak`: {{{ mkWeak key val (Just (IO finalizer)) = IO $ \s -> case mkWeak# key val finalizer s of { (# s1, w #) -> (# s1, Weak w #) } }}} Looks wrong to me; e.g. `mkWeak# (head xs)`? Copying Simon M. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 08:27:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 08:27:31 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.6ae9878bfd05e344193f5557ac41bfec@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages 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 simonpj): * keywords: TypeInType, ErrorMessages => TypeInType, TypeErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 08:27:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 08:27:55 -0000 Subject: [GHC] #11672: Poor error message In-Reply-To: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> References: <049.cc2f48c705b5aa7c4431fbd88245f608@haskell.org> Message-ID: <064.6d20dcba7f31573443ed7be93b24e154@haskell.org> #11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | TypeErrorMessages, 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: ErrorMessages, TypeInType => TypeErrorMessages, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 09:27:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 09:27:02 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.f54ddde11549553e17c01f47fcb89688@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:6 simonpj]: > and now we could have polymorphism over liftedness, but I just don't think it's worth it. Can it be added in the future if deemed useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 09:29:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 09:29:55 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.95d2b1aed5bf0f6c217faf2cff07a771@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Duplicating the primop is an ugly solution to something that isn't really a problem IMO. There are lots of ways to segfault using primops! We should just document how to use them safely. If we could fix the type system to give an accurate type to this then fine, but otherwise I suggest we just improve the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 10:46:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 10:46:08 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.9c4cbe26a3a6546ea41d2507fa2e9a15@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors 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 kosmikus): Simon, thanks a lot for testing with HEAD. I can confirm that my code works with HEAD (8.3.20170422) as well, but it still crashes with 8.2.0.20170422. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 10:55:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 10:55:45 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.41941a75701fba669bc278fcf6111756@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know roughly what is happening here. * When checking kinds we call `solveEqualities` which immediately reports type errors * The offending kind-equality constraint in this case has a `TypeEqOrigin` whose `uo_thing` is built by `checkExpectedKind`. * That `uo_thing` is printed as part of the error message. Alas it contains a type (not a kind); and that type involves some knot-tied `TyCons`. Result: black hole. The exact details are still hazy to me. The entire `uo_thing` stuff seems pretty grim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 11:19:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 11:19:23 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.95b1f9bb7c42fb419180a022b4169742@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors 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): Could be the fix to #12156 (unlikely), or #13381 (more likely), or #13487. I'm not sure which of these are merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:12:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:12:45 -0000 Subject: [GHC] #13513: Incorrect behavior on arm64 with optimisations In-Reply-To: <047.a4ba0434831678c830befedb77f73790@haskell.org> References: <047.a4ba0434831678c830befedb77f73790@haskell.org> Message-ID: <062.322034bad2a2b7ec6873c16661892f23@haskell.org> #13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vielmetti): If folks are looking for build/test infrastructure for aarch64, please contact me - Packet has "Type 2A" Cavium based 96-core ARMv8 systems which we are actively seeking out open source projects to engage with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:13:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:13:59 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.26322974f44cc0b48d50902d9fc49729@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 bgamari): * priority: high => highest Comment: This is definitely a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:19:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:19:06 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.f32f292c4879d8300139a3094f1e4e09@haskell.org> #13333: Typeable regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: typeable, Resolution: | 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): Phab:D3424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:19:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:19:31 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.0726824c939d98f7a5bedddc2fe557d4@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * related: => #13333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:19:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:19:44 -0000 Subject: [GHC] #13585: ala from Control.Lens.Wrapped panics In-Reply-To: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> References: <047.d6201d061ec44f0ff0f4aae7a74be608@haskell.org> Message-ID: <062.a2da06551a23c13919d5b2b6f687d38a@haskell.org> #13585: ala from Control.Lens.Wrapped panics -------------------------------------+------------------------------------- Reporter: fumieval | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: => 8.2.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:20:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:20:13 -0000 Subject: [GHC] #13578: Incorrect Record Pattern Synonym example in users guide In-Reply-To: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> References: <051.58a626fdfaf00c9495077810b02c0150@haskell.org> Message-ID: <066.9549715c00e60b6576bfbf5ad6260c09@haskell.org> #13578: Incorrect Record Pattern Synonym example in users guide -------------------------------------+------------------------------------- Reporter: cjholdbrooks | Owner: (none) Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:20:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:20:37 -0000 Subject: [GHC] #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file In-Reply-To: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> References: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> Message-ID: <061.6604a043cb490f85af1fe78aa34018fe@haskell.org> #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:21:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:21:18 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.13ce11ff5e6833129d8f05e654995235@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.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.2.1 => 8.4.1 Comment: It seems unlikely that anything will happen on this for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:21:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:21:55 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.da94b81c4608d5a9908a68e606ede8b3@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages 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.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:22:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:22:48 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.f92028d00aad940fa1ee213f9c26d66e@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: At this point it seems unlikely that the remaining robustification will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:23:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:23:23 -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.a5a0cc1413c68311786df76dc2b96eeb@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 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.2.1 => 8.4.1 Comment: This won't be fixed for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:24:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:24:13 -0000 Subject: [GHC] #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is In-Reply-To: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> References: <045.ce3771e6f817c088d0ef6be30bfa4c03@haskell.org> Message-ID: <060.e6d298084c66a400f65423e4eaa246d0@haskell.org> #13590: Update Cabal submodule to whatever the final Cabal 2.0 release is -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: libraries | Version: 8.2.1-rc2 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): At the moment this needs some changes in `ghc-cabal` and `ghc-pkg` due to the mungled package name patch that was merged to Cabal's `2.0` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:26:05 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.7e95540164520cd04a19898bcbeef821@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => rwbarton Comment: Reid, do you suppose you could have a look at the remaining regressions when you get a chance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:30:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:30:52 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.1be7027dc370caf0b7a1d8d1356ce5e1@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 shlevy): * Attachment "13609.patch" added. Untested fix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:31:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:31:29 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.0d5e02741b9afc117ad72cc13ab55902@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 shlevy): hvr can you test this ^ ? I can test this evening if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:44:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:44:16 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.e8ff4cdb9e9a8f143c70b24472155db1@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've confirmed that 2f9f1f86849ebc18af409c9b3fd809c9cd464021 (the fix for #13487) fixes this program as well. Curiously, #13487 was marked as merge, but hasn't made it into 8.2 for some reason. Can we do so? I'll prepare a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 13:55:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 13:55:29 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.74d0a89c327452a1e78e18f8d31bcf36@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #13487 | Differential Rev(s): Phab:D3495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3495 * related: => #13487 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:13:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:13:06 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.4153cb3e7bc68cabf7394568963e8d91@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:15:04 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.af471136fb1c9cf1fedcbe5c02b544d8@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 shlevy): https://phabricator.haskell.org/D3496 <- tested this locally, M.hs now works as expected with and without -fexternal-interpreter in stage1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:20:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:20:59 -0000 Subject: [GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts In-Reply-To: <050.20687161d0113262dd4300045296344b@haskell.org> References: <050.20687161d0113262dd4300045296344b@haskell.org> Message-ID: <065.a74432012b3a36c97ce45fdace944c90@haskell.org> #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Here appears to be a smaller, digestible example: {{{#!hs {-# LANGUAGE TypeFamilies, TypeOperators, DataKinds, PolyKinds, GADTs, ScopedTypeVariables #-} f :: [a] -> [a] f [] = [] f [x] = [x] f (x:y:zs) = g y zs where g _ bs = x : bs type family F (as :: [a]) :: [a] where F '[] = '[] F '[x] = '[x] F (x:y:zs) = G x y zs type family G x a bs where G x _ bs = x : bs data family Sing (x :: k) data instance Sing (x :: [a]) where SNil :: Sing '[] SCons :: Sing a -> Sing as -> Sing (a : as) infixr 5 `SCons` sF :: forall (p :: [a]). Sing p -> Sing (F p :: [a]) sF SNil = SNil sF (SCons x SNil) = SCons x SNil sF ((x :: Sing x) `SCons` y `SCons` zs) = sG y zs where sG :: forall b c. Sing b -> Sing c -> Sing (G x b c) sG _ bs = x `SCons` bs }}} Let's start by examining `f` and `g`, which are ordinary, Haskell98 functions. What's the inferred type of `g`? It depends on whether or not lets are generalized. In Haskell98 (i.e. `NoMonoLocalBinds`), `g` is inferred to have type `forall b. b -> [a] -> [a]`. With `MonoLocalBinds`, `g` is inferred to have type `a -> [a] -> [a]`. Both types allow `f` to type-check, and so the user won't notice this difference. Now let's consider the translation of `f` and `g` to type families. `g` closes over the outer local variable `x`, so we must add `x` to `G`'s parameter list (this is lambda lifting). Note that `F` gets a CUSK, derived from `f`'s type signature. `G` gets no kind annotations, as `g` has no type annotation. GHC infers kind `forall a b. a -> b -> [a] -> [a]` for `G`. Note that, as `G` is not local, its kind is always generalized, regardless of `MonoLocalBinds`. Finally, we consider the singletonized version of `f` and `g`. Note that the type variable bound in `sF`'s type gets a kind signature, as does the result. `sG` gets a type signature, but no variables get kind signatures. (`sG`'s type signature is entirely formulaic, given the singletons pattern.) The only way GHC can figure out the kinds of `b` and `c` is via their usage in the call to `G`. This tells GHC that `c` must have kind `[a]`, but it gives no information about `b`, whose kind remains mysterious. In 8.0, GHC mistakenly quantified over the kind of `b`, leading to `sG :: forall (b :: k) (c :: [a]). ...`. When `sG` is called on `y :: a`, it's specialized with `[k |-> a]` and all is well. However, now that kind generalization is working properly, GHC does ''not'' quantify over `k` and leaves it as a metavariable to be solved. What puzzles me a bit now that I look at this is that `k` should be able to be solved in the no-generalization case: `k` is determined by the call `sG y zs`, where we can see that `k := a` is a good solution. But GHC reports `k` as untouchable at this point.... and I don't know why. There seems to be no equality constraints brought into scope between `sG y zs` and the introduction of `k`, so I don't know why it would be untouchable. I will examine again in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:36:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:36:39 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.d80888e75f98f1eb2569e28e5838a4e8@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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 hvr): I've tested the patch on AIX, and it appears to work well there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:57:00 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.eb98775c31eb0dfa566a54b58183dde8@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): RyanGlScott, did comment:24 come from user code? If not then we might just have to punt this on to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:57:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:57:42 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.a5a6bfc49db936304934b830a00d68eb@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jb55): * cc: jb55 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:58:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:58:38 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.2e9fd0eaba3c59c070aada91cf7dc495@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.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): * status: merge => new Comment: While this appears to be fixed, Simon would like to know what precisely fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 14:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 14:59:12 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.83fd5ff5ed88765a54dc3f819bc250a0@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:34 bgamari]: > RyanGlScott, did comment:24 come from user code? If not then we might just have to punt this on to 8.4. It's only user code in the sense that I stumbled upon it independently while idly trying out levity polymorphism. I wouldn't be heartbroken if it didn't make it into 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:07:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:07:06 -0000 Subject: [GHC] #13420: Bizarre pretty-printing of closed type families in GHCi In-Reply-To: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> References: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> Message-ID: <065.948c9438ec7919bf14c51349a3a28262@haskell.org> #13420: Bizarre pretty-printing of closed type families in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3497 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3497 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:10:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:10:22 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.48e89f37af5509d0f2fdafc77ef89232@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is a reasonable candidate for 8.2. Simon and I agree that the patch as submitted is a little smelly, but it works (modulo validation glitches). We have a plan for a better approach, but the better approach will have to wait until I free up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:32:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:32:55 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.63b9263948d31cfbbb5f332facabd77d@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -1,3 +1,1 @@ - `NonEmpty` and `Semigroup` are in ''base'' and we are on our way to add - `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to - ask if we should include + This is a proposal to add @@ -5,2 +3,1 @@ - Semigroup-Foldable.html Foldable1] in ''base'' as well (`Foldable1` is - like `Foldable` for non-empty structures). + Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base @@ -8,6 +5,14 @@ - `Foldable` has partial functions, functions that only make sense for non- - empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. - There are also functions which ''could'' be defined in terms of `Foldable` - like `head` / `tail` (for definition of `unimprove` and `Diff` see - [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue - #49] and this + {{{#!hs + -- Data.Semigroup.Foldable + class Foldable t => Foldable1 t where + fold1 :: Semigroup m => t m -> m + foldMap1 :: Semigroup m => (a -> m) -> t a -> m + + -- Possible methods (efficiency) + head1 :: t a -> a + last1 :: t a -> a + }}} + + along with instances and function that are only valid for non-empty + structures (details: [https://github.com/ekmett/semigroupoids/issues/49 + semigroupoids issue #49], @@ -15,3 +20,1 @@ - github] page) - - With `Foldable1` we can make these functions total: + github]) @@ -39,2 +42,2 @@ - There is also the possibility of adding further functions such as `foldM`, - `foldM_`, `foldrM` and `foldlM` for non-empty structures. + Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures + is also a possibility. @@ -42,3 +45,10 @@ - As usual I don't have more concrete ideas, but let's start by testing the - waters before submitting a ghc-proposal. I understand this may be - controversial but I never liked so many partial functions in `Foldable`. + ---- + + Currently these are partial functions in `Foldable`. This proposal does + '''not''' propose replacing partial `Foldable` functions. + + ---- + + I wanted to test the waters before submitting it to the libraries mailing + list. This may be controversial but it gives us a path to avoid partial + functions in `Foldable`. New description: This is a proposal to add [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base {{{#!hs -- Data.Semigroup.Foldable class Foldable t => Foldable1 t where fold1 :: Semigroup m => t m -> m foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- Possible methods (efficiency) head1 :: t a -> a last1 :: t a -> a }}} along with instances and function that are only valid for non-empty structures (details: [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49], [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github]) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures is also a possibility. ---- Currently these are partial functions in `Foldable`. This proposal does '''not''' propose replacing partial `Foldable` functions. ---- I wanted to test the waters before submitting it to the libraries mailing list. This may be controversial but it gives us a path to avoid partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:34:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:34:58 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.54a21394b8e11d475b278d6693c8a05b@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I wondered about deferring the errors in `solveEqualities` by re-emitting them. Just jotting it down here; entirely untested. {{{ +{- + ; emitConstraints final_wc + ; traceTc "End solveEqualities }" (ppr final_wc) + ; when (anyErrorsWC final_wc) failM + ; return result } +-} @@ -145,0 +153,8 @@ solveEqualities thing_inside +anyErrorsWC :: WantedConstraints -> Bool +anyErrorsWC (WC { wc_simple = wanteds, wc_insol = insols, wc_impl = implics }) + = anyBag is_err wanteds + || anyBag is_err insols + || anyBag (anyErrorsWC . ic_wanted) implics + where + is_err ct = trulyInsoluble ct + }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:38:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:38:19 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.d3b0fc0c05f7c30b1d91d3101f5b5295@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very smelly. Let's not close this, nor forget it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:45:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:45:38 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.4191def26b6597ed454a13fcb22024f1@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3498 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3498 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 15:52:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 15:52:05 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.b7a3c885caf38030d430508574417b7e@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've verified that commit 2effe18ab51d66474724d38b20e49cc1b8738f60 (The Early Inline Patch) was what fixed this. Somewhat related: the [https://ghc.haskell.org/trac/ghc/changeset/be8122ab72aeec509b5ce4b4f05fbc5cdb77bf5a/ghc commit] which added this program as a regression test isn't actually //running// the compiled program, so it's not verifying if it's looping or not. Surely this isn't intended? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:10:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:10:54 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.3a87225f04cab8b628337f5836f05b30@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | 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 simonpj): Where is the patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:12:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:12:33 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.544eb25b8a9e85fd52db56ab37c3ef5d@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, the test should run. We still need to know why it looped before. The early-inline patch should not, of itself, have changed that! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:16:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:16:59 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.9b90149ce1b6a1d426329698c72b6612@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot 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 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:19:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:19:58 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin Message-ID: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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: -------------------------------------+------------------------------------- Consider this program: {{{ {-# OPTIONS_GHC -O -fplugin TestPlugin #-} module Test where foo :: Int -> Int foo = id {-# INLINE [0] foo #-} {-# RULES "foo1" [1] foo 1 = foo 2 "foo2" [1] foo 2 = foo 3 #-} fun :: Int -> Int -> Int fun = (+) {-# NOINLINE fun #-} test = foo 1 `fun` foo 2 }}} I would expect that one run of the simplifier in phase `1` will turn this into {{{ test = foo 3 `fun` foo 3 }}} I am using this plugin to test this: {{{ module TestPlugin where import System.Exit import Control.Monad import GhcPlugins import Simplify import CoreStats import SimplMonad import FamInstEnv import SimplEnv -- Plugin boiler plate plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ (simpl:xs) = return $ simpl : pass : xs where pass = CoreDoPluginPass "Test" testPass -- The plugin testPass :: ModGuts -> CoreM ModGuts testPass guts = do let [expr] = [ e | NonRec v e <- mg_binds guts , occNameString (occName v) == "test" ] simplified_expression <- simplify guts expr putMsg $ text "Test" $$ nest 4 (hang (text "Before" <> colon) 4 (ppr expr)) $$ nest 4 (hang (text "After" <> colon) 4 (ppr simplified_expression)) liftIO $ exitFailure -- A simplifier simplify :: ModGuts -> CoreExpr -> CoreM CoreExpr simplify guts expr = do dflags <- getDynFlags let dflags' = dflags { ufVeryAggressive = True } us <- liftIO $ mkSplitUniqSupply 's' let sz = exprSize expr rule_base <- getRuleBase vis_orphs <- getVisibleOrphanMods let rule_base2 = extendRuleBaseList rule_base (mg_rules guts) let rule_env = RuleEnv rule_base2 vis_orphs (expr', _) <- liftIO $ initSmpl dflags' rule_env emptyFamInstEnvs us sz $ simplExpr (simplEnv 1) >=> simplExpr (simplEnv 1) $ expr return expr' simplEnv :: Int -> SimplEnv simplEnv p = mkSimplEnv $ SimplMode { sm_names = ["Test"] , sm_phase = Phase p , sm_rules = True , sm_inline = True , sm_eta_expand = True , sm_case_case = True } }}} But I get: {{{ $ ghc-head -package ghc Test.hs [1 of 2] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) Test Before: fun (foo (GHC.Types.I# 1#)) (foo (GHC.Types.I# 2#)) After: fun (foo (GHC.Types.I# 2#)) (foo (GHC.Types.I# 3#)) }}} If I however compile this without the plugin, and look at what’s happening with `-dverbose-core2core`, I observe this: {{{ … test :: Int test = fun (foo (GHC.Types.I# 1#)) (foo (GHC.Types.I# 2#)) … ==================== Simplifier ==================== Max iterations = 4 SimplMode {Phase = 1 [main], inline, rules, eta-expand, case-of-case} … test :: Int test = fun (foo (GHC.Types.I# 3#)) (foo (GHC.Types.I# 3#)) … }}} So what am I doing wrong in my plugin? Any help is appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:21:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:21:15 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case In-Reply-To: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> References: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> Message-ID: <059.f25609fe83213898f56c34aace44e568@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid I don't follow the argument in comment:2. What precisely is your objection and what are you proposing that we change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:24:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:24:36 -0000 Subject: [GHC] #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 In-Reply-To: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> References: <046.8370c5a51cf6fd43771bbc3f135011a3@haskell.org> Message-ID: <061.9f61b0f7ce49baae0a5ef717c782dfec@haskell.org> #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:26:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:26:00 -0000 Subject: [GHC] #13584: ghci parse error on operator info In-Reply-To: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> References: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> Message-ID: <061.c46f92f46a317bac9db39d334993a3f1@haskell.org> #13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: parse, info, | operator 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): It is indeed strange that these parse differently. I would argue that we should reject `(+ )`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 16:44:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 16:44:19 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case In-Reply-To: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> References: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> Message-ID: <059.5d410d2a3a81dcd4064a395670cdae75@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hello Ben,\\ In fact the cause does not come from Typed Holes in my opinion.\\ We need to go back in the language implementation and redefine the role of underscore {{{_}}} in an expression.\\ And hence Typed Holes will become clearer.\\ See ticket {{{#13602}}} please.\\ what do you think?\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 17:04:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 17:04:47 -0000 Subject: [GHC] #13602: Pattern syntax in expression context must be clarified In-Reply-To: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> References: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> Message-ID: <059.077656f1b6353603b30ea2cbe4806327@haskell.org> #13602: Pattern syntax in expression context must be clarified -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [ticket:13602 vanto]: > > {{{let f = [True | x <- [_, _]]}}} raise the error > {{{pattern syntax in expression context: _}}}\\ > But as Typed Holes, this error has no sense here.\\ > > {{{let f' = [_ | x <- [1,2]]}}}will give a result like > {{{"__"}}} And this calculation also makes sense if one refers to the rule of inference, as the function > {{{f}}} > .\\ I'm afraid I still don't follow. What, specifically, is the issue you want solved? It seems to have something to do with holes, but I can't discern what from your text. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 18:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 18:21:09 -0000 Subject: [GHC] #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 In-Reply-To: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> References: <050.d768cbcd7afd3c7633840a8a13d3da1c@haskell.org> Message-ID: <065.f71b43d4c0607af5a9a41eb022e6c7e5@haskell.org> #13594: Typechecker behavior w.r.t. BangPatterns and nested foralls has changed in 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: BangPatterns, Resolution: | 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 bgamari): It is the `wip/T13594` branch but sadly validation failed. I'll need to look into why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 19:29:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 19:29:59 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) In-Reply-To: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> References: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> Message-ID: <064.c3bc5b159a721b67f6bf545ed36af97d@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------+------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Comment (by jp.rider63): As mentioned on irc, applying D3290 before building the cross-compiler did not work. The diff of nm is ~800k lines so I don't think it will be much help (the x86 library was built with a different version of ghc so there are different library versions and different symbols). I've been trying to create a minimal example to demonstrate the crash. So far I have had mixed results. Calling `hs_AAPublicKeyAlgorithm` by itself does cause the crash. Oddly, when I call `hs_testf` (defined below) before `hs_AAPublicKeyAlgorithm`, the crash goes away. {{{ class Test a b | a -> b where testF :: a -> b instance Test String String where testF = id foreign export ccall hs_astr :: IO (StablePtr String) hs_astr :: IO (StablePtr String) hs_astr = newStablePtr "a string" foreign export ccall hs_testf :: StablePtr String -> IO (StablePtr String) hs_testf :: StablePtr String -> IO (StablePtr String) hs_testf s = do s' <- deRefStablePtr s newStablePtr $ testF s' }}} I was thinking that maybe the functional dependency from `ToAlgorithm t a | t -> a` is causing the crash, but I'm not really sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 21:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 21:08:12 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.9296a3a25fc8cb66197f92cdea055c9c@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer: @@ -1,1 +1,1 @@ - This commit + The commit 751996e90a964026a3f86853338f10c82db6b610 New description: The commit 751996e90a964026a3f86853338f10c82db6b610 {{{ commit 751996e90a964026a3f86853338f10c82db6b610 Author: Simon Peyton Jones Date: Fri Apr 7 17:10:07 2017 +0100 Kill off complications in CoreFVs }}} makes `n-body` in nofib go 25% slower. See [https://perf.haskell.org/ghc/#revision/751996e90a964026a3f86853338f10c82db6b610 perf results page]. Investigate. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 21:12:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 21:12:27 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code In-Reply-To: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> References: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> Message-ID: <062.a222c5733328835f5c2bd2fb361f9d7e@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 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 bgamari): There is a bit of a tricky interface question here. It seems to me like allowing only one callback is insufficient. Afterall, what when you want to use both MySQL and libcurl? It seems that you really need the ability to register multiple callbacks for this to be robust. However, there is also the question of what the precise semantics of this callback are. Should it get called on threads which are pre-existing at time of callback registration? Does the callback get called in the context of each thread, or merely with its, e.g., `pid`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 21:15:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 21:15:25 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.e873aa161f79c7366e67d564b6305c1f@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3500 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * differential: => Phab:D3500 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 21:16:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 21:16:02 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code In-Reply-To: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> References: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> Message-ID: <062.1a8d51c9399f99fdd351fb828cb36b26@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 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 bgamari): Also, it seems that MySQL requires that you call `mysql_thread_end` on thread termination. We would probably also need a callback for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 21:17:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 21:17:33 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code In-Reply-To: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> References: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> Message-ID: <062.89c0a168bee0bf6489f690c90a140689@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 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 bgamari): It shouldn't be hard for someone to implement this idea after these questions are answered. I believe that all of the relevant RTS bits can be found in `rts/Task.c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 22:33:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 22:33:39 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.914945dc2de5f3da30a94b58c32c0d25@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 22:34:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 22:34:27 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.eaaabc0e125622921a44a852b780253b@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not just that they aren't getting applied; somehow `foo 1` is getting rewritten to `foo 2` which is deeply strange. I have no hypothesis here. I'm not sure why you are simplifying twice. You don't seem to be doing occurrence analysis, although I can't see how that will lead to this behaviour. Try `-ddump-rule-rewrites`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 22:51:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 22:51:44 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.d017da79f76dec2a218ce3e26aadb27f@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 nomeata): Replying to [comment:1 simonpj]: > It's not just that they aren't getting applied; somehow `foo 1` is getting rewritten to `foo 2` which is deeply strange. That is not strange, one of the rules is {{{ "foo1" [1] foo 1 = foo 2 }}} after all. But I wonder why it does not then apply the second rule. > I'm not sure why you are simplifying twice. Just in case it takes multiple simplifier iterations to apply rules exhaustively (although it does not help). My hypothesis is as follows: Rewrite rules are attached (via the `IdInfo` field `ruleInfo`)to the `Id` of the outermost function on the LHS of the rule; in this case `foo` (and not looked up in some mapping, as one might naively expect). As far as I can tell, the rule `foo1` and `foo2` are attached to all occurrences of `foo` in the module – excluding the ones on the RHS of the rules themselves! This would explain this behaviour. It would rewrite foo[ruleInfo=foo1,foo2] 1 `fun` foo[ruleInfo=foo1,foo2] 2 to foo[ruleInfo=] 2 `fun` foo[ruleInfo=] 3 and then not apply any more rules (because `ruleInfo`) is empty. This hypothesis would explain the behavior; what puzzles me is that it works as expected if I compile the module as normal. And, pragmaticall, what I wave to do so that my plugin acts as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 25 23:53:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Apr 2017 23:53:42 -0000 Subject: [GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation Message-ID: <044.57733831351687fff6258688df1f42f7@haskell.org> #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Mostly self contained sample - only depends on base, deepseq and locally provided hashable and unordered-containers. No unsafePtrEq involved, but unsafeThaw/Freese is - affected function uses `foldl'` to insert stuff into hashmap - I don't think there's a way to obtain multiple references to the same map. Making arguments strict or rnf'ing them doesn't help. Issue is reproduceable with HEAD with -O0 but not with O2. in ghc 8.0.2 and 7.10.1 it's reproduceable with -O2 as well. {{{ sum (map snd xs) = map snd (toList $ fromListWith (+) xs) }}} ^ this statement fails to hold when xs contains stuff with memocombinators and parallel evaluation from evaluation strategies I found which inplace update needs to be replaced with copy and update to make things work - bug is fixed after changing unsafeInsertWith, BitmapIndexed branch: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps: clone this: {{{ https://github.com/pacak/cuddly-bassoon }}} {{{ stack build }}} {{{ ./.stack-work/install/x86_64-linux/ghc-8.0.2/8.0.2/bin/gamebooksolver- solvebook02 }}} Last command will either finish successfully printing `"solving\n0.0"` or will die with `error` in `src/Solver.hs` `regroup` function. To reproduce the problem computer must have at least 3 CPUs, running with +RTS -N1 or -N2 "fixes" the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 00:26:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 00:26:01 -0000 Subject: [GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.9c1c392856a993bd892a94f25773142a@haskell.org> #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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): * priority: normal => highest * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 00:28:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 00:28:27 -0000 Subject: [GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.2d96d311cde9401c038bd077ffb48a69@haskell.org> #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Can also build easily with "cabal new-build". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 00:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 00:50:44 -0000 Subject: [GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.64396c1b38fae9ddfb5681fcbf7db4ea@haskell.org> #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- Description changed by pacak: @@ -0,0 +1,6 @@ + The program linked below uses modified (mostly to trim down on + dependencies) copies of parallel and unordered-containers. Its behavior is + nondeterministic, even though all the operations it uses are supposed to + be pure + + @@ -4,2 +10,9 @@ - into hashmap - I don't think there's a way to obtain multiple references - to the same map. Making arguments strict or rnf'ing them doesn't help. + into hashmap. + + + unsafeThaw/Freeze are used to perform implace updates on a HashMap inside + fromListWith function. Updates are sequential and performed with `foldl'`, + I don't see obvious ways of obtaining references to intermediate versions + of HashMap so inplace updates seems to be valid. + + Making arguments to unsafeInsertWith strict or rnf'ing them doesn't help. @@ -11,1 +24,1 @@ - sum (map snd xs) = map snd (toList $ fromListWith (+) xs) + sum (map snd xs) = sum (map snd (toList $ fromListWith (+) xs)) New description: The program linked below uses modified (mostly to trim down on dependencies) copies of parallel and unordered-containers. Its behavior is nondeterministic, even though all the operations it uses are supposed to be pure Mostly self contained sample - only depends on base, deepseq and locally provided hashable and unordered-containers. No unsafePtrEq involved, but unsafeThaw/Freese is - affected function uses `foldl'` to insert stuff into hashmap. unsafeThaw/Freeze are used to perform implace updates on a HashMap inside fromListWith function. Updates are sequential and performed with `foldl'`, I don't see obvious ways of obtaining references to intermediate versions of HashMap so inplace updates seems to be valid. Making arguments to unsafeInsertWith strict or rnf'ing them doesn't help. Issue is reproduceable with HEAD with -O0 but not with O2. in ghc 8.0.2 and 7.10.1 it's reproduceable with -O2 as well. {{{ sum (map snd xs) = sum (map snd (toList $ fromListWith (+) xs)) }}} ^ this statement fails to hold when xs contains stuff with memocombinators and parallel evaluation from evaluation strategies I found which inplace update needs to be replaced with copy and update to make things work - bug is fixed after changing unsafeInsertWith, BitmapIndexed branch: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps: clone this: {{{ https://github.com/pacak/cuddly-bassoon }}} {{{ stack build }}} {{{ ./.stack-work/install/x86_64-linux/ghc-8.0.2/8.0.2/bin/gamebooksolver- solvebook02 }}} Last command will either finish successfully printing `"solving\n0.0"` or will die with `error` in `src/Solver.hs` `regroup` function. To reproduce the problem computer must have at least 3 CPUs, running with +RTS -N1 or -N2 "fixes" the problem. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:11:36 -0000 Subject: [GHC] #13420: Bizarre pretty-printing of closed type families in GHCi In-Reply-To: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> References: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> Message-ID: <065.a1f3ae92e01ea1e79d89dc7ee96a5441@haskell.org> #13420: Bizarre pretty-printing of closed type families in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3497 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"da792e47981f65b2dba4fc76ce51dc3fb9c4c02d/ghc" da792e47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da792e47981f65b2dba4fc76ce51dc3fb9c4c02d" Only pretty-print binders in closed type families with -fprint-explicit- foralls Previously, we were unconditionally pretty-printing all type variable binders when pretty-printing closed type families (e.g., in the output of `:info` in GHCi). This threw me for a loop, so let's guard this behind the `-fprint-explicit-foralls` flag. Test Plan: make test TEST=T13420 Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13420 Differential Revision: https://phabricator.haskell.org/D3497 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:11:36 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.24f6f92ca1ddcdaea6a37b07e8efd675@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9373994acaf1b73fe0e7cf8e03594c63cec8d235/ghc" 9373994/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9373994acaf1b73fe0e7cf8e03594c63cec8d235" configure: Kill off FP_ARG_WITH_* This replaces the --with-* configure flags with the usual autoconf environment variables, as suggested by #13583. Test Plan: Configure on various platforms Reviewers: hvr, trofi, thomie, austin Reviewed By: trofi Subscribers: rwbarton, erikd GHC Trac Issues: #13583 Differential Revision: https://phabricator.haskell.org/D3499 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:11:36 -0000 Subject: [GHC] #10640: Document prim-ops In-Reply-To: <046.4e817e7df8d2c783e102d23f1eac2c40@haskell.org> References: <046.4e817e7df8d2c783e102d23f1eac2c40@haskell.org> Message-ID: <061.aeca8e4bbfd9671a3ab36e993e97b7e3@haskell.org> #10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 7.10.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:D1082 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"244602697c30e03ba63076941e4742ceeb78dd7c/ghc" 2446026/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="244602697c30e03ba63076941e4742ceeb78dd7c" Document mkWeak# Reviewers: simonmar, austin Reviewed By: simonmar Subscribers: RyanGlScott, rwbarton, thomie GHC Trac Issues: #10640, #13611 Differential Revision: https://phabricator.haskell.org/D3498 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:11:36 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.8aab477d99a5dfc39884b46633522c7c@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3498 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"244602697c30e03ba63076941e4742ceeb78dd7c/ghc" 2446026/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="244602697c30e03ba63076941e4742ceeb78dd7c" Document mkWeak# Reviewers: simonmar, austin Reviewed By: simonmar Subscribers: RyanGlScott, rwbarton, thomie GHC Trac Issues: #10640, #13611 Differential Revision: https://phabricator.haskell.org/D3498 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:11:36 -0000 Subject: [GHC] #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file In-Reply-To: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> References: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> Message-ID: <061.fb3aee542f08abf584411b236c5f2b32@haskell.org> #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"66108864540601837ad77847f4062a670362361f/ghc" 6610886/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="66108864540601837ad77847f4062a670362361f" Revert "Remove special casing of Windows in generic files" This commit didn't consider the fact that binary distributions on Windows must have relative toolchain paths. This caused #13560. This reverts commit 48385cb2fc295eb8af9188cbe140142c1807d5a7 (except for a helpful comment). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:11:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:11:36 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.d56b9bb0efcbc92f874412e43ff3bcf5@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3500 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"47be6444d35783eea7dc3ab8b2f11626777cdbd8/ghc" 47be644/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="47be6444d35783eea7dc3ab8b2f11626777cdbd8" Add instances for Data.Ord.Down Namely `Num`, `Functor`, `Applicative`, `Monad`, `Semigroup` and `Monoid` for `Data.Ord.Down` (#13097). Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: bgamari, RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie GHC Trac Issues: #13097 Differential Revision: https://phabricator.haskell.org/D3500 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:13:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:13:09 -0000 Subject: [GHC] #13420: Bizarre pretty-printing of closed type families in GHCi In-Reply-To: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> References: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> Message-ID: <065.07b3bdec7c651ee7766b0f1218940f32@haskell.org> #13420: Bizarre pretty-printing of closed type families in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3497 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:14:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:14:04 -0000 Subject: [GHC] #13097: Num a => Num (Down a) In-Reply-To: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> References: <051.a5fd4f9730009c1f1add0e7f3e40a083@haskell.org> Message-ID: <066.f627fca85b9d380b1e7b5f2364ef6cb7@haskell.org> #13097: Num a => Num (Down a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3500 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:13:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:13:43 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.fdb24c0634f0117c7e880b8a1b01713f@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3498 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:14:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:14:35 -0000 Subject: [GHC] #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file In-Reply-To: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> References: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> Message-ID: <061.4df4f7267c3d93365f643dad2b83bc8e@haskell.org> #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:14:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:14:55 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.69901f078c9d3e27ec76ab61ee2d57cc@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:15:04 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.a678ea3e62d0d10adff1e8d9221d0da9@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:18:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:18:04 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors In-Reply-To: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> References: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> Message-ID: <063.56f122b14e18d2dca30ed202d8d22d38@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T13487 Blocked By: | Blocking: Related Tickets: #12104 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12104 * milestone: 8.4.1 => 8.2.1 Comment: This was marked as merge, but the milestone was 8.4.1. I've opted to mark it for the 8.2.1 milestone, especially since it fixes #12104 (see https://ghc.haskell.org/trac/ghc/ticket/12104#comment:8). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 01:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 01:50:30 -0000 Subject: [GHC] #13601: GHC errors but hangs In-Reply-To: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> References: <051.4e8fb4ae3d4c038136f57536b875ceac@haskell.org> Message-ID: <066.774aee702e5a50d47a6d0c8a6a5ad47a@haskell.org> #13601: GHC errors but hangs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The `uo_thing` field was introduced in order to keep error messages reasonably stable during the `TypeInType` merge. Pre-`TypeInType`, kind errors reported what type had the kind that was involved in the error, and I wanted to keep this functionality post-`TypeInType`. That's the only reason the field exists. It was (and is) my hope to use `uo_thing` also for term-level error messages, as I think we can improve these through its use. One of the grim aspects of `uo_thing` is that `unifyType`'s type starts with `Outputable a => Maybe a -> ...` in order to use (possibly) something as the thing in the `uo_thing` field. But passing `Nothing` to `unifyType` causes ambiguity errors, because we can't know what `a` should be. So I have `noThing :: Maybe (HsExpr Name); noThing = Nothing` to resolve the ambiguity. I've been meaning to clean this up. Another missed opportunity after `TypeInType` is to use `TcTyCon` more fully. Type-checking can produce `TcTyCon`s instead of `TyCon`s, with the latter rewriting to the former only during the final zonk. This would mean that the type-checking knot needs to cover only zonking, instead of type- checking. That would surely fix this bug. In more direct response to comment:4, I'm dubious. If `solveEqualities` fails, then there is something ill-kinded lurking about, and I'm worried that some `failIfErrsM` and such won't fire, causing chaos. It may be possible to rein in the chaos, but I don't think it will be an easy win. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 02:02:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 02:02:01 -0000 Subject: [GHC] #13602: Pattern syntax in expression context must be clarified In-Reply-To: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> References: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> Message-ID: <059.6c99fa0479eb7a8f7d66c1eaa34976e9@haskell.org> #13602: Pattern syntax in expression context must be clarified -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think to move this forward, we need 3 things: 1. A concrete example (chunk of Haskell code) 2. What GHC does with this code today 3. What you would like GHC to do with this code Sometimes, several examples (each with points 1, 2, and 3) are helpful. ''Separately'' (either above or below), explain your motivation. It can be hard sometimes when the motivation and concrete examples are mixed together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 02:05:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 02:05:05 -0000 Subject: [GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.c060f14390af6d61b38507c6bd96e052@haskell.org> #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Interesting, forcing `st'` before passing it to `unsafeUpdateM` in the the `BitmapIndexed` branch of `Data.HashMap.Strict.unsafeInsertWith` also seems to fix the issue. I haven't thought much about why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 02:40:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 02:40:23 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators_=28was=3A_Wrong_results_from_what_suppose?= =?utf-8?q?d_to_be_pure_function_with_presense_of_parallel_evalua?= =?utf-8?q?tion=29?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.e6f5e78128bb1fec7153d79c564ecae8@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 liyang): * cc: liyang (added) @@ -1,4 +1,4 @@ - The program linked below uses modified (mostly to trim down on - dependencies) copies of parallel and unordered-containers. Its behavior is - nondeterministic, even though all the operations it uses are supposed to - be pure + The example below uses in-place copies (mostly to fix dependencies + and to make it more self-contained) of `parallel` (modified), + `unordered-containers` (modified), and `hashable`. Its behavior is + nondeterministic, despite using only supposedly pure operations. @@ -6,0 +6,4 @@ + Aforementioned aside, it only depends on `base` and `deepseq`, and there's + no `unsafePtrEq` involved at all. The affected `fromListWith` uses + `foldl'` + to perform in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. @@ -7,4 +11,3 @@ - Mostly self contained sample - only depends on base, deepseq and locally - provided hashable and unordered-containers. No unsafePtrEq involved, but - unsafeThaw/Freese is - affected function uses `foldl'` to insert stuff - into hashmap. + I don't see how references to intermediate versions of `HashMap` could + leak + out, so using in-place updates seem valid to me. @@ -12,10 +15,5 @@ - - unsafeThaw/Freeze are used to perform implace updates on a HashMap inside - fromListWith function. Updates are sequential and performed with `foldl'`, - I don't see obvious ways of obtaining references to intermediate versions - of HashMap so inplace updates seems to be valid. - - Making arguments to unsafeInsertWith strict or rnf'ing them doesn't help. - - Issue is reproduceable with HEAD with -O0 but not with O2. in ghc 8.0.2 - and 7.10.1 it's reproduceable with -O2 as well. + Strictifying (or even `rnf`ing) the arguments to `unsafeInsertWith` + doesn't + help. The issue is reproducible with `-O0` on `HEAD` but not with `-O2`; + On + 8.0.2 and 7.10.1, it can also be reproduced with `-O2`. @@ -24,1 +22,1 @@ - sum (map snd xs) = sum (map snd (toList $ fromListWith (+) xs)) + sum . map snd = sum . map snd . toList . fromListWith (+) @@ -27,2 +25,2 @@ - ^ this statement fails to hold when xs contains stuff with memocombinators - and parallel evaluation from evaluation strategies + The above identity fails when the input contains values constructed using + ''both'' memo combinators and parallel evaluation strategies. @@ -30,4 +28,3 @@ - - I found which inplace update needs to be replaced with copy and update to - make things work - bug is fixed after changing unsafeInsertWith, - BitmapIndexed branch: + I have identified the in-place-update that needs to be replaced with + copy-and-update to make things work―patch `unsafeInsertWith` on the + `BitmapIndexed` branch as follows: @@ -38,1 +35,1 @@ - + let ary' = A.update ary i st' + + let ary' = A.update ary i st' @@ -42,5 +39,1 @@ - - - Steps: - - clone this: + Steps to reproduce: @@ -49,1 +42,4 @@ - https://github.com/pacak/cuddly-bassoon + git clone https://github.com/pacak/cuddly-bassoon && cd cuddly-bassoon + cabal new-build + dist-newstyle/build/gamebooksolver-0.1.0.0/build/gamebooksolver- + solvebook02/gamebooksolver-solvebook02 @@ -52,3 +48,2 @@ - {{{ - stack build - }}} + This will either finish successfully with `"solving\n0.0"`, or will die + with an `error` from the `regroup` function in `src/Solver.hs`. @@ -56,4 +51,2 @@ - {{{ - ./.stack-work/install/x86_64-linux/ghc-8.0.2/8.0.2/bin/gamebooksolver- - solvebook02 - }}} + Your machine must have at least 2 CPU cores to reproduce the problem; also + it will not show up with `+RTS -N1`. @@ -61,2 +54,2 @@ - Last command will either finish successfully printing `"solving\n0.0"` or - will die with `error` in `src/Solver.hs` `regroup` function. + This issue was first reported here: + https://github.com/tibbe/unordered-containers/issues/147 @@ -64,3 +57,3 @@ - - To reproduce the problem computer must have at least 3 CPUs, running with - +RTS -N1 or -N2 "fixes" the problem. + And the original text of ''this'' report can be found here, in case my + editor fucked up or left anything out: + http://lpaste.net/diff/6339195854280196096/6983816376066506752 New description: The example below uses in-place copies (mostly to fix dependencies and to make it more self-contained) of `parallel` (modified), `unordered-containers` (modified), and `hashable`. Its behavior is nondeterministic, despite using only supposedly pure operations. Aforementioned aside, it only depends on `base` and `deepseq`, and there's no `unsafePtrEq` involved at all. The affected `fromListWith` uses `foldl'` to perform in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. I don't see how references to intermediate versions of `HashMap` could leak out, so using in-place updates seem valid to me. Strictifying (or even `rnf`ing) the arguments to `unsafeInsertWith` doesn't help. The issue is reproducible with `-O0` on `HEAD` but not with `-O2`; On 8.0.2 and 7.10.1, it can also be reproduced with `-O2`. {{{ sum . map snd = sum . map snd . toList . fromListWith (+) }}} The above identity fails when the input contains values constructed using ''both'' memo combinators and parallel evaluation strategies. I have identified the in-place-update that needs to be replaced with copy-and-update to make things work―patch `unsafeInsertWith` on the `BitmapIndexed` branch as follows: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps to reproduce: {{{ git clone https://github.com/pacak/cuddly-bassoon && cd cuddly-bassoon cabal new-build dist-newstyle/build/gamebooksolver-0.1.0.0/build/gamebooksolver- solvebook02/gamebooksolver-solvebook02 }}} This will either finish successfully with `"solving\n0.0"`, or will die with an `error` from the `regroup` function in `src/Solver.hs`. Your machine must have at least 2 CPU cores to reproduce the problem; also it will not show up with `+RTS -N1`. This issue was first reported here: https://github.com/tibbe/unordered-containers/issues/147 And the original text of ''this'' report can be found here, in case my editor fucked up or left anything out: http://lpaste.net/diff/6339195854280196096/6983816376066506752 -- Comment: I've editorised the text of the original bug report. Pray I do not editorise it further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 03:35:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 03:35:12 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.8a8a0eef4cfc8b33bdfec04e4e7d08a7@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Doe this imply that if you want to use gold, you'd specify LD=ld.gold, or however that ld is called? And we can remove the logic that forces gold? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 03:35:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 03:35:23 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.93e6a4db7c465c34aafe13ffa510bc8c@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- @@ -9,1 +9,1 @@ - to perform in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. + to effect in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. @@ -12,2 +12,2 @@ - leak - out, so using in-place updates seem valid to me. + possibly leak + out, so in-place updates seem valid to me. @@ -29,2 +29,3 @@ - copy-and-update to make things work―patch `unsafeInsertWith` on the - `BitmapIndexed` branch as follows: + copy-and-update to make things work―patch `unsafeInsertWith.go` in + `unordered-containers-0.2.8.0/Data/HashMap/Strict.hs`, under the + `BitmapIndexed` pattern as follows: New description: The example below uses in-place copies (mostly to fix dependencies and to make it more self-contained) of `parallel` (modified), `unordered-containers` (modified), and `hashable`. Its behavior is nondeterministic, despite using only supposedly pure operations. Aforementioned aside, it only depends on `base` and `deepseq`, and there's no `unsafePtrEq` involved at all. The affected `fromListWith` uses `foldl'` to effect in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. I don't see how references to intermediate versions of `HashMap` could possibly leak out, so in-place updates seem valid to me. Strictifying (or even `rnf`ing) the arguments to `unsafeInsertWith` doesn't help. The issue is reproducible with `-O0` on `HEAD` but not with `-O2`; On 8.0.2 and 7.10.1, it can also be reproduced with `-O2`. {{{ sum . map snd = sum . map snd . toList . fromListWith (+) }}} The above identity fails when the input contains values constructed using ''both'' memo combinators and parallel evaluation strategies. I have identified the in-place-update that needs to be replaced with copy-and-update to make things work―patch `unsafeInsertWith.go` in `unordered-containers-0.2.8.0/Data/HashMap/Strict.hs`, under the `BitmapIndexed` pattern as follows: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps to reproduce: {{{ git clone https://github.com/pacak/cuddly-bassoon && cd cuddly-bassoon cabal new-build dist-newstyle/build/gamebooksolver-0.1.0.0/build/gamebooksolver- solvebook02/gamebooksolver-solvebook02 }}} This will either finish successfully with `"solving\n0.0"`, or will die with an `error` from the `regroup` function in `src/Solver.hs`. Your machine must have at least 2 CPU cores to reproduce the problem; also it will not show up with `+RTS -N1`. This issue was first reported here: https://github.com/tibbe/unordered-containers/issues/147 And the original text of ''this'' report can be found here, in case my editor fucked up or left anything out: http://lpaste.net/diff/6339195854280196096/6983816376066506752 -- Comment (by liyang): I have editorised the text further. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 03:36:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 03:36:56 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.e41362f59c7f0124b287de068c92d0ee@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Just to be clear, my issue is not with gold per se. My issue is that we make assumptions about the naming of the linker. If my gold is called ld, or x-y-z-ld.gold or my-lovely-linker, I'm running into issues. This becomes evident probably only when using custom toolchains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 04:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 04:04:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.b4c3f1d9e064b16b6e33d96e54600820@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- Description changed by liyang: @@ -57,4 +57,0 @@ - - And the original text of ''this'' report can be found here, in case my - editor fucked up or left anything out: - http://lpaste.net/diff/6339195854280196096/6983816376066506752 New description: The example below uses in-place copies (mostly to fix dependencies and to make it more self-contained) of `parallel` (modified), `unordered-containers` (modified), and `hashable`. Its behavior is nondeterministic, despite using only supposedly pure operations. Aforementioned aside, it only depends on `base` and `deepseq`, and there's no `unsafePtrEq` involved at all. The affected `fromListWith` uses `foldl'` to effect in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. I don't see how references to intermediate versions of `HashMap` could possibly leak out, so in-place updates seem valid to me. Strictifying (or even `rnf`ing) the arguments to `unsafeInsertWith` doesn't help. The issue is reproducible with `-O0` on `HEAD` but not with `-O2`; On 8.0.2 and 7.10.1, it can also be reproduced with `-O2`. {{{ sum . map snd = sum . map snd . toList . fromListWith (+) }}} The above identity fails when the input contains values constructed using ''both'' memo combinators and parallel evaluation strategies. I have identified the in-place-update that needs to be replaced with copy-and-update to make things work―patch `unsafeInsertWith.go` in `unordered-containers-0.2.8.0/Data/HashMap/Strict.hs`, under the `BitmapIndexed` pattern as follows: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps to reproduce: {{{ git clone https://github.com/pacak/cuddly-bassoon && cd cuddly-bassoon cabal new-build dist-newstyle/build/gamebooksolver-0.1.0.0/build/gamebooksolver- solvebook02/gamebooksolver-solvebook02 }}} This will either finish successfully with `"solving\n0.0"`, or will die with an `error` from the `regroup` function in `src/Solver.hs`. Your machine must have at least 2 CPU cores to reproduce the problem; also it will not show up with `+RTS -N1`. This issue was first reported here: https://github.com/tibbe/unordered-containers/issues/147 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 05:31:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 05:31:43 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.09dde2e3a7d45ba5887074a27870c19e@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 pacak): I pushed a bunch of simplification commits to the repo, failure chance went down a bit but still within 10-20% on my machine. If you can't reproduce the problem - try first commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 07:21:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 07:21:18 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.5b2be70c10fc921d81f5cb45667e8646@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah now I get it > As far as I can tell, the rule foo1 and foo2 are attached to all occurrences of foo in the module – excluding the ones on the RHS of the rules themselves! That should not matter: at every occurrence of a variable it is looked up in the in-scope set, to get the "master copy", so after simplification all occurrences point to the binder. This is done by `SimplEnv.substId`. There is a debug WARN if the `Id` is not in the in-scope set. But I bet you have a non-debug compiler; and that you have an in-scope set that does not include `foo`. Might that be it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 09:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 09:41:31 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.5a7a6104130b124e44867e43a6e68233@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -12,2 +12,3 @@ - head1 :: t a -> a - last1 :: t a -> a + head1 :: t a -> a + last1 :: t a -> a + toNonEmpty :: t a -> Nonempty a New description: This is a proposal to add [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base {{{#!hs -- Data.Semigroup.Foldable class Foldable t => Foldable1 t where fold1 :: Semigroup m => t m -> m foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- Possible methods (efficiency) head1 :: t a -> a last1 :: t a -> a toNonEmpty :: t a -> Nonempty a }}} along with instances and function that are only valid for non-empty structures (details: [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49], [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github]) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures is also a possibility. ---- Currently these are partial functions in `Foldable`. This proposal does '''not''' propose replacing partial `Foldable` functions. ---- I wanted to test the waters before submitting it to the libraries mailing list. This may be controversial but it gives us a path to avoid partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 09:41:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 09:41:52 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.800d19f1942686b3444840aaec31f8ce@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -11,1 +11,1 @@ - -- Possible methods (efficiency) + -- Possible methods @@ -14,1 +14,1 @@ - toNonEmpty :: t a -> Nonempty a + toNonEmpty :: t a -> NonEmpty a New description: This is a proposal to add [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base {{{#!hs -- Data.Semigroup.Foldable class Foldable t => Foldable1 t where fold1 :: Semigroup m => t m -> m foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- Possible methods head1 :: t a -> a last1 :: t a -> a toNonEmpty :: t a -> NonEmpty a }}} along with instances and function that are only valid for non-empty structures (details: [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49], [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github]) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures is also a possibility. ---- Currently these are partial functions in `Foldable`. This proposal does '''not''' propose replacing partial `Foldable` functions. ---- I wanted to test the waters before submitting it to the libraries mailing list. This may be controversial but it gives us a path to avoid partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 09:43:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 09:43:45 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.bb51816905a8624a6d790b72e984ebe4@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -7,3 +7,3 @@ - class Foldable t => Foldable1 t where - fold1 :: Semigroup m => t m -> m - foldMap1 :: Semigroup m => (a -> m) -> t a -> m + class Foldable f => Foldable1 f where + fold1 :: Semigroup m => f m -> m + foldMap1 :: Semigroup m => (a -> m) -> f a -> m @@ -12,3 +12,3 @@ - head1 :: t a -> a - last1 :: t a -> a - toNonEmpty :: t a -> NonEmpty a + head1 :: f a -> a + last1 :: f a -> a + toNonEmpty :: f a -> NonEmpty a @@ -36,1 +36,1 @@ - foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) + foldr1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) @@ -39,1 +39,1 @@ - foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) + foldl1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) New description: This is a proposal to add [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base {{{#!hs -- Data.Semigroup.Foldable class Foldable f => Foldable1 f where fold1 :: Semigroup m => f m -> m foldMap1 :: Semigroup m => (a -> m) -> f a -> m -- Possible methods head1 :: f a -> a last1 :: f a -> a toNonEmpty :: f a -> NonEmpty a }}} along with instances and function that are only valid for non-empty structures (details: [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49], [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github]) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures is also a possibility. ---- Currently these are partial functions in `Foldable`. This proposal does '''not''' propose replacing partial `Foldable` functions. ---- I wanted to test the waters before submitting it to the libraries mailing list. This may be controversial but it gives us a path to avoid partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 10:06:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 10:06:48 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.f24234f9e9aeb7ad4137a52f28ded88d@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -24,1 +24,3 @@ - minimum1 :: (Ord a, Foldable1 f) => f a -> a + import qualified Data.Semigroup as S + + minimum1, maximum1 :: (Ord a, Foldable1 f) => f a -> a @@ -26,2 +28,0 @@ - - maximum1 :: (Ord a, Foldable1 f) => f a -> a @@ -30,1 +30,1 @@ - head1 :: Foldable1 f => f a -> a + head1, last1 :: Foldable1 f => f a -> a @@ -32,0 +32,1 @@ + last1 = S.getLast . foldMap1 S.Last @@ -33,4 +34,1 @@ - last1 :: Foldable1 f => f a -> a - last1 = S.getLast . foldMap1 S.Last - - foldr1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) + foldr1, foldl1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) @@ -38,2 +36,0 @@ - - foldl1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) New description: This is a proposal to add [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base {{{#!hs -- Data.Semigroup.Foldable class Foldable f => Foldable1 f where fold1 :: Semigroup m => f m -> m foldMap1 :: Semigroup m => (a -> m) -> f a -> m -- Possible methods head1 :: f a -> a last1 :: f a -> a toNonEmpty :: f a -> NonEmpty a }}} along with instances and function that are only valid for non-empty structures (details: [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49], [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github]) {{{#!hs import qualified Data.Semigroup as S minimum1, maximum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 = S.getMax . foldMap1 S.Max head1, last1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 = S.getLast . foldMap1 S.Last foldr1, foldl1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures is also a possibility. ---- Currently these are partial functions in `Foldable`. This proposal does '''not''' propose replacing partial `Foldable` functions. ---- I wanted to test the waters before submitting it to the libraries mailing list. This may be controversial but it gives us a path to avoid partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 10:12:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 10:12:24 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.d2244be4e2b1a7cdc033366c1510fd12@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Examples from [https://hackage.haskell.org/package/algebra-4.3/docs /Numeric-Algebra-Class.html alge][https://hackage.haskell.org/package/algebra-4.3/docs/Numeric- Additive-Class.html bra] package {{{#!hs class Additive r where (+) :: r -> r -> r sumWith1 :: Foldable1 f => (a -> r) -> f a -> r class Multiplicative r where (*) :: r -> r -> r productWith1 :: Foldable1 f => (a -> r) -> f a -> r }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 10:38:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 10:38:49 -0000 Subject: [GHC] #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure In-Reply-To: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> References: <045.35ccaaf3c29916eccad65d2da03768b1@haskell.org> Message-ID: <060.1a32e35a3df984888f637a3210c01b80@haskell.org> #13583: configure.ac: handle AR=, NM= and other flags as arguments to ./configure -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The above commit does nothing about the ld issue. I think the best of the terrible options before us would be to. 1. replace the logic which currently forces use of gold with a test looking for the broken bfd linker, falling off it is found. 2. add some logic to look at the value of`LD` and try adding the appropriate flag to the C compiler flags to ensure that it is used I don't know the best way for the user to disable (2), as distribution packagers will almost certainly want to do. I suppose a `--disable-ld- cflags` configure option might work, but it seems terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 11:59:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 11:59:25 -0000 Subject: [GHC] #13598: role annotation for newtype (partially?) ignored? In-Reply-To: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> References: <044.fac0f84ee354aa8e2d98b81815c7a6ea@haskell.org> Message-ID: <059.ba57482237e69895fdc4e9003aaf38cd@haskell.org> #13598: role annotation for newtype (partially?) ignored? -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): To be fair, someone pointed to me recently that the haddock documentation of the [https://www.stackage.org/haddock/lts-8.12/ghc-prim-0.5.0.0/GHC- Types.html#t:Coercible Coercible] class already says something with respect to this: {{{ The third kind of instance exists for every newtype NT = MkNT T and comes in two variants, namely instance Coercible a T => Coercible a NT instance Coercible T b => Coercible NT b This instance is only usable if the constructor MkNT is in scope. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 12:44:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 12:44:43 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.5b24751b576f93004bc5c2c3e658d344@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -9,1 +9,1 @@ - foldMap1 :: Semigroup m => (a -> m) -> f a -> m + foldMap1 :: Semigroup m => (a -> m) -> (f a -> m) New description: This is a proposal to add [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1] (non-empty `Foldable`) to base {{{#!hs -- Data.Semigroup.Foldable class Foldable f => Foldable1 f where fold1 :: Semigroup m => f m -> m foldMap1 :: Semigroup m => (a -> m) -> (f a -> m) -- Possible methods head1 :: f a -> a last1 :: f a -> a toNonEmpty :: f a -> NonEmpty a }}} along with instances and function that are only valid for non-empty structures (details: [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49], [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91ae3b2969/src/Data/Semigroup/Difference.hs github]) {{{#!hs import qualified Data.Semigroup as S minimum1, maximum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 = S.getMax . foldMap1 S.Max head1, last1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 = S.getLast . foldMap1 S.Last foldr1, foldl1 :: Foldable1 f => (a -> a -> a) -> (f a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} Adding `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures is also a possibility. ---- Currently these are partial functions in `Foldable`. This proposal does '''not''' propose replacing partial `Foldable` functions. ---- I wanted to test the waters before submitting it to the libraries mailing list. This may be controversial but it gives us a path to avoid partial functions in `Foldable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 13:24:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 13:24:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.e53afafda0812e1e4dec5d28b4b665f0@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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: | -------------------------------------+------------------------------------- Description changed by pacak: @@ -49,1 +49,1 @@ - This will either finish successfully with `"solving\n0.0"`, or will die + This will either finish successfully producing no output, or will die New description: The example below uses in-place copies (mostly to fix dependencies and to make it more self-contained) of `parallel` (modified), `unordered-containers` (modified), and `hashable`. Its behavior is nondeterministic, despite using only supposedly pure operations. Aforementioned aside, it only depends on `base` and `deepseq`, and there's no `unsafePtrEq` involved at all. The affected `fromListWith` uses `foldl'` to effect in-place `HashMap` updates using `unsafe{Thaw,Freeze}`. I don't see how references to intermediate versions of `HashMap` could possibly leak out, so in-place updates seem valid to me. Strictifying (or even `rnf`ing) the arguments to `unsafeInsertWith` doesn't help. The issue is reproducible with `-O0` on `HEAD` but not with `-O2`; On 8.0.2 and 7.10.1, it can also be reproduced with `-O2`. {{{ sum . map snd = sum . map snd . toList . fromListWith (+) }}} The above identity fails when the input contains values constructed using ''both'' memo combinators and parallel evaluation strategies. I have identified the in-place-update that needs to be replaced with copy-and-update to make things work―patch `unsafeInsertWith.go` in `unordered-containers-0.2.8.0/Data/HashMap/Strict.hs`, under the `BitmapIndexed` pattern as follows: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps to reproduce: {{{ git clone https://github.com/pacak/cuddly-bassoon && cd cuddly-bassoon cabal new-build dist-newstyle/build/gamebooksolver-0.1.0.0/build/gamebooksolver- solvebook02/gamebooksolver-solvebook02 }}} This will either finish successfully producing no output, or will die with an `error` from the `regroup` function in `src/Solver.hs`. Your machine must have at least 2 CPU cores to reproduce the problem; also it will not show up with `+RTS -N1`. This issue was first reported here: https://github.com/tibbe/unordered-containers/issues/147 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 15:07:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 15:07:21 -0000 Subject: [GHC] #13591: "*** Exception: expectJust showModule" in ghci with hs-boot In-Reply-To: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> References: <048.4105303e7c5be1146bae2ea14744bf92@haskell.org> Message-ID: <063.528734fc8ca98f770a05be4fedc03169@haskell.org> #13591: "*** Exception: expectJust showModule" in ghci with hs-boot -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: ghci hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): #9887 seems related, as it seems to be the main "consumer" of the function that causes this error. Handling the Nothing-case by returning True could mean that #9887 remains open for hs-boot files, but then I don't understand what exactly the test for {{{linkable}}} is supposed to accomplish in the first place. When trying to understand the involved code, I noticed that this seems to be a near-perfect example of boolean blindness. Where {{{isObjectLinkable}}} returns a Bool that might reflect pretty closely what the function's name suggests, the value is then "reinterpreted" without any explanation and exposed as {{{isModuleInterpreted}}}. Further, {{{showModule}}} passes the Bool to {{{showModMsg}}} where the argument then is called "recomp" (another reinterpretation): {{{ showModMsg dflags target recomp mod_summary = ... case target of HscInterpreted | recomp -> ... -- what we have here, really is: -- HscInterpreted | (isModuleInterpreted mod_summary) -> .. -- so we have two interpreted-flags? what? ... }}} At this point I have no idea anymore of what the supposed semantic of this Bool is anymore. All that said, doing {{{ isModuleInterpreted :: GhcMonad m => ModSummary -> m Bool isModuleInterpreted mod_summary = withSession $ \hsc_env -> case lookupUFM (hsc_HPT hsc_env) (ms_mod_name mod_summary) of Nothing -> panic "missing linkable" Just mod_info -> return $ case hm_linkable mod_info of Nothing -> True Just linkable -> not (isObjectLinkable linkable) }}} seems to be a quick fix for this. But it does not display something like {{{ Failed, modules loaded: First(First.o-boot), First, Second. }}} in the case that only First.hs-boot was compiled before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 15:16:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 15:16:04 -0000 Subject: [GHC] #13602: Pattern syntax in expression context must be clarified In-Reply-To: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> References: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> Message-ID: <059.39478cb3553a3c58f872a485e86a3793@haskell.org> #13602: Pattern syntax in expression context must be clarified -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Hello goldfire,\\ Well! it's OK.\\ But before, could you tell me which list of these two lists that makes good sense to you?\\ {{{f1 = [-4, -4, -3, -2, 0, 3, 8]}}}\\ {{{f2 = [-4, -4, -3, -2, 1, 3, 8]}}}\\ And tell me why? Maybe it just seems "logical" for you?\\ Explain your motivation :\\ The focus here is on an incomprehensible result (that makes no sense) of list comprehension in certain situations which I shall try to explain here.\\ Before I begin, I ask you to forget everything you've learned about the Haskell language. Erase everything from your memory and keep only the syntax of the language.\\ 1. What is a list comprehension\\ It allow many functions on lists to be defined in simple manner. It employs a syntax adapted from conventional mathematics for describing sets. The syntax is: {{{[exp | qual1 , ... , qualn]}}}\\ in which exp denotes an arbitrary expression, and a qualifier is either a boolean-valued expression or a generator. The forms for a generator we shall use is: {{{variable <- [list]}}}\\ The best way of explaining what list comprehensions do is to give some examples.\\ {{{ >[x * x | x <- [1..10], even x] [4,16,36,64,100] }}} This list comprehension reads: the list of values x * x, where x is drawn from the list [1..10] and x is even.\\ {{{ >[3 | j <- [1..4]] [3,3,3,3] >[ x | x <- [1..3], y <- ['a','b']] [1,1,2,2,3,3] >[(\x -> True) j | j <- [(\x -> x), (\y -> y+1)]] [True, True] >[(\x -> True) j | j <- ['"', '"']] [True, True] >[(\x -> True) j | j <- ['`', '`']] [True, True] > [(\x -> True) j | j <- [_ , _]] [True, True] }}} 2. A concrete example (chunk of Haskell code)\\ see above.\\ All this codes are correct codes and the compiler works fine.\\ 3. What GHC was doing with this code before today.\\ For some reason someone raised an exception when an "underscore" was in an expression (inside a generator of a list expression, as far as we are concerned here)\\ This is how the following code generates an error in GHC 7.6.3\\ {{{> [(\x -> True) j | j <- [_ , _]]}}} pattern syntax in expression context: _\\ And it does not make good sense.\\ Do you "see" that "it makes no sense"?\\ Imagine that someone removes the numeric value of the expression.\\ {{{ > [(\x -> True) j | j <- [1, 2]] }}} The compiler will report an error like "found numeric value in expression". This also makes no sense.\\ Do you "see" that?\\ Reverse the problem. May be that the error is justified. Then the underscore is badly used in the syntax and must be rewritten, I think.\\ 4. What GHC does with this code today.\\ Today, the error "pattern syntax..." no longer exists. Someone created Typed Holes. And now the error is "Found Typed Holes..." And this also makes no sense in the example above.\\ Reverse the problem, and rewrite the underscore syntax if justified.\\ 5. What you would like GHC to do with this code.\\ I do not know if at this point you understood this " it makes a no sense".\\ Well, avoid the compiler to provide results who makes no sense of course!.\\ one more thing.\\ Take a look in the book "Ada 2012" from Dr. John Barnes and see page 24-25 about some behaviour of C language or in the book "Ada 2005" from the same author and see page 24-25 too. It's amazing. Although not speaking of the same thing, I think you will understand the connection between these things.\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 15:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 15:21:21 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.e584e95e7055ea2b7a312ef5e9d7703a@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While playing around with the repro, I noticed that the issue is reproducible if the `unsafeUpdateM` is performed, even if the resulting `HashMap` doesn't refer to the old array. e.g., {{{#!hs go h k x s t@(BitmapIndexed b ary) | b .&. m == 0 = do let ary' = A.insert ary i $! leaf h k x return $! bitmapIndexedOrFull (b .|. m) ary' | otherwise = do st <- A.indexM ary i st' <- rnf x `seq` go h k x (s+bitsPerSubkey) st let !ary' = A.update ary i $! st' A.unsafeUpdateM ary i st' return $ BitmapIndexed b ary' where m = mask h s i = sparseIndex b m }}} I'm not yet sure whether this is a meaninfgul observation, but it is an observation nonetheless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 16:14:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 16:14:29 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.46955a5fdd1047d1fe2f0c75b4509a79@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 8.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => worksforme Comment: > But I bet you have a non-debug compiler; and that you have an in-scope set that does not include foo. Might that be it? That seems to be it! (Although I had a hard time fixing it because of a bug(?) in the recompilation checker: If you used `-dynamic-too` before, but forget it later, GHC will happily use old `TestPlugin.dyn_o/TestPlugin.o` files, so I kept seeing unchanged behaviour… will file a bug). Incidentially, why is this not an issue for `simplifyExpr` in `SimplCore` – I don’t see code there adding anything to the in-scope set? Or is it ok because that function is not going to do such elaborate things as applying rules anyways? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 16:24:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 16:24:45 -0000 Subject: [GHC] #13616: Old file used when later calls to GHC omit -dynamic-too Message-ID: <046.4bec74021614f0a20ca26f287cd9f516@haskell.org> #13616: Old file used when later calls to GHC omit -dynamic-too -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This may possibly only hurt few people who develop Plugins, but it is still quite annoying: If `ghc`, in `--make` mode, recompiles a plugin that it is going to use, but without `-dynamic-too`, it will create new `.dyn` and `.o` files, but it will happily use the old `.dyn_hs` or `.dyn_o` files that are still lying around. I guess the desired behavior is: If it determines that it needs the dynamically compiled version of some module, and it is recompiling the module, then it should complain instead of later either ungracefully falling over the missing `.dyn_o` file or – worse – using an old one. This script reproduces the issue: {{{ #!/bin/bash rm -f *.o *.hi *.dyn_o *.dyn_hi cat > Plugin.hs <<__END__ module Plugin where import GhcPlugins plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ _ = error "First version" __END__ cat > Code.hs <<__END__ {-# OPTIONS_GHC -O -fplugin Plugin #-} module Code where __END__ echo "No dynamic file found (fine, but the error message could be more helpful)" ghc -package ghc Code.hs -fforce-recomp echo "Compiling with -dynamic-too" ghc -dynamic-too -package ghc Code.hs -fforce-recomp cat > Plugin.hs <<__END__ module Plugin where import GhcPlugins plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ _ = error "Second version" __END__ echo "Recompiling without -dynamic-too, it still uses the old file" ghc -package ghc Code.hs -fforce-recomp echo "Recompiling with -dynamic-too, now it works" ghc -dynamic-too -package ghc Code.hs -fforce-recomp }}} And here is the slightly redacted output: {{{ $ ./repro.sh No dynamic file found (fine, but the error message could be more helpful) [1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o ) [2 of 2] Compiling Code ( Code.hs, Code.o ) : fatal: cannot find object file ‘./Plugin.dyn_o’ while linking an interpreted expression Compiling with -dynamic-too [1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o ) [2 of 2] Compiling Code ( Code.hs, Code.o ) ghc: panic! (the 'impossible' happened) First version Recompiling without -dynamic-too, it still uses the old file [1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o ) [2 of 2] Compiling Code ( Code.hs, Code.o ) ghc: panic! (the 'impossible' happened) First version Recompiling with -dynamic-too, now it works [1 of 2] Compiling Plugin ( Plugin.hs, Plugin.o ) [2 of 2] Compiling Code ( Code.hs, Code.o ) ghc: panic! (the 'impossible' happened) Second version }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 16:44:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 16:44:47 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.26a7d80dd11294ac44a328103b48a87e@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have confirmed that eliminating the use of `parMap` in `solve` eliminates the issue as does replacing `rdeepseq` with `rseq`. I don't know whether the use of the `memo` combinator contributes as runtime blows up when it is removed Both uses of `A.unsafeUpdateM` in `unsafeInsertWith` (one in the `BitmapIndexed` branch and one in the `Full` branch) are problematic. Replacing either one with `A.update` decreases the failure rate, but the rate is still non-zero. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 17:51:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 17:51:38 -0000 Subject: [GHC] #13541: Make it easier to use the gold linker In-Reply-To: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> References: <046.0b1321a637ed3292c60514e6510d2c09@haskell.org> Message-ID: <061.8d701621e0a4a581b18be08f3b4bb3a3@haskell.org> #13541: Make it easier to use the gold linker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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 Apr 26 17:59:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 17:59:13 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.3ee0a6d2ea47fc67e8e178c97eedc370@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 nomeata): * status: closed => new * resolution: worksforme => Comment: Ok, so this works fine for locally defined things. But I run into the same (or a similar) problem where rules attached to globally defined things do not fire. Here is my test file (with commented-out rule): {{{ {-# OPTIONS_GHC -O -fplugin TestPlugin #-} module Test where import GHC.Base (foldr) {- # RULES "foldr/id_mine" GHC.Base.foldr (:) [] = id #-} test :: [a] -> [a] test xs = map id xs }}} and here the plugin, with the fix from earlier: {{{ module TestPlugin where import System.Exit import Control.Monad import GhcPlugins import Simplify import CoreStats import SimplMonad import FamInstEnv import SimplEnv import OccurAnal -- Plugin boiler plate plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ (simpl:xs) = return $ simpl : pass : xs where pass = CoreDoPluginPass "Test" testPass -- The plugin testPass :: ModGuts -> CoreM ModGuts testPass guts = do let [expr] = [ e | NonRec v e <- mg_binds guts , occNameString (occName v) == "test" ] simplified_expression <- simplify guts expr putMsg $ text "Test" $$ nest 4 (hang (text "Before" <> colon) 4 (ppr expr)) $$ nest 4 (hang (text "After" <> colon) 4 (ppr simplified_expression)) liftIO $ exitFailure -- A simplifier simplify :: ModGuts -> CoreExpr -> CoreM CoreExpr simplify guts expr = do dflags <- getDynFlags let dflags' = dflags { ufVeryAggressive = True } us <- liftIO $ mkSplitUniqSupply 's' let sz = exprSize expr rule_base <- getRuleBase vis_orphs <- getVisibleOrphanMods let rule_base2 = extendRuleBaseList rule_base (mg_rules guts) let rule_env = RuleEnv rule_base2 vis_orphs let top_lvls = bindersOfBinds (mg_binds guts) (expr', _) <- liftIO $ initSmpl dflags' rule_env emptyFamInstEnvs us sz $ do simplExpr (simplEnv top_lvls 1) (occurAnalyseExpr expr) return expr' simplEnv :: [Var] -> Int -> SimplEnv simplEnv vars p = env1 where env1 = addNewInScopeIds env0 vars env0 = mkSimplEnv $ SimplMode { sm_names = ["Test"] , sm_phase = Phase p , sm_rules = True , sm_inline = True , sm_eta_expand = True , sm_case_case = True } }}} If I run this I get: {{{ $ ghc-head -O -dynamic-too -package ghc Test.hs -fforce-recomp [1 of 2] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) Test Before: \ (@ a) (xs :: [a]) -> GHC.Base.build @ a (\ (@ b1) (c [OS=OneShot] :: a -> b1 -> b1) (n [OS=OneShot] :: b1) -> GHC.Base.foldr @ a @ b1 c n xs) After: \ (@ a) (xs :: [a]) -> GHC.Base.foldr @ a @ [a] (GHC.Types.: @ a) (GHC.Types.[] @ a) xs }}} Note that `GHC.Base.foldr` is still there in the `After:`: expression, despite the `foldr/id` rule in `GHC.Base`, which should simplify this code! If I add that rule to my module (as hinted at above), it does fire: {{{ $ ghc-head -O -dynamic-too -package ghc Test.hs -fforce-recomp [1 of 2] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) Test Before: \ (@ a) (xs :: [a]) -> GHC.Base.build @ a (\ (@ b1) (c [OS=OneShot] :: a -> b1 -> b1) (n [OS=OneShot] :: b1) -> GHC.Base.foldr @ a @ b1 c n xs) After: \ (@ a) (xs :: [a]) -> xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 18:09:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 18:09:27 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.431535cc64c719384ec02c2c3133e5a0@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So it appears that the intermediate mutable arrays from `unsafeInsertWith` are somehow "leaking" out of the fold. Consider this variant of `unsafeInsertWith`'s `BitIndexed` codepath, {{{#!hs go h k x s (BitmapIndexed b ary) | b .&. m == 0 = do let ary' = A.insert ary i $! leaf h k x return $! bitmapIndexedOrFull (b .|. m) ary' | otherwise = do st <- A.indexM ary i st' <- ({-# SCC "hi3" #-}rnf x) `seq` go h k x (s+bitsPerSubkey) st let !ary' = A.update ary i $! st' A.unsafeUpdateM ary i (error "fiddlesticks") return $ BitmapIndexed b ary' where m = mask h s i = sparseIndex b m }}} Now, as far as I can tell, if no one has kept any references to the `HashMap` that `unsafeInsertWith` is inserting into there should be no way that we enter `error "fiddlesticks"`. Afterall, the array `ary` is dead after we finish evaluating `go`. However, in actuality this doesn't appear to be true: `fiddlesticks` is indeed entered! Namely, it is forced by the `rnf` at the beginning of `unsafeInsertWith`. {{{#!hs unsafeInsertWith f k0 v0 m0 = ({-# SCC "top" #-}rnf m0) `seq` runST (go h0 k0 v0 0 m0) }}} Now this is quite strange as it means that either, a. a reference to the old `ary` is somehow leaking out of `go` b. there are multiple references to `ary` scattered throughout the `HashMap` It's not immediately obvious how either of these could be true, but the facts don't lie. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 19:16:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 19:16:21 -0000 Subject: [GHC] #13617: Segfault in Windows GHCi involving C code compiled with -O4 Message-ID: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> #13617: Segfault in Windows GHCi involving C code compiled with -O4 ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following: {{{ $ git clone https://github.com/RyanGlScott/hmatrix-segfault $ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5 $ cd hmatrix-segfault/ $ cabal install $ runghc exe/Main.hs Access violation in generated code when reading ffffffffffffffff }}} Running `Main.hs` in GHCi crashes, whereas compiling it works: {{{ $ ghc exe/Main.hs $ ./exe/Main.exe [1,1,1,1,1,1,1,1,1,1,1,1] }}} I've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1. There are a couple of things that appear to be necessary to trigger the segfault: 1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`. 2. You need to define the [https://github.com/RyanGlScott/hmatrix- segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38 FunCodeS] datatype. Removing either of these things causes the program to work again under GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 19:31:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 19:31:47 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.5cc8c78c5fed95fbb28fffafd89f7728@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hypothesis: `thawArray#` is to blame. Falsified by falling back to `__GLASGOW_HAKSELL__ < 702` codepath in `Data.HashMap.Array.thaw`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 20:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 20:55:17 -0000 Subject: [GHC] #13618: Reified data family instances type variables not related to value constructor fields Message-ID: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> #13618: Reified data family instances type variables not related to value constructor fields -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 (Type checker) | 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: -------------------------------------+------------------------------------- When using the reify template-haskell operation on a data family, the returned data instances lose the relationship between the type variables in the parameters and those in the value constructors. In this paste I show that reify forgets the relationship, but that declaration splices preserve it. Note the two occurrences of a_6989586621679027007 . I would specifically expect the occurences of a_6989586621679015819 and a_6989586621679015790 to be the same. The code that implements this reification is in compiler/typecheck/TcSplice.hs , the template-haskell package merely exposes the functionality, so this is why I've specified "compiler (type checker)" I've confirmed that this bug exists in GHC 8.0.2 and 8.2.1-rc1. I suspect it exists in older versions, too. {{{#!haskell $ /Users/emertens/Tools/ghc-8.2.1-rc1/bin/ghci GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeFamilies Prelude> :set -XTemplateHaskell Prelude> import Language.Haskell.TH Prelude Language.Haskell.TH> import Text.Show.Pretty (ppShow) Prelude Language.Haskell.TH Text.Show.Pretty> data family DF a; data instance DF [a] = DFList a Prelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< reify ''DF) FamilyI (DataFamilyD Ghci1.DF [ KindedTV a_6989586621679015789 StarT ] (Just StarT)) [ DataInstD [] Ghci1.DF [ AppT ListT (VarT a_6989586621679015819) ] Nothing [ NormalC Ghci1.DFList [ ( Bang NoSourceUnpackedness NoSourceStrictness , VarT a_6989586621679015790 ) ] ] [] ] Prelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< [d| data family DF a; data instance DF [a] = DFList a |]) [ DataFamilyD DF_6989586621679027004 [ PlainTV a_6989586621679027006 ] Nothing , DataInstD [] DF_6989586621679027004 [ AppT ListT (VarT a_6989586621679027007) ] Nothing [ NormalC DFList_6989586621679027005 [ ( Bang NoSourceUnpackedness NoSourceStrictness , VarT a_6989586621679027007 ) ] ] [] ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:00:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:00:55 -0000 Subject: [GHC] #13619: hsc2hs parses incorrectly c99 style ("/// ...") comments in '--cross-compile' mode Message-ID: <045.97eab08bb959837363779f6598f1d3ed@haskell.org> #13619: hsc2hs parses incorrectly c99 style ("/// ...") comments in '--cross- compile' mode -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | 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 code is simplified version of something from Win32 package (https://github.com/haskell/win32/blob/master/Graphics/Win32/GDI/Pen.hsc#L59): {{{#!hs -- a.hsc #{enum Int , // "hi" there! , a = sizeof(int) } }}} {{{ $ hsc2hs a.hsc -o a.hs-cross --cross-compile $ hsc2hs a.hsc -o a.hs-native }}} {{{#!diff --- a.hs-cross 2017-04-26 21:56:56.157323964 +0100 +++ a.hs-native 2017-04-26 21:57:00.753311717 +0100 @@ -2,3 +2,3 @@ a :: Int -a = // "hi" there! 4 +a = 4 }}} I'm not sure if it's a valid .hsc but having at least the same (valid or invalid) result in both modes would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:12:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:12:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.4c613b792372c0df1507ea9c46efa0ad@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I've also tested with `-fno-full-laziness`; the issue persists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:23:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:23:49 -0000 Subject: [GHC] #13620: hsc2hs parses incorrectly '#ifdef' under '#{enum' in '--cross-compile' mode Message-ID: <045.55bb49e2522877c4e792974e9d747ed9@haskell.org> #13620: hsc2hs parses incorrectly '#ifdef' under '#{enum' in '--cross-compile' mode -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | 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 code is simplified version of something from Win32 package (https://github.com/haskell/win32/blob/master/System/Win32/SimpleMAPI.hsc#L56): {{{#!hs #{enum Int , , a = sizeof(int) #if 0 , b = sizeof(char) #endif } }}} {{{ $ hsc2hs b.hsc -o b.hs-native $ hsc2hs b.hsc -o b.hs-cross --cross-compile b.hsc:1 sizeof(int) #if 0 is not an integer }}} I'm not sure if it's a valid .hsc but having at least the same (valid or invalid) result in both modes would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:46:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:46:10 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.bca67dfe1589efe9e66b546d414bd39c@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I wonder if you have ensured that `GHC.Base` is loaded? If the interface is not loaded, GHC won't see the rule. Check what you get in the intial rule-base -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:50:52 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.f127d2f0b9b411d1d3b8e76e59f496c6@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 nomeata): > I wonder if you have ensured that GHC.Base is loaded? If the interface is not loaded, GHC won't see the rule. Yes, `GHC.Base` is loaded. I was under the impression that (non-orphan) rules are attached to the `ID`, so should it matter? Or is that only true for locally defined rules? Or is `GHC.Base` special in that matter? In the above plugin code, the result of `getRuleBase` is indeed empty, and so is `mg_rules guts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:53:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:53:25 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.e1becc8666a24eafc639486c4f8081a9@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You'll have to look at the code, but only locally-defined Ids have their rules attached. The rest are in a global database (the rule-base). I can't explain why it's empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 21:59:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 21:59:55 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.47e0d66ede14f22ffec07079b42b7bda@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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 nomeata): > You'll have to look at the code, but only locally-defined Ids have their rules attached. The rest are in a global database (the rule-base) Ah, thanks for clearing that up for me. I always assumed that the rule base is only for orphan rules. Now I know where to look, and will hopefully find out what’s wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 26 22:53:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Apr 2017 22:53:35 -0000 Subject: [GHC] #13614: Rewrite rules not applied exhaustively when simplifying from plugin In-Reply-To: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> References: <046.6c4fad35ecda60184dee66d5540739e2@haskell.org> Message-ID: <061.a514e9e4d48e09586c4bef7b15315be4@haskell.org> #13614: Rewrite rules not applied exhaustively when simplifying from plugin -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 8.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => worksforme Comment: Ok, it seems that `CoreM`’s `getRuleBase` only returns the rules from the current home package. To get the rules from the external package, I have to use `getHscEnv`: {{{ hpt_rule_base <- getRuleBase hsc_env <- getHscEnv eps <- liftIO $ hscEPS hsc_env let rule_base1 = unionRuleBase hpt_rule_base (eps_rule_base eps) rule_base2 = extendRuleBaseList rule_base1 (mg_rules guts) vis_orphs <- getVisibleOrphanMods let rule_env = RuleEnv rule_base2 vis_orphs }}} Thanks for your help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 00:09:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 00:09:42 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.a2128d64f4d16ed808fcdb1504e81cb7@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer): Simon, I rebased your branch and fixed a comment, producing `wip/dfeuer-T13397`. The [https://perf.haskell.org/ghc/#compare/583fa9e3687b49d8c779e6d53a75af9276e4f5cf/a2df49f25cd8c332d0e9bb409428db566378eee2 perf results] generally look fine, with a few very small regressions: {{{ Nofib allocations ----------------- knights +1.35% pic +1.14% scs +0.81% (this ran slightly *faster*) last-piece +0.29% Nofib runtimes -------------- cacheprof +1.3% last-piece +1.23% hidden +1.08% wheel-sieve1 +0.95% digits-of-e1 +0.87% lambda +0.47% Test suite allocations ---------------------- T783 +0.59% T9675 +0.33% T12707 +0.23% }}} The wins seem modest, but bigger than the regressions: {{{ Nofib allocations ----------------- anna -0.7% fft -0.41% Nofib runtimes -------------- cryptarithm1 -4.29% fannkuch-redux -3.75% binary-trees -3.7% scs -1.28% integer -1% fasta -0.98% mate -0.95% digits-of-e2 -0.85% }}} As far as I'm concerned, this should probably be ready to merge. Should I do so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 00:10:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 00:10:42 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.63e58ecf57d14f83f05ad3d3dbdbcb06@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 00:15:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 00:15:28 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.2cf642a0ebf831a9a1c98d18ff28eb79@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 pacak): {{{ gamebooksolver-solvebook02: Those are expected to be equal(6030,6030) GHC has an interesting sense of equality }}} Code that generates this error looks like this and both `s'` and `s` are `Int`s. {{{ if s' /= s then error $ "Those are expected to be equal" ++ show (s', s) else xs' }}} I don't see how that's possible unless `Eq` instance for `Int` gets corrupted somehow. If that's the case - it also might mean `Num` instance is bogus as well and that results in wrong sum. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 00:23:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 00:23:10 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.76f3e36342cb393182766510810aecf3@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 pacak): I've confirmed that ghc has an interesting sense of equality: {{{ regroup :: (NFData a, Show a, Hashable a, Eq a, Ord a) => [(a, Int)] -> [(a, Int)] regroup xs = let xs' = HM.toList $ HM.fromListWith (+) xs s' = sum (map snd xs') s = sum (map snd xs) in if s' /= s then if show s' == show s then error "WAT????" else error $ "Those are expected to be equal" ++ show (s', s) else xs' }}} {{{ gamebooksolver-solvebook02: Those are expected to be equal(141,121) CallStack (from HasCallStack): error, called at src/Main.hs:50:26 in main:Main gamebooksolver-solvebook02: Those are expected to be equal(384,300) CallStack (from HasCallStack): error, called at src/Main.hs:50:26 in main:Main gamebooksolver-solvebook02: Those are expected to be equal(1045,1045) CallStack (from HasCallStack): error, called at src/Main.hs:50:26 in main:Main gamebooksolver-solvebook02: WAT???? CallStack (from HasCallStack): error, called at src/Main.hs:49:26 in main:Main gamebooksolver-solvebook02: WAT???? CallStack (from HasCallStack): error, called at src/Main.hs:49:26 in main:Main gamebooksolver-solvebook02: WAT???? CallStack (from HasCallStack): error, called at src/Main.hs:49:26 in main:Main }}} Actually it's even worse, note third error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 00:50:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 00:50:00 -0000 Subject: [GHC] #13618: Reified data family instances type variables not related to value constructor fields In-Reply-To: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> References: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> Message-ID: <059.184d788d919446abe878d660741afb74@haskell.org> #13618: Reified data family instances type variables not related to value constructor fields -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc1 checker) | 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): Phab:D3505 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3505 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 01:15:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 01:15:13 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.763f921d32df923fd40c45edcd5a02e1@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I have also observed similar insanity to comment:16. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 01:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 01:37:04 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.03ce77c474e36a3e1af1cdc698c5e07c@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Note that the probability of seeing the issue increases markedly if `regroup` is defined as, {{{#!hs regroup :: (NFData a, Show a, Hashable a, Eq a, Ord a) => [(a, Int)] -> [(a, Int)] regroup xs0 = let xs = map (\(x,y) -> (x, y+1)) xs0 xs' = HM.toList $ HM.fromListWith (+) xs s' = sum (map snd xs') s = sum (map snd xs) in if s' /= s then if show s' == show s then error "WAT????" else error $ "Those are expected to be equal" ++ show (s', s) else xs' }}} It appears that elements are getting dropped from the list inspected by `fromListWith` (which is why the `(+1)` makes the issue easier to see: you won't notice if you drop a zero from a sum) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 01:38:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 01:38:32 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.f4ebdd90d6fedff84e2107057d1bc1bd@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `-feager-blackholing` also makes no difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 01:58:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 01:58:59 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.f2925fd072ae5121521575597dac46cc@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So perhaps we are entering a closure twice and consequently get a race condition where one thread in-place increments a hashtable entry by `x`, then the other does the same, but uses the now already incremented hashtable, resulting in an overall contribution of `2*x`. This explains why the hashtable sum is always larger than the expected result. While it's not clear precisely what closure we are entering multiple times, the fix is clear: ensure that `unordered-containers` is compiled with `-feager-blackholing`. However, we should also (at very least) document this caveat better. The users-guide current advertises `-feager- blackholing` as a optimization to avoid redundant computation in parallel programs. However, in this case that it's absolutely critical for correctness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 02:20:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 02:20:08 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.c5671be2347c43e215b4930976382071@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For future reference, the `-feager-blackholing` flag was introduced in GHC 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 02:33:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 02:33:03 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.32db28704b3ffa0cf80836c3749e9242@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 akio): `-feager-blackholing` does not eliminate the race completely, right? I thought you needed a call to `noDuplicate#` in order to guarantee single entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 02:51:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 02:51:20 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.158683cffde1c6f513e5efef6293ee2c@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed you may be right; I'll need to try to work out precisely where the multiple entry is occurring tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 03:11:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 03:11:24 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.9a35b22021eea292db1d21a7bbf9ea9d@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293, | Differential Rev(s): #13059, #10818 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 8.4.1 => 8.2.1 Comment: This appears to be fixed in HEAD, but I haven't checked the 8.2 release. I checked both the reproduction in comment:22 and the Cabal module that originally triggered this. I don't know why I didn't check that before going digging through history. Whoops. I'll add a perf test case based on Edward's reproduction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 09:30:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 09:30:10 -0000 Subject: [GHC] #13621: Problems with injective type families Message-ID: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> #13621: Problems with injective type families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple InjectiveFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE GADTs, TypeInType, DataKinds, TypeFamilyDependencies #-} import Data.Kind type family IB a = res | res -> a where IB Int = Bool IB Bool = Int type Cat k = k -> k -> Type data F :: Cat Type where F :: (a -> IB a) -> F a (IB a) data Exp :: Type -> Type where I :: Int -> Exp Int B :: Bool -> Exp Bool fmap' :: F a b -> (Exp a -> Exp b) fmap' (F f) = \case B b -> I (f b) I i -> B (f i) }}} I would have thought this should work as well, given that `IB` is injective: {{{#!hs data F :: Cat Type where F :: (IB a -> a) -> F (IB a) a }}} but it gives {{{#!hs fmap' :: F a b -> (Exp a -> Exp b) fmap' (F f) = \case B b -> I (f b) -- c.hs:33:13: error: -- • Could not deduce: b ~ Int -- from the context: a ~ IB b -- bound by a pattern with constructor: -- F :: forall a. (IB a -> a) -> F (IB a) a, -- in an equation for ‘fmap'’ -- at c.hs:32:8-10 -- or from: a ~ Bool -- bound by a pattern with constructor: B :: Bool -> Exp Bool, -- in a case alternative -- at c.hs:33:3-5 -- ‘b’ is a rigid type variable bound by -- the type signature for: -- fmap' :: forall a b. F a b -> Exp a -> Exp b -- at c.hs:31:10 -- • In the first argument of ‘I’, namely ‘(f b)’ -- In the expression: I (f b) -- In a case alternative: B b -> I (f b) -- • Relevant bindings include -- f :: IB b -> b (bound at c.hs:32:10) -- fmap' :: F a b -> Exp a -> Exp b (bound at c.hs:32:1) -- Failed, modules loaded: none. }}} But if we know that `a ~ Bool` (as we do from matching on `B`), and we know that `a ~ IB b` then by injectivity it should figure that `b ~ Int`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 10:10:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 10:10:55 -0000 Subject: [GHC] #3781: Improve inlining for local functions In-Reply-To: <046.7e7e45262f788675411974bac0244395@haskell.org> References: <046.7e7e45262f788675411974bac0244395@haskell.org> Message-ID: <061.bf6d6dd63e1095661d0c14977cc4c702@haskell.org> #3781: Improve inlining for local functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #3755, #7664 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 12:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 12:22:19 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.75c44b264c9a768c538bb7b57dc6e06f@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 simonpj): Why does it matter if we evaluate the same thunk twice? I'm lost. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 12:56:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 12:56:33 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.46b10aeefe39cf5bb8a26b78f387c341@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Why does it matter if we evaluate the same thunk twice? I'm lost. Well, I'm still not entirely certain what the problematic thunk looks like, but the program in question *does* rely on in-place modification of an array which would break if performed more than once. I believe the problem revolves around `Data.HashMap.Strict.unsafeInsertWith`, which, to paraphrase, does the following, {{{#!hs unsafeInsertWith :: (v -> v -> v) -> k -> v -> HashMap k v -> HashMap k v unsafeInsertWith f k v (HashMap arr) = runST $ do marr <- unsafeThawArray# arr let some_index = {- some function of k -} old_v <- readArray# marr some_index writeArray# marr some_index (f old_v v) _ <- unsafeFreezeArray# marr return (HashMap arr) }}} That is, despite being a "pure" function, `unsafeInsertWith` take the array out of the `HashMap` which it was given, thaws it, modifies it, freezes it again, and then returns the same array as a "new" result. This means that if we have a thunk `unsafeInsertWith some_key some_value hm` which we enter twice, the multiple entry will be observable through the fact that the array element at `some_index` will be `f v (f v old_v)`, instead of `f v old_v` as was intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 13:04:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 13:04:18 -0000 Subject: [GHC] #13621: Problems with injective type families In-Reply-To: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> References: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> Message-ID: <066.dfef5cd4cc11ccd71e2029166b8a3841@haskell.org> #13621: Problems with injective type families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies Operating System: 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): No, injectivity can't yet do this. Injectivity annotations are very much like functional dependencies, working only to do type inference. They have no representation in Core. Why not, you ask? Because I was unable to prove the soundness of doing so. But perhaps [http://cs.brynmawr.edu/~rae/papers/2017/partiality/partiality.pdf Constrained Type Families] gives us a way forward here. I have yet to attempt the injectivity proof in the context of that paper, but my hunch is that it will succeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 13:16:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 13:16:19 -0000 Subject: [GHC] #13621: Problems with injective type families In-Reply-To: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> References: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> Message-ID: <066.77aa63628e66213645b5619587b8eb62@haskell.org> #13621: Problems with injective type families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies Operating System: 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): Sounds promising, should the ticket be kept open? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 14:44:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 14:44:04 -0000 Subject: [GHC] #13621: Problems with injective type families In-Reply-To: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> References: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> Message-ID: <066.2b3d03f51cfab2c33000d38fb89d54a5@haskell.org> #13621: Problems with injective type families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies 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): * type: bug => feature request Comment: As a feature request, sure. But don't hold your breath! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 15:01:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 15:01:53 -0000 Subject: [GHC] #13621: Problems with injective type families In-Reply-To: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> References: <051.8b28c91f9a3ebc698fd782bfaaee4159@haskell.org> Message-ID: <066.5713d9f095656d6878137b5aa2cc89d5@haskell.org> #13621: Problems with injective type families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | InjectiveFamilies Operating System: 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): Too late! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 15:48:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 15:48:22 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.7416c8f9475d7df576879db30cb02849@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've put this aside for now. The current state of things is, * My current theory is that a closure is being entered multiple times, resulting in repeated observable mutation. It's still not entirely clear precisely which closure is being entered multiple times, but the evidence before us is consistent with the multiple mutation hypothesis. * compiling `unordered-containers` with `-feager-blackholing` appears to resolve the issue, however I'm pretty certain that this is merely shrinking the race window, not eliminating it altogether. * adding a `noDuplicate#` (e.g. see https://github.com/bgamari/unordered- containers/commit/bf799b2a00da8c78ac78d818de8f1963c7ff87ad) at the beginning of `unsafeInsertWith` also resolves the issue, even with lazy blackholing enabled. However, this seems like a very large hammer to place in an inner loop like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 16:23:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 16:23:11 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.6da9abbcfd178dbf38f4917c6846700a@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:14 MikolajKonarski]: > > In HEAD [...] the time problem has moved. Now, the long iteration is the very first one after desugaring > > May it have anything to do with the "early inlining" changes? Simon thinks so. And he thinks this whole problem has to do with simplifying the same expressions many times. Simon, have you worked out how to fix this yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 16:35:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 16:35:46 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.fc255fb5f9f7bee8fa1c1d174dbeed97@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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): In principle yes. But although +0.59% allocation in T783, say isn't important enough to prevent using is, it'd be good to know why it happened. Maybe there's something simple going wrong that would be easily fixed? Or maybe it's one of those things like "with the change, f becomes small enough to inline into g, so g becomes too big to inline at its call sites and that makes the difference". If so, fine. But it'd be good to know. I find `-ticky` lets you nail the changes really fast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 16:49:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 16:49:43 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.167c2ce95458a318a1b93f8f7f2bbc92@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, just validating -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 17:12:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 17:12:05 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope Message-ID: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I ran into this regression when trying to compile the `ersatz` library with GHC 8.2.1-rc1. Here is a minimized example: {{{#!hs module Bug (Bits(Bits)) where import qualified Data.Bits as Bits newtype Bits = Bits Int }}} Compiling this with GHC 8.0.2 works fine, but with 8.2.1-rc1, you get this error: {{{ l$ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170422: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:1:13: error: • Ambiguous occurrence ‘Bits’ It could refer to either ‘Bits.Bits’, imported qualified from ‘Data.Bits’ at Bug.hs:3:1-34 or ‘Bits’, defined at Bug.hs:5:1 • In the export: Bits(Bits) | 1 | module Bug (Bits(Bits)) where | ^^^^^^^^^^ }}} Despite the fact that `Bits` isn't actually ambiguous, since the `Bits` from `Data.Bits` is qualified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 18:14:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 18:14:11 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.26d4c86c287a471c957092a7f7a1ecee@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Iceland_jack): That example could be featured in a children's book -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 18:33:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 18:33:22 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.2763d6de76785ff3810b58af8a7066e9@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lehins): For what it's worth, I figured out a reliable way to avoid the bug, namely adding an extra constraint `Array X e`. So changing the type signature of `correlate` to: `correlate :: (Array X e, Array cs e) => Image X e -> Image cs e -> Image cs e` can be used as a trick for working around the bug. Not sure if it is relevant, but maybe it will help in narrowing down a possible cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 18:50:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 18:50:04 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.e3023e7b86af3f2dba452b302c0dbee7@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 mpickering): Does it work with HEAD? I think I fixed this in #13528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 20:12:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 20:12:06 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.278cf68ff15588437facf5bb31e6aece@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13603 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:4 merged in 1bc7429d921ae8a1c82773b9c6dde0395d1514d4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 20:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 20:14:16 -0000 Subject: [GHC] #13611: Segfault due to levity polymorphism of mkWeak# In-Reply-To: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> References: <046.fa4b464ab8f650f009b14e596717e8a5@haskell.org> Message-ID: <061.00905b95487d1a04976c73a5ac0838c7@haskell.org> #13611: Segfault due to levity polymorphism of mkWeak# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3498 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 933fb440ad4adba542975fc5d8b46c1f666ff2ce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 20:14:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 20:14:28 -0000 Subject: [GHC] #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file In-Reply-To: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> References: <046.fd1f62ec7929e2ce13ae8d85f55aac4b@haskell.org> Message-ID: <061.b9826f71e179d10bf401d196435046f6@haskell.org> #13560: Windows binary distributions have absolute paths from the build environment in the `settings` file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 8ef9716f8f085a4276e95d099e0ffb7343388639 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 20:15:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 20:15:00 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.01bc4db6e723a03d78d28aca9a0a1534@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I experience the same bug with GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 23:10:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 23:10:34 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion Message-ID: <048.123971708b7ce58829cc065941274f85@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- Below, I am generating to stream fusion streams xs and ys. Both parameterized on k l. The two streams are then concatenated. Finally I do a strict left fold. This example needs the 'vector' package but nothing else. {{{ module Test where import Data.Vector.Fusion.Stream.Monadic as S foo :: Int -> Int -> IO Int foo = \i j -> S.foldl' (+) 0 $ xs i j S.++ ys i j where xs k l = S.enumFromStepN k l 2 ys k l = S.enumFromStepN k l 3 {-# Inline xs #-} {-# Inline ys #-} {-# Inline foo #-} }}} With ghc-8.0.1 I get nice core: {{{ $wfoo_r1Ai $wfoo_r1Ai = \ ww_s1q5 ww1_s1q9 w_s1q2 -> letrec { $s$wfoldlM'_loop_s1xc $s$wfoldlM'_loop_s1xc = \ sc_s1x7 sc1_s1x5 sc2_s1x6 sc3_s1x4 -> case tagToEnum# (># sc2_s1x6 0#) of _ { False -> (# sc_s1x7, I# sc3_s1x4 #); True -> $s$wfoldlM'_loop_s1xc sc_s1x7 (+# sc1_s1x5 ww1_s1q9) (-# sc2_s1x6 1#) (+# sc3_s1x4 sc1_s1x5) }; } in letrec { $s$wfoldlM'_loop1_s1x3 $s$wfoldlM'_loop1_s1x3 = \ sc_s1x2 sc1_s1x0 sc2_s1x1 sc3_s1wZ -> case tagToEnum# (># sc2_s1x1 0#) of _ { False -> $s$wfoldlM'_loop_s1xc sc_s1x2 ww_s1q5 3# sc3_s1wZ; True -> $s$wfoldlM'_loop1_s1x3 sc_s1x2 (+# sc1_s1x0 ww1_s1q9) (-# sc2_s1x1 1#) (+# sc3_s1wZ sc1_s1x0) }; } in $s$wfoldlM'_loop1_s1x3 w_s1q2 ww_s1q5 2# 0# }}} Now the same with ghc-8.2-rc1. Here, [https://github.com/haskell/vector/blob/master/Data/Vector/Fusion/Stream/Monadic.hs Stream.++] function is not fully optimized away (Left and Right constructors!). Instead we have a join point that executes either of the two parts (xs or ys) based on a case w2_s1U2 of {Left -> ; Right ->}. {{{ $wfoo_r23R $wfoo_r23R = \ ww_s1Ue ww1_s1Ui w_s1Ub -> let { x1_a1tj x1_a1tj = I# ww_s1Ue } in let { tb_a1wC tb_a1wC = (x1_a1tj, lvl1_r23Q) } in let { lvl2_s1Yh lvl2_s1Yh = Right tb_a1wC } in joinrec { $wfoldlM'_loop_s1U8 $wfoldlM'_loop_s1U8 w1_s1U0 ww2_s1U6 w2_s1U2 w3_s1U3 = case w1_s1U0 of { __DEFAULT -> case w2_s1U2 of { Left sa_a1yP -> case sa_a1yP of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> jump $wfoldlM'_loop_s1U8 SPEC ww2_s1U6 lvl2_s1Yh w3_s1U3; True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Left (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } }; Right sb_a1z3 -> case sb_a1z3 of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> (# w3_s1U3, I# ww2_s1U6 #); True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Right (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } } } }; } in jump $wfoldlM'_loop_s1U8 SPEC 0# (Left (x1_a1tj, lvl_r23P)) w_s1Ub }}} For my stream-fusion heavy code, this yields a slowdown of approximately x4 (10 seconds with ghc-8.2-rc1, 2.5 seconds with ghc-8.0.1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 23:14:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 23:14:27 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.90a0cf2a6ea6bf350f7879e09bb144ab@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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): * cc: lukemauer (added) * priority: normal => high * milestone: => 8.2.1 @@ -7,1 +7,1 @@ - {{{ + {{{#!hs @@ -24,1 +24,1 @@ - {{{ + {{{#!hs @@ -61,1 +61,1 @@ - two parts (xs or ys) based on a case w2_s1U2 of {Left -> ; Right ->}. + two parts (xs or ys) based on a `case w2_s1U2 of {Left -> ; Right ->}`. @@ -63,1 +63,1 @@ - {{{ + {{{#!hs New description: Below, I am generating to stream fusion streams xs and ys. Both parameterized on k l. The two streams are then concatenated. Finally I do a strict left fold. This example needs the 'vector' package but nothing else. {{{#!hs module Test where import Data.Vector.Fusion.Stream.Monadic as S foo :: Int -> Int -> IO Int foo = \i j -> S.foldl' (+) 0 $ xs i j S.++ ys i j where xs k l = S.enumFromStepN k l 2 ys k l = S.enumFromStepN k l 3 {-# Inline xs #-} {-# Inline ys #-} {-# Inline foo #-} }}} With ghc-8.0.1 I get nice core: {{{#!hs $wfoo_r1Ai $wfoo_r1Ai = \ ww_s1q5 ww1_s1q9 w_s1q2 -> letrec { $s$wfoldlM'_loop_s1xc $s$wfoldlM'_loop_s1xc = \ sc_s1x7 sc1_s1x5 sc2_s1x6 sc3_s1x4 -> case tagToEnum# (># sc2_s1x6 0#) of _ { False -> (# sc_s1x7, I# sc3_s1x4 #); True -> $s$wfoldlM'_loop_s1xc sc_s1x7 (+# sc1_s1x5 ww1_s1q9) (-# sc2_s1x6 1#) (+# sc3_s1x4 sc1_s1x5) }; } in letrec { $s$wfoldlM'_loop1_s1x3 $s$wfoldlM'_loop1_s1x3 = \ sc_s1x2 sc1_s1x0 sc2_s1x1 sc3_s1wZ -> case tagToEnum# (># sc2_s1x1 0#) of _ { False -> $s$wfoldlM'_loop_s1xc sc_s1x2 ww_s1q5 3# sc3_s1wZ; True -> $s$wfoldlM'_loop1_s1x3 sc_s1x2 (+# sc1_s1x0 ww1_s1q9) (-# sc2_s1x1 1#) (+# sc3_s1wZ sc1_s1x0) }; } in $s$wfoldlM'_loop1_s1x3 w_s1q2 ww_s1q5 2# 0# }}} Now the same with ghc-8.2-rc1. Here, [https://github.com/haskell/vector/blob/master/Data/Vector/Fusion/Stream/Monadic.hs Stream.++] function is not fully optimized away (Left and Right constructors!). Instead we have a join point that executes either of the two parts (xs or ys) based on a `case w2_s1U2 of {Left -> ; Right ->}`. {{{#!hs $wfoo_r23R $wfoo_r23R = \ ww_s1Ue ww1_s1Ui w_s1Ub -> let { x1_a1tj x1_a1tj = I# ww_s1Ue } in let { tb_a1wC tb_a1wC = (x1_a1tj, lvl1_r23Q) } in let { lvl2_s1Yh lvl2_s1Yh = Right tb_a1wC } in joinrec { $wfoldlM'_loop_s1U8 $wfoldlM'_loop_s1U8 w1_s1U0 ww2_s1U6 w2_s1U2 w3_s1U3 = case w1_s1U0 of { __DEFAULT -> case w2_s1U2 of { Left sa_a1yP -> case sa_a1yP of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> jump $wfoldlM'_loop_s1U8 SPEC ww2_s1U6 lvl2_s1Yh w3_s1U3; True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Left (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } }; Right sb_a1z3 -> case sb_a1z3 of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> (# w3_s1U3, I# ww2_s1U6 #); True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Right (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } } } }; } in jump $wfoldlM'_loop_s1U8 SPEC 0# (Left (x1_a1tj, lvl_r23P)) w_s1Ub }}} For my stream-fusion heavy code, this yields a slowdown of approximately x4 (10 seconds with ghc-8.2-rc1, 2.5 seconds with ghc-8.0.1). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 23:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 23:15:04 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.fed57e9f41228c2e13d117bd8ed719f0@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 23:16:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 23:16:12 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.219f32d4532e2fb007ecd5e0a6e6357f@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by choenerzs: @@ -122,0 +122,9 @@ + + === + + ghc-options: + -O2 + -ddump-to-file + -ddump-simpl + -dsuppress-all + -dshow-passes New description: Below, I am generating to stream fusion streams xs and ys. Both parameterized on k l. The two streams are then concatenated. Finally I do a strict left fold. This example needs the 'vector' package but nothing else. {{{#!hs module Test where import Data.Vector.Fusion.Stream.Monadic as S foo :: Int -> Int -> IO Int foo = \i j -> S.foldl' (+) 0 $ xs i j S.++ ys i j where xs k l = S.enumFromStepN k l 2 ys k l = S.enumFromStepN k l 3 {-# Inline xs #-} {-# Inline ys #-} {-# Inline foo #-} }}} With ghc-8.0.1 I get nice core: {{{#!hs $wfoo_r1Ai $wfoo_r1Ai = \ ww_s1q5 ww1_s1q9 w_s1q2 -> letrec { $s$wfoldlM'_loop_s1xc $s$wfoldlM'_loop_s1xc = \ sc_s1x7 sc1_s1x5 sc2_s1x6 sc3_s1x4 -> case tagToEnum# (># sc2_s1x6 0#) of _ { False -> (# sc_s1x7, I# sc3_s1x4 #); True -> $s$wfoldlM'_loop_s1xc sc_s1x7 (+# sc1_s1x5 ww1_s1q9) (-# sc2_s1x6 1#) (+# sc3_s1x4 sc1_s1x5) }; } in letrec { $s$wfoldlM'_loop1_s1x3 $s$wfoldlM'_loop1_s1x3 = \ sc_s1x2 sc1_s1x0 sc2_s1x1 sc3_s1wZ -> case tagToEnum# (># sc2_s1x1 0#) of _ { False -> $s$wfoldlM'_loop_s1xc sc_s1x2 ww_s1q5 3# sc3_s1wZ; True -> $s$wfoldlM'_loop1_s1x3 sc_s1x2 (+# sc1_s1x0 ww1_s1q9) (-# sc2_s1x1 1#) (+# sc3_s1wZ sc1_s1x0) }; } in $s$wfoldlM'_loop1_s1x3 w_s1q2 ww_s1q5 2# 0# }}} Now the same with ghc-8.2-rc1. Here, [https://github.com/haskell/vector/blob/master/Data/Vector/Fusion/Stream/Monadic.hs Stream.++] function is not fully optimized away (Left and Right constructors!). Instead we have a join point that executes either of the two parts (xs or ys) based on a `case w2_s1U2 of {Left -> ; Right ->}`. {{{#!hs $wfoo_r23R $wfoo_r23R = \ ww_s1Ue ww1_s1Ui w_s1Ub -> let { x1_a1tj x1_a1tj = I# ww_s1Ue } in let { tb_a1wC tb_a1wC = (x1_a1tj, lvl1_r23Q) } in let { lvl2_s1Yh lvl2_s1Yh = Right tb_a1wC } in joinrec { $wfoldlM'_loop_s1U8 $wfoldlM'_loop_s1U8 w1_s1U0 ww2_s1U6 w2_s1U2 w3_s1U3 = case w1_s1U0 of { __DEFAULT -> case w2_s1U2 of { Left sa_a1yP -> case sa_a1yP of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> jump $wfoldlM'_loop_s1U8 SPEC ww2_s1U6 lvl2_s1Yh w3_s1U3; True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Left (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } }; Right sb_a1z3 -> case sb_a1z3 of { (w4_a1zr, m1_a1zs) -> case m1_a1zs of { I# x2_a1zw -> case tagToEnum# (># x2_a1zw 0#) of { False -> (# w3_s1U3, I# ww2_s1U6 #); True -> case w4_a1zr of { I# y_a1xT -> jump $wfoldlM'_loop_s1U8 SPEC (+# ww2_s1U6 y_a1xT) (Right (I# (+# y_a1xT ww1_s1Ui), I# (-# x2_a1zw 1#))) w3_s1U3 } } } } } }; } in jump $wfoldlM'_loop_s1U8 SPEC 0# (Left (x1_a1tj, lvl_r23P)) w_s1Ub }}} For my stream-fusion heavy code, this yields a slowdown of approximately x4 (10 seconds with ghc-8.2-rc1, 2.5 seconds with ghc-8.0.1). === ghc-options: -O2 -ddump-to-file -ddump-simpl -dsuppress-all -dshow-passes -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 27 23:24:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Apr 2017 23:24:28 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.32b4a9896d78c72e069fcba1c7869ea2@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by choenerzs): Pure conjecture: `$wfoldlM'_loop_s1U8` takes `SPEC` and should probably then not be a join point. On the other hand, the `vector` people probably need join points to happen if they want to remove `Skip` from from the `Step` data type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 01:16:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 01:16:03 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.e22abdfb6df721c897b11d1553982502@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer): * Attachment "coreFV-cmm.diff" added. cmm diff before and after -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 01:19:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 01:19:55 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.2f4ef97e2c8402782e037c93189b991d@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer): * Attachment "coreFV-stg.diff" added. STG diff before and after -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 01:22:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 01:22:02 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.783aec0fb30a6d631cb2a678fd79257a@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer): * Attachment "coreFV-simpl.diff" added. Tidy core diff before and after -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 01:27:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 01:27:00 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.2c5ad875823fdd12ac5040ab5307931f@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 dfeuer): Whatever's going on here looks really subtle. The simplifier dumps appear to be exactly the same, except for doing things in slighly different orders. The STG dumps are a bit harder to read, but the difference in CMM dumps is sufficiently small and confined that someone familiar with CMM might well be able to see what's going on there directly. I'll have to learn something about that pretty soon, I imagine, but I don't know it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 02:05:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 02:05:06 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.cd72c048c46fcd73c3459be110a34519@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For the sake of convenience, here's a version which brings in the relevant code from `vector` to avoid dependencies: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE CPP #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Test where import GHC.Types (SPEC(..)) foo :: Int -> Int -> IO Int foo = \i j -> sfoldl' (+) 0 $ xs i j +++ ys i j where xs k l = senumFromStepN k l 2 ys k l = senumFromStepN k l 3 {-# Inline xs #-} {-# Inline ys #-} {-# Inline foo #-} ------------------------------------------------------------------------------- -- vector junk ------------------------------------------------------------------------------- #define PHASE_FUSED [1] #define PHASE_INNER [0] #define INLINE_FUSED INLINE PHASE_FUSED #define INLINE_INNER INLINE PHASE_INNER data Stream m a = forall s. Stream (s -> m (Step s a)) s data Step s a where Yield :: a -> s -> Step s a Skip :: s -> Step s a Done :: Step s a senumFromStepN :: (Num a, Monad m) => a -> a -> Int -> Stream m a {-# INLINE_FUSED senumFromStepN #-} senumFromStepN x y n = x `seq` y `seq` n `seq` Stream step (x,n) where {-# INLINE_INNER step #-} step (w,m) | m > 0 = return $ Yield w (w+y,m-1) | otherwise = return $ Done sfoldl' :: Monad m => (a -> b -> a) -> a -> Stream m b -> m a {-# INLINE sfoldl' #-} sfoldl' f = sfoldlM' (\a b -> return (f a b)) sfoldlM' :: Monad m => (a -> b -> m a) -> a -> Stream m b -> m a {-# INLINE_FUSED sfoldlM' #-} sfoldlM' m w (Stream step t) = foldlM'_loop SPEC w t where foldlM'_loop !_ z s = z `seq` do r <- step s case r of Yield x s' -> do { z' <- m z x; foldlM'_loop SPEC z' s' } Skip s' -> foldlM'_loop SPEC z s' Done -> return z infixr 5 +++ (+++) :: Monad m => Stream m a -> Stream m a -> Stream m a {-# INLINE_FUSED (+++) #-} Stream stepa ta +++ Stream stepb tb = Stream step (Left ta) where {-# INLINE_INNER step #-} step (Left sa) = do r <- stepa sa case r of Yield x sa' -> return $ Yield x (Left sa') Skip sa' -> return $ Skip (Left sa') Done -> return $ Skip (Right tb) step (Right sb) = do r <- stepb sb case r of Yield x sb' -> return $ Yield x (Right sb') Skip sb' -> return $ Skip (Right sb') Done -> return $ Done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 02:17:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 02:17:45 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.b222e853e34ac141ca995f5addc7fa5a@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821, polykinds/T11821a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mietek): I can still trigger the same internal error in GHC 8.0.2 with the following, admittedly silly example: {{{ {-# LANGUAGE TypeInType #-} data X :: Y where Y :: X }}} The error message is: {{{ Bug.hs:2:11: error: … • GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1cR :-> APromotionErr TyConPE] • In the kind ‘Y’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 02:19:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 02:19:56 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.ed269e73e13ab64b9cb36bde0cc0f101@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821, polykinds/T11821a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mietek): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 03:22:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 03:22:39 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment Message-ID: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well. Since `loadObj()` just `mmap()`s the entire object file and decodes it ''in place'', it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX. The attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time. You can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following: {{{ $ objdump -d map.o Disassembly of section .text: 0000000000000000 : 0: 49 89 f3 mov %rsi,%r11 3: 49 29 fb sub %rdi,%r11 6: 0f 8e f9 00 00 00 jle 105 c: 49 83 fb 20 cmp $0x20,%r11 10: 0f 82 bd 00 00 00 jb d3 16: 4d 89 da mov %r11,%r10 19: 49 83 e2 e0 and $0xffffffffffffffe0,%r10 1d: 4d 89 d9 mov %r11,%r9 20: 49 83 e1 e0 and $0xffffffffffffffe0,%r9 24: 0f 84 a9 00 00 00 je d3 2a: 49 01 fa add %rdi,%r10 2d: 48 8d 44 ba 60 lea 0x60(%rdx,%rdi,4),%rax 32: 49 8d 7c b8 60 lea 0x60(%r8,%rdi,4),%rdi 37: c5 fc 28 05 00 00 00 vmovaps 0x0(%rip),%ymm0 # 3f 3e: 00 3f: 4c 89 c9 mov %r9,%rcx 42: 66 66 66 66 66 2e 0f data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) 49: 1f 84 00 00 00 00 00 50: c5 f8 10 4f a0 vmovups -0x60(%rdi),%xmm1 55: c5 f8 10 57 c0 vmovups -0x40(%rdi),%xmm2 5a: c5 f8 10 5f e0 vmovups -0x20(%rdi),%xmm3 5f: c5 f8 10 27 vmovups (%rdi),%xmm4 63: c4 e3 75 18 4f b0 01 vinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1 6a: c4 e3 6d 18 57 d0 01 vinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2 71: c4 e3 65 18 5f f0 01 vinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3 78: c4 e3 5d 18 67 10 01 vinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4 7f: c5 f4 58 c8 vaddps %ymm0,%ymm1,%ymm1 83: c5 ec 58 d0 vaddps %ymm0,%ymm2,%ymm2 87: c5 e4 58 d8 vaddps %ymm0,%ymm3,%ymm3 8b: c5 dc 58 e0 vaddps %ymm0,%ymm4,%ymm4 8f: c4 e3 7d 19 48 b0 01 vextractf128 $0x1,%ymm1,-0x50(%rax) 96: c5 f8 11 48 a0 vmovups %xmm1,-0x60(%rax) 9b: c4 e3 7d 19 50 d0 01 vextractf128 $0x1,%ymm2,-0x30(%rax) a2: c5 f8 11 50 c0 vmovups %xmm2,-0x40(%rax) a7: c4 e3 7d 19 58 f0 01 vextractf128 $0x1,%ymm3,-0x10(%rax) ae: c5 f8 11 58 e0 vmovups %xmm3,-0x20(%rax) b3: c4 e3 7d 19 60 10 01 vextractf128 $0x1,%ymm4,0x10(%rax) ba: c5 f8 11 20 vmovups %xmm4,(%rax) be: 48 83 e8 80 sub $0xffffffffffffff80,%rax c2: 48 83 ef 80 sub $0xffffffffffffff80,%rdi c6: 48 83 c1 e0 add $0xffffffffffffffe0,%rcx ca: 75 84 jne 50 cc: 4d 39 cb cmp %r9,%r11 cf: 75 05 jne d6 d1: eb 32 jmp 105 d3: 49 89 fa mov %rdi,%r10 d6: 4c 29 d6 sub %r10,%rsi d9: 4a 8d 04 92 lea (%rdx,%r10,4),%rax dd: 4b 8d 0c 90 lea (%r8,%r10,4),%rcx e1: c5 fa 10 05 00 00 00 vmovss 0x0(%rip),%xmm0 # e9 e8: 00 e9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) f0: c5 fa 58 09 vaddss (%rcx),%xmm0,%xmm1 f4: c5 fa 11 08 vmovss %xmm1,(%rax) f8: 48 83 c0 04 add $0x4,%rax fc: 48 83 c1 04 add $0x4,%rcx 100: 48 ff ce dec %rsi 103: 75 eb jne f0 105: c5 f8 77 vzeroupper 108: c3 req }}} The attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is [0..N-1]): {{{ $ ./build.sh + llc-4.0 -filetype=obj -mcpu=native map.ll + ghc --make -no-hs-main test.c $ ./a.out array size is 31 calling function... ok 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0 }}} For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. {{{ $ lldb a.out (lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) run Process 7294 launched: '/a.out' (x86_64) array size is 32 calling function... Process 7294 stopped * thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main- thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000000010019f207 -> 0x10019f207: vmovaps 0xe1(%rip), %ymm0 0x10019f20f: movq %r9, %rcx 0x10019f212: nopw %cs:(%rax,%rax) 0x10019f220: vmovups -0x60(%rdi), %xmm1 }}} The `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails. I've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 03:23:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 03:23:10 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.8e13f8cdf859f977b537598b4f8f7abc@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * Attachment "test.c" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 03:23:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 03:23:22 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.a15a9cba933fd92a9b576785be710b26@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * Attachment "map.ll" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 03:23:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 03:23:35 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.90e3f6cc598aec0ef802e30e00a51d8c@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * Attachment "build.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 03:30:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 03:30:19 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.f4b32dc8663147817472e1118b620d94@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): With the floating-in of the array-indexing primop, instead of having the following order: {{{ 1) A <- load from address @XXX 2) compute several things (sqrt,mul,div,sub,add) independent of A 3) store (A - ..) at address @XXX }}} We have this order: 2, 1, 3. As this is n-body, could it be a prefetching issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:06:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:06:30 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.b69da6fac4e49ba3bdf671cba1a9fb44@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:28:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:28:51 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.aa1ec719c05cc70827dc8ad4a63c4023@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821, polykinds/T11821a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: I think this is a different bug. I will open a new ticket anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:30:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:30:23 -0000 Subject: =?utf-8?b?W0dIQ10gIzEzNjI1OiBHSEMgaW50ZXJuYWwgZXJyb3I6IOKAmFk=?= =?utf-8?q?=E2=80=99_is_not_in_scope_during_type_checking=2C_but_?= =?utf-8?q?it_passed_the_renamer?= Message-ID: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TypeInType #-} data X :: Y where Y :: X }}} The error message is: {{{ Bug.hs:2:11: error: … • GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1cR :-> APromotionErr TyConPE] • In the kind ‘Y’ }}} Originally reported by @mietek in #11821 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:31:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:31:59 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification Message-ID: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cat A.hs module A where data T = Cons $ cat B.hs module B (T(T)) where import qualified A data T = T $ ghc-8.2.0.20170422 -Wall B.hs [2 of 2] Compiling B ( B.hs, B.o ) [A changed] B.hs:1:11: error: • Ambiguous occurrence ‘T’ It could refer to either ‘A.T’, imported qualified from ‘A’ at B.hs:3:1-18 or ‘T’, defined at B.hs:5:1 • In the export: T(T) | 1 | module B (T(T)) where | ^^^^ }}} There should be no ambiguity, because there is only one data constructor named `T`. Even if `A.T`'s data constructor would also be called `T` there would be no ambiguity because `A` is imported with qualification. The problem does not appear, if `B.T`'s data constructor is named `Cons`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:33:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:33:08 -0000 Subject: [GHC] #13627: IndexError: pop from empty list Message-ID: <046.4bbf0226d456473b81ceb192cece0d5c@haskell.org> #13627: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) 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: -------------------------------------+------------------------------------- ==== How to Reproduce ==== While doing a GET operation on `/attachment/ticket/13626/`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {u'action': u'new', 'path': u'13626/', 'realm': u'ticket'} }}} User agent: `#USER_AGENT#` ==== System Information ==== ''Systeminformation nicht verfügbar'' ==== Enabled Plugins ==== ''Plugininformation nicht verfügbar'' ==== Interface Customization ==== ''Interface customization information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 623, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 259, in dispatch iterable=chrome.use_chunked_encoding) File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1164, in render_template encoding='utf-8') File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 184, in render return encode(generator, method=method, encoding=encoding, out=out) File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 58, in encode for chunk in iterator: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 350, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 829, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 669, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 774, in __call__ for kind, data, pos in chain(stream, [(None, None, None)]): File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 594, in __call__ for ev in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1431, in _strip_accesskeys for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 1420, in _generate for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 706, in _unmark for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 1101, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 118, in __iter__ event = self.stream.next() File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 734, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 702, in _mark for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 362, in _match content = list(content) File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 326, in _match for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 178, in _generate for event in msgbuf.translate(gettext(msgbuf.format())): File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 1051, in translate events = self.events[order].pop(0) IndexError: pop from empty list }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:33:45 -0000 Subject: [GHC] #13627: IndexError: pop from empty list In-Reply-To: <046.4bbf0226d456473b81ceb192cece0d5c@haskell.org> References: <046.4bbf0226d456473b81ceb192cece0d5c@haskell.org> Message-ID: <061.eb77cca68150d9e139a6ed452f009326@haskell.org> #13627: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: Lemming | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: 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 Lemming): * owner: (none) => hvr * component: Compiler => Trac & Git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 07:45:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 07:45:13 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.b04c5c7740532b8d05d60122929787b3@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: kavon@… (added) Comment: I'm a bit surprised that the Sinking pass in Cmm didn't convert 1,2,3 into 2,1,3. In which case both programs would have the same end product. So you've at least confirmed that the runtime change was indeed (as I thought) something v subtle to do with prefetching or whatnot. It looks unreasonable for the `FloatIn` pass to choose the "right" thing, even if we knew what was "right". So it's still interesting, but it removes the urgency of saying "do we want this particular patch". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 08:33:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 08:33:35 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification In-Reply-To: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> References: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> Message-ID: <061.6228ef70fcddf4000648ee76638bbb4f@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I think that the problem was not present in earlier GHC-8.2 prereleases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 08:41:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 08:41:38 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification In-Reply-To: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> References: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> Message-ID: <061.9b739e0cf33a2a56921edb3efbc10d64@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 09:39:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 09:39:44 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification In-Reply-To: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> References: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> Message-ID: <061.1b7e3e13560e55b446cd8d208806ac33@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is a duplicate of #13622, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 09:47:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 09:47:55 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification In-Reply-To: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> References: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> Message-ID: <061.b22c13817539d00ecc5c1fab037fbbcc@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | 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 Lemming): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 09:49:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 09:49:50 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.5b2ee63a0d1833a0acb5c5685012e156@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Lemming): * cc: Lemming (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 10:47:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 10:47:13 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.07e58027d6828d38418857d54ffa6379@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 mpickering): The problem is that name clash errors are reported too eagerly. Solution. 1. Extend `ChildLookupResult` to have a case for an ambiguous lookup 2. Prefer other options to ambiguous lookup in the monoid instance. 3. Use `addNameClashErr` when handling `ChildLookupResult` for the ambiguous case. I need to look carefully at whether all the uses of ambiguous names are recoverable or whether they should all be deferred to later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 11:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 11:04:10 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.d87174f9db047c42f1d4a93051e246cb@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a1b753e8b1475659440f524b3e66dfbea31c5787/ghc" a1b753e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a1b753e8b1475659440f524b3e66dfbea31c5787" Cure exponential behaviour in the simplifier This patch nails a Bad Bug exposed in Trac #13379. Roughly, a deeply-nested application like f (f (f ....) ) ) could make the simplifier go exponential -- without producing an exponential-sized result! The reason was that we - simplified a (big) function argument - then decided to inline the function - then preInilneUnconditionally the argument - and then re-simplified the big argument And if the "big argument" itself had a similar structure things could get very bad. Once I'd understood, it was easy to fix: * See Note Note [Avoiding exponential behaviour] for an overview * The key change is that Simplify.simplLam now as a case for (isSimplified dup). This is what removes the perf bug. * But I also made simplCast more parsimonious about simplifying, avoiding doing so when the coercion is Refl * And similarly I now try to avoid simplifying arguments where possible before applying rules. See Note [Trying rewrite rules] The latter two points tackle common cases, and in those cases make the simplifier take fewer iterations. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 11:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 11:04:10 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.9e56f04e31682773b1cf2b881d33cbdc@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"29d88ee173bc9b04245a33d5268dda032f5dc331/ghc" 29d88ee1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29d88ee173bc9b04245a33d5268dda032f5dc331" Be a bit more eager to inline in a strict context If we see f (g x), and f is strict, we want to be a bit more eager to inline g, because it may well expose an eval (on x perhaps) that can be eliminated or shared. I saw this in nofib boyer2, function RewriteFuns.onewayunify1. It showed up as a consequence of the preceding patch that makes the simplifier do less work (Trac #13379). We had f d (g x) where f was a class-op. Previously we simplified both d and (g x) with a RuleArgCtxt (making g a bit more eager to inline). But now we simplify only d that way, then fire the rule, and only then simplify (g x). Firing the rule produces a strict funciion, so we want to make a strict function encourage inlining a bit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 11:13:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 11:13:47 -0000 Subject: [GHC] #13628: Confusing error message with TypeApplications already enabled Message-ID: <042.ee10be2d1f10ead503438907139bca43@haskell.org> #13628: Confusing error message with TypeApplications already enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have `{-# LANGUAGE TypeApplications #-}` in my file, and accidentally wrote a typo: `myFunction at a` (missing space, intended was `myFunction @a`). GHC 8.0.2 outputs: {{{ Pattern syntax in expression context: myFunction at a Did you mean to enable TypeApplications? }}} I already have TypeApplications on, why does GHC suggest this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 11:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 11:14:16 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.211ae256af4cc435062bee9eb339a42f@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => perf/compile/T13379 * status: new => merge Comment: I claim this is fixed. The second patch fixes a problem that the first one exposed; so merge them both. Would someone like to verify it's fixed in real live contexts? The `Main.hs` attachement is ok -- it's in the regression tests now. I forgot to mention, but the first (main) patch produces some perf improvements in `tests/perf/compiler`: {{{ T9020: 14% reduction in compiler allocation T12425: 5% reduction in compiler allocation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 11:48:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 11:48:51 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.6f7b522aa1dfa6755bf77fbd9e1d1669@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 kavon): It seems the Cmm Sinker won't move the loads in (1) closer to their use in (3) because there is an intervening foreign call to the sqrt function in (2). Right now, the Sinker's analysis conservatively says that it's not save to commute a memory load with a foreign call due to the possibility of that call writing to the heap. Ideally, there would be a marker for foreign calls that we know are pure, i.e., math functions like sqrt, so that the loads can move past it. I'm not sure if this marker already exists or not. In this case, the importance of turning it into 2,1,3 via sinking is that there are fewer values live across the call to sqrt, because that call causes any floating-point values that are in register to be saved to the stack, negating any benefit of loading it so early. Here's the output of the 1,2,3 version I'm seeing with the NCG: {{{ movsd (%rax), %xmm5 ; load A into xmm5 very early ; ... movsd %xmm5, 128(%rsp) ; save A to stack ; ... call _sqrt ; ... movsd 128(%rsp), %xmm4 ; restore A from stack subsd %xmm3, %xmm4 ; actually use A }}} I think 2,1,3 is always desirable in Cmm, as the instruction scheduler should be hiding the load latency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 12:59:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 12:59:54 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313625=3A_GHC_internal_error=3A_?= =?utf-8?q?=E2=80=98Y=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> References: <049.ad31bbf13fa6a8340cd37900420f039f@haskell.org> Message-ID: <064.6d852d860812fa529bd79adf28a731af@haskell.org> #13625: GHC internal error: ‘Y’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) 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 goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 13:02:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 13:02:56 -0000 Subject: [GHC] #13628: Confusing error message with TypeApplications already enabled In-Reply-To: <042.ee10be2d1f10ead503438907139bca43@haskell.org> References: <042.ee10be2d1f10ead503438907139bca43@haskell.org> Message-ID: <057.e156cb3d66396c87adf28401e29120ad@haskell.org> #13628: Confusing error message with TypeApplications already enabled -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12879 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12879 Comment: Thankfully, this is fixed in GHC 8.2.1, where you get this error message instead: {{{ Pattern syntax in expression context: myFunction at a Type application syntax requires a space before '@' }}} See #12879 for the original ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 13:29:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 13:29:27 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.4f6b4e40c46c21a78aa3e68983dc8445@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586 | 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 Fri Apr 28 14:16:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 14:16:20 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.8ede634d62a1270c2d8c47ad0f2d202e@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13603 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Out of curiosity, can any of those `TYPE rep` annotations be omitted in ''HEAD'' while retaining levity polymorphism? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 14:37:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 14:37:18 -0000 Subject: [GHC] #13603: Can't resolve levity polymorphic superclass In-Reply-To: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> References: <051.e7f50c2f87d4c190f2423ef8be79c1b1@haskell.org> Message-ID: <066.b69784c4a158ff8fbd36e64f9444d99f@haskell.org> #13603: Can't resolve levity polymorphic superclass -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13603 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3489 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I doubt it. Levity polymorphism is opt-in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 14:51:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 14:51:04 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.1a9933bd241aedf05a50fd2366cf8e96@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 15:05:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 15:05:22 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 Message-ID: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3265 | Wiki Page: -------------------------------------+------------------------------------- The NCG currently implements the square root MachOp with an out-of-line call. This resulted in a large performance regression in `n-body` (see #13570). Fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 15:06:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 15:06:02 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.8cd46d772bd6c9247e2ca3eeb79099ac@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3265 => Phab:D3508 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 15:06:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 15:06:43 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.c47ed48471014ccedd29052d3bb70ff5@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13629 Comment: I've opened #13629 to track the `sqrt` code generation issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 15:06:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 15:06:54 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.72492375eb7400046051af2abc7d10aa@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #13570 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 15:50:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 15:50:23 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.701faf01cf9da54a84b555621dff87bb@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The NCG currently implements the square root MachOp with an out-of-line call Where is this choice made? E.g. I think the `sin` `MachOp` really generates a `sin` instruction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 16:21:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 16:21:12 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.74211a9b4531e39cef7401b047abcf88@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It's made in the native code generator, `genCCall` in `compiler/nativeGen/X86/CodeGen.hs`. While we use the `fsin` instruction on i386, we don't on x86_64 (and i386 with `-msse2`). See Phab:D3508 for a quick attempt at fixing the `sqrt` situation. In the case of trigonometric functions I'm afraid we have little choice but to fall back on `libm` since SSE provides no trig instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 16:55:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 16:55:05 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.e4e7b7aef9bf1d81795723ed62ea94e4@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 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: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Description changed by kavon: @@ -4,0 +4,3 @@ + + See discussion [https://mail.haskell.org/pipermail/ghc- + devs/2017-April/014168.html here] as well. New description: The NCG currently implements the square root MachOp with an out-of-line call. This resulted in a large performance regression in `n-body` (see #13570). Fix this. See discussion [https://mail.haskell.org/pipermail/ghc- devs/2017-April/014168.html here] as well. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:18:57 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.e0a6a456454759b42397cb8b957a8b48@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #13487 | Differential Rev(s): Phab:D3495 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"69b9b853e3e68191cdfa8aec0e4da966298a2659/ghc" 69b9b853/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69b9b853e3e68191cdfa8aec0e4da966298a2659" Add regression test for #12104 Commit 2f9f1f86849ebc18af409c9b3fd809c9cd464021 (#13487) fixes #12104 as well. This adds a regression test for the program reported in #12104 to keep it fixed. Test Plan: make test TEST=T12104 Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12104 Differential Revision: https://phabricator.haskell.org/D3495 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:18:57 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors In-Reply-To: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> References: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> Message-ID: <063.537cc7445c850587c9404fc66010011c@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T13487 Blocked By: | Blocking: Related Tickets: #12104 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"69b9b853e3e68191cdfa8aec0e4da966298a2659/ghc" 69b9b853/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69b9b853e3e68191cdfa8aec0e4da966298a2659" Add regression test for #12104 Commit 2f9f1f86849ebc18af409c9b3fd809c9cd464021 (#13487) fixes #12104 as well. This adds a regression test for the program reported in #12104 to keep it fixed. Test Plan: make test TEST=T12104 Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12104 Differential Revision: https://phabricator.haskell.org/D3495 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:18:57 -0000 Subject: [GHC] #13618: Reified data family instances type variables not related to value constructor fields In-Reply-To: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> References: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> Message-ID: <059.b8cd01f56f2c769cebdf2cbe6590fe0b@haskell.org> #13618: Reified data family instances type variables not related to value constructor fields -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc1 checker) | 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): Phab:D3505 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b2c38d6b4003d3dda60d15204283da5aab15c2ec/ghc" b2c38d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b2c38d6b4003d3dda60d15204283da5aab15c2ec" Make the tyvars in TH-reified data family instances uniform It turns out we were using two different sets of type variables when reifying data family instances in Template Haskell. We were using the tyvars quantifying over the instance itself for the LHS, but using the tyvars quantifying over the data family instance constructor for the RHS. This commit uses the instance tyvars for both the LHS and the RHS, fixing #13618. Test Plan: make test TEST=T13618 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13618 Differential Revision: https://phabricator.haskell.org/D3505 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:18:57 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzYxNTogTm9uZGV0ZXJtaW5pc20gaW4g4oCY?= =?utf-8?q?pure=E2=80=99_function_w/_parallel_evaluation_=26_memo?= =?utf-8?q?_combinators?= In-Reply-To: <044.57733831351687fff6258688df1f42f7@haskell.org> References: <044.57733831351687fff6258688df1f42f7@haskell.org> Message-ID: <059.0e5d863496026c34b1dc44c49cf3e3c8@haskell.org> #13615: Nondeterminism in ‘pure’ function w/ parallel evaluation & memo combinators -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Ben Gamari ): In [changeset:"228d4670e98e4fd998c847aac38c11ad85aa35a7/ghc" 228d4670/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="228d4670e98e4fd998c847aac38c11ad85aa35a7" Use memcpy in cloneArray While looking at #13615 I noticed that there was this strange open-coded memcpy in the definition of the cloneArray macro. I don't see why this should be preferable to memcpy. Test Plan: Validate, particularly focusing on array operations Reviewers: simonmar, tibbe, austin, alexbiehl Reviewed By: tibbe, alexbiehl Subscribers: alexbiehl, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3504 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:19:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:19:53 -0000 Subject: [GHC] #13618: Reified data family instances type variables not related to value constructor fields In-Reply-To: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> References: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> Message-ID: <059.3e99067f3274a31018c2d9b4dd2bd031@haskell.org> #13618: Reified data family instances type variables not related to value constructor fields -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | 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): Phab:D3505 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:20:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:20:51 -0000 Subject: [GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" In-Reply-To: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> References: <046.3aa229b1c93bff66ccc48ab6d0e3a13c@haskell.org> Message-ID: <061.d13708e0c06d225c4307b96f72b642eb@haskell.org> #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: fixed | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #13487 | Differential Rev(s): Phab:D3495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Will merge fix for #13487 to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:27:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:27:09 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.227cf2e6c8b14f0853d3f371fbe2b7c9@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => numeric/num009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:28:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:28:46 -0000 Subject: [GHC] #13468: GHC stubbornly produces dead code for empty case with type family In-Reply-To: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> References: <045.25c4bffd8ac85aad2b0082017a4952a2@haskell.org> Message-ID: <060.49a5ef82cd2b4570e08bcfd6fcde1b44@haskell.org> #13468: GHC stubbornly produces dead code for empty case with type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | simplCore/should_compile/T13468 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.1 Comment: I ended up merging this to 8.2 (09249f93089517ace8aae6d0652716f6fac18e3e) to simplify merging of #13379. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 18:29:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 18:29:33 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.ffba5d85475ba16e4ebf16ccfe1df230@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:17 merged to `ghc-8.2` as 09249f93089517ace8aae6d0652716f6fac18e3e and comment:18 as f9aa658ba8293832a6622323b58063a379b16901. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 19:01:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 19:01:41 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.0719a1cb613e6ece7f6bb493bc4ea212@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9ac22183e405773ea7147728e593edd78f30a025/ghc" 9ac22183/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ac22183e405773ea7147728e593edd78f30a025" nativeGen: Use SSE2 SQRT instruction Reviewers: austin, dfeuer Subscribers: dfeuer, rwbarton, thomie GHC Trac Issues: #13629 Differential Revision: https://phabricator.haskell.org/D3508 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 19:05:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 19:05:51 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.46bcc455de03054f1da04c1f680dd407@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 20:18:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 20:18:40 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.85b88b62a24512da7dc1ed1526a023df@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): Replying to [comment:4 bgamari]: > It's made in the native code generator, `genCCall` in `compiler/nativeGen/X86/CodeGen.hs`. While we use the `fsin` instruction on i386, we don't on x86_64 (and i386 with `-msse2`). If there is already x87 FPU instruction support in the NCG for x86-32, it might be profitable to reuse that support for x86-64 to speed up trig functions, etc. The simplest way I see it is to expand the foreign call into an instruction sequence that moves the float from XMM registers to the x87 stack, computes the value, and moves it back to XMM registers. This way we no longer have a C call in a potentially bad place. It's worth comparing x87 on modern processors against the assembly routine backing the C function first. It seems platforms like Skylake the x87 `fsin` takes 50-120 cycles [1], but I'm not sure about the library versions. If they're roughly equivalent, there's likely a benefit to eliding the C call. [1] http://www.agner.org/optimize/instruction_tables.pdf (Page 223 for Skylake x87) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 20:38:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 20:38:40 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.509bee598a41370631f45b89d458cdce@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think I would prefer to make the C call cheaper (by, for instance, marking it as pure so that the sinker can better optimize code around it) than to bring x87 into the fold. x87's `fsin` is terribly imprecise (and consequently causes the `num009` test to fail on platforms where it is used). Moreover, as you point out, x87 performance varies widely between microarchitectures. Finally, x87's architecture is really a nuisance for the native codegen, requiring a number of hacks. It would be nice if some day we could do away with x87 support entirely (although this likely won't happen any time soon). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 21:39:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 21:39:03 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.0f9ed63d2c66c9913033fc9dba8459b8@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Unfortunately, [changeset:"9ac22183e405773ea7147728e593edd78f30a025/ghc" 9ac22183/ghc] (the fix to #13629) does *not* seem to fix this. `-ddump- asm` indicates that we're now using `sqrtsd`, but the numbers remain wretched. We'll have to see if Gipeda agrees with me, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 21:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 21:46:15 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.7f1f8fa2666339eee5487c95c0fa9c56@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, there are still a couple regressions for the combination of your two patches: {{{ nofib/time/cryptarithm1 time increases 4.87% from 0.513s to 0.538s nofib/size/scs code size increases 5.28% from 1224890 bytes to 1289570 bytes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:04:45 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.4e7e1a3e5995adda37bf3b49a54b1d68@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): I'm surprised `n-body` doesn't improve after that patch. Could you attach the assembly file? I'm wondering if the stack save/restores are still being emitted around the `sqrtsd` instruction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:07:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:07:44 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.80d128f8adf21f14704cde311dabb14b@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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 David Feuer ): In [changeset:"6d14c1485cb570cbd183bcdc0f858d9a6dc1eb31/ghc" 6d14c148/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d14c1485cb570cbd183bcdc0f858d9a6dc1eb31" Improve code generation for conditionals This patch in in preparation for the fix to Trac #13397 The code generator has a special case for case tagToEnum (a>#b) of False -> e1 True -> e2 but it was not doing nearly so well on case a>#b of DEFAULT -> e1 1# -> e2 This patch arranges to behave essentially identically in both cases. In due course we can eliminate the special case for tagToEnum#, once we've completed Trac #13397. The changes are: * Make CmmSink swizzle the order of a conditional where necessary; see Note [Improving conditionals] in CmmSink * Hack the general case of StgCmmExpr.cgCase so that it use NoGcInAlts for conditionals. This doesn't seem right, but it's the same choice as the tagToEnum version. Without it, code size increases a lot (more heap checks). There's a loose end here. * Add comments in CmmOpt.cmmMachOpFoldM }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:12:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:12:34 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.134354309b29530a6d5ddfb58a144d15@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:13:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:13:42 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.0bde8e8f89623a03ae940a05e2a05a32@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "latest-asm" added. n-body -ddump-asm with HEAD using sqrtsd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:14:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:14:30 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.54734ee87acb8030ea2a501f31f6990b@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ignore that attachment just now till I fix it. Attached the wrong one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:16:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:16:40 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.2096a4a5750b8203c22907b6f4023e57@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "latest-asm.2" added. -ddump-asm actually after the recent change -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:17:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:17:01 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "latest-asm" removed. n-body -ddump-asm with HEAD using sqrtsd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:17:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:17:01 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.83a826c7e8c9812535f8234367448261@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "latest-asm" added. Overwrite garbage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:17:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:17:50 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.cf9da358ed3c06ec41599c1270d5bc97@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Sorry for all the wrong clicks. The attachment should be right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 22:34:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 22:34:19 -0000 Subject: [GHC] #13570: CoreFVs patch makes n-body slower In-Reply-To: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> References: <046.1d2943f316c839fe14856692f6ce7477@haskell.org> Message-ID: <061.93d03e5b5046ea3396d89065ba5ad31e@haskell.org> #13570: CoreFVs patch makes n-body slower -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: #13629 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): Well, at least the assembly code after the patch for #13629 is much more efficient! The sqrt inefficiency in #13629 was a somewhat separate observation: I expected nbody to improve a bit because of that fix, counteracting whatever weird thing is going on in this regression. I guess once the Gipeda report is up we'll see if that patch helped any of the benchmarks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 28 23:58:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Apr 2017 23:58:17 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.9413e5b1a596d7e4b2cec5d7caefe57f@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I did a quick, rather unscientific, comparison of SSE2 and x87, {{{#!c++ #include #include #include #include const int N = 1e8; template void time_it(const char *name, std::function f, Args... args) { struct timespec start, end; clock_gettime(CLOCK_MONOTONIC, &start); f(args...); clock_gettime(CLOCK_MONOTONIC, &end); double t = (end.tv_nsec - start.tv_nsec) * 1e-9 + (end.tv_sec - start.tv_sec); printf("%s: %f seconds / %d = %f ns per iter\n", name, t, N, t / N / 1e-9); } static double test(double x) { double y = 0; for (int i=0; i(test), 0.0); return 0; } }}} For x87 I compiled this with, {{{ $ g++ -lm hi.cpp -O2 -std=c++11 -march=core2 -ffast-math -mfpmath=387 }}} Which produced (ignoring the epilogue responsible for preparing the return value) {{{#!objdump 0000000000000b00 <_ZL4libmd>: b00: f2 0f 11 44 24 f8 movsd %xmm0,-0x8(%rsp) b06: dd 44 24 f8 fldl -0x8(%rsp) b0a: b8 00 e1 f5 05 mov $0x5f5e100,%eax b0f: dd 05 53 01 00 00 fldl 0x153(%rip) # c68 <_ZTSPFddE+0xb> b15: d9 ee fldz b17: dd 05 53 01 00 00 fldl 0x153(%rip) # c70 <_ZTSPFddE+0x13> b1d: dd 05 55 01 00 00 fldl 0x155(%rip) # c78 <_ZTSPFddE+0x1b> b23: eb 0f jmp b34 <_ZL4libmd+0x34> b25: 0f 1f 00 nopl (%rax) b28: dc c2 fadd %st,%st(2) b2a: d9 ca fxch %st(2) b2c: d9 fe fsin b2e: d9 cb fxch %st(3) b30: d9 cc fxch %st(4) b32: d9 ca fxch %st(2) b34: d9 c2 fld %st(2) b36: 83 e8 01 sub $0x1,%eax b39: d8 c2 fadd %st(2),%st b3b: d9 cd fxch %st(5) b3d: de c4 faddp %st,%st(4) b3f: 75 e7 jne b28 <_ZL4libmd+0x28> ... }}} For SSE I compiled with, {{{ $ g++ -lm hi.cpp -O2 -std=c++11 -march=core2 -ffast-math }}} Which produced, {{{#!objdump 0000000000000b60 <_ZL4libmd>: b60: 53 push %rbx b61: 66 0f ef c9 pxor %xmm1,%xmm1 b65: bb 00 e1 f5 05 mov $0x5f5e100,%ebx b6a: 48 83 ec 10 sub $0x10,%rsp b6e: f2 0f 11 04 24 movsd %xmm0,(%rsp) b73: f2 0f 10 05 5d 01 00 movsd 0x15d(%rip),%xmm0 # cd8 <_ZTSPFddE+0xb> b7a: 00 b7b: eb 1e jmp b9b <_ZL4libmd+0x3b> b7d: 0f 1f 00 nopl (%rax) b80: f2 0f 10 05 60 01 00 movsd 0x160(%rip),%xmm0 # ce8 <_ZTSPFddE+0x1b> b87: 00 b88: f2 0f 58 c1 addsd %xmm1,%xmm0 b8c: e8 4f fd ff ff callq 8e0 b91: f2 0f 10 54 24 08 movsd 0x8(%rsp),%xmm2 b97: 66 0f 28 ca movapd %xmm2,%xmm1 b9b: f2 0f 10 15 3d 01 00 movsd 0x13d(%rip),%xmm2 # ce0 <_ZTSPFddE+0x13> ba2: 00 ba3: 83 eb 01 sub $0x1,%ebx ba6: f2 0f 58 04 24 addsd (%rsp),%xmm0 bab: f2 0f 58 d1 addsd %xmm1,%xmm2 baf: f2 0f 11 04 24 movsd %xmm0,(%rsp) bb4: f2 0f 11 54 24 08 movsd %xmm2,0x8(%rsp) bba: 75 c4 jne b80 <_ZL4libmd+0x20> }}} Note the call to `sin` which is sent through the PLT. Yuck. This gave the following results on my i7-6600U (Skylake @ 2.6GHz) (looking at a variety of iteration counts to ensure that the timing isn't dominated by setup time, as well as a few measurements at each count to get a sense for variance) , ||= Method =||= iterations =||= Time per iteration (ns) =|| || SSE || 1e8 || 33.91 || || SSE || 1e8 || 34.08 || || SSE || 1e8 || 33.08 || || SSE || 5e7 || 34.47 || || SSE || 5e7 || 34.76 || || SSE || 5e7 || 36.36 || || SSE || 1e7 || 39.69 || || SSE || 1e7 || 36.45 || || SSE || 1e7 || 39.40 || || X87 || 1e8 || 37.95 || || X87 || 1e8 || 39.74 || || X87 || 1e8 || 40.94 || || X87 || 5e7 || 37.29 || || X87 || 5e7 || 36.35 || || X87 || 5e7 || 36.60 || || X87 || 1e7 || 37.75 || || X87 || 1e7 || 37.34 || || X87 || 1e7 || 38.30 || It seems to me like (in the case of this particularly terrible benchmark) the two implementations are relatively similar, with SSE perhaps having a slight edge. Intriguingly, replacing `sin` in the example with `sqrt` changes the outcome dramatically: both timings decrease markedly (as one might expect; `sin` isn't an easy thing to compute), but X87 is twice as fast as SSE (2.2 ns/iteration vs. 5.5 ns/iteration). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 12:23:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 12:23:06 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.d4233d68bd730325640d77ba374c52c6@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 13:44:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 13:44:13 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.abbdd917916835be57901f8d226d313e@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): This is really interesting, thanks for looking into it! I'm not sure whether there are real programs that will benefit if we inline this library call by using x87 instructions. I'll leave that to someone who has a better intuition about whether there are graphics/mathematics programs that would appreciate the attention. We're at least no worse than C/C++ in this regard, though we probably pay a slightly higher call-site penalty due to a register mismatch between C and GHC conventions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 16:03:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 16:03:31 -0000 Subject: [GHC] #3397: :step hangs when -fbreak-on-exception is set In-Reply-To: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@haskell.org> References: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@haskell.org> Message-ID: <060.891a80317ae0691bc014fb2e3475c864@haskell.org> #3397: :step hangs when -fbreak-on-exception is set -------------------------------------+---------------------------------- Reporter: hamish | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+---------------------------------- Comment (by George): this seems to be fixed in 8.2.1-rc1: {{{ ghci -ignore-dot-ghci bug3397.hs GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( bug3397.hs, interpreted ) [flags changed] Ok, modules loaded: Main. *Main> :set -fbreak-on-exception *Main> :steplocal main Stopped in Main.main, bug3397.hs:12:8-34 _result :: IO () = _ [bug3397.hs:12:8-34] [bug3397.hs:12:8-34] *Main> :steplocal Stopped in Main.main, bug3397.hs:12:25-33 _result :: IO () = _ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 16:05:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 16:05:02 -0000 Subject: [GHC] #3397: :step hangs when -fbreak-on-exception is set In-Reply-To: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@haskell.org> References: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@haskell.org> Message-ID: <060.e7dc2f89f0d12507d114d5ff4a711ce0@haskell.org> #3397: :step hangs when -fbreak-on-exception is set -------------------------------------+---------------------------------- Reporter: hamish | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+---------------------------------- Changes (by George): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 16:14:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 16:14:44 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.6e44914b5afa728bd96690c4e0b7a978@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 18:06:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 18:06:18 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification In-Reply-To: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> References: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> Message-ID: <061.86a3ae5b7a6876767cd07358519eedb0@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | 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 mpickering): I realised an easier way to fix this and implemented it on my wip refactoring branch. However, it isn't suitable to be merged as I have heavily refactored the surrounding code and it is implemented using 8.0 only features. I will prepare another fix for the 8.2 branch once I have finished working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 18:11:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 18:11:08 -0000 Subject: [GHC] #13626: Ambiguity when exporting a data constructor despite qualification In-Reply-To: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> References: <046.7e8637b50ac056e95d6985efc0288c56@haskell.org> Message-ID: <061.c07ca8752c34e047f0fcdd9b7074bf16@haskell.org> #13626: Ambiguity when exporting a data constructor despite qualification -------------------------------------+------------------------------------- Reporter: Lemming | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Parser) | 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 Lemming): With GHC-8.0 only features? As far as I can see, in GHC-8.0 the problem did not exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 20:04:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 20:04:47 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.64b2c5886b60dfb92dec2082f8c992af@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: closed => new * resolution: fixed => Comment: This made `n-body` ''slower'' and did not appreciably affect other benchmarks. It would be really good to figure out what's going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 20:05:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 20:05:04 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.7a5cb2930f069ade659290d30db753bf@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): https://perf.haskell.org/ghc/#revision/9ac22183e405773ea7147728e593edd78f30a025 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 21:27:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 21:27:31 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.939a13679f1ab80a930ff268d9723d3d@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): If you have reasons to doubt the results, better try to reproduce them on your machine. I see performance cliffs of that size on perf.h.o that are sometimes triggered by very insignificant changes to the runtime system, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 29 23:11:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Apr 2017 23:11:42 -0000 Subject: [GHC] #13220: Performance regressions in testsuite from join points In-Reply-To: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> References: <049.405b53d5bd8d89bbd89346c7b7cf9193@haskell.org> Message-ID: <064.857bb0b1234574e0c39e5d7b0a830e4e@haskell.org> #13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: highest => normal Comment: The other regressions are small (~5%) and the join points commit is so complicated and so long ago that I doubt looking at these changes is the easiest way to gain a few percent on a few benchmarks. Furthermore the issue is clouded by indirect effects of the join points change that result from running a stage2 compiler. For example parsing and typechecking allocates slightly less after join points, but these gains are roughly canceled out by increased allocations during desugaring. Since these phases were presumably not changed by the join points commit, this changes must be due to different code generation with join points. These changes are probably more interesting than slight changes in perf tests. In all three `perf/compiler` tests where allocations changed, there were no significant changes to Core program size. It looks like the simplifier is just doing more work, which is no big surprise. I looked at T9020 (the simplest test case) with stage1 compilers built with ticky, but the code changes are extensive enough that I couldn't draw any conclusion from the results (many changes, new functions added, and old functions removed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 00:01:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 00:01:40 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.03b082b4911cf3fe3e389678fba1c3fe@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've reproduced the regression locally. While it's hard to measure the runtime difference with the default test configuration, if you increase the argument from 3000 to 10000 it becomes quite clear. Before the patch the runtime is 1.14 seconds, after it's 1.30 seconds. This is quite surprising since there are a few bits of the generated code that get rather significantly shorter. Namely, {{{#!asm ... subq $8,%rsp movsd %xmm0,%xmm4 movss %xmm6,%xmm0 mulss %xmm6,%xmm0 mulss %xmm6,%xmm0 movq %rax,%rbx movl $1,%eax movq %rcx,%r14 movq %rdx,72(%rsp) movq %rsi,80(%rsp) movq %rdi,88(%rsp) movsd %xmm4,96(%rsp) movsd %xmm1,104(%rsp) movsd %xmm2,112(%rsp) movsd %xmm3,120(%rsp) call sqrtf addq $8,%rsp movss _n8uc(%rip),%xmm1 divss %xmm0,%xmm1 movss %xmm1,%xmm0 movsd 112(%rsp),%xmm2 mulss %xmm2,%xmm0 movss %xmm1,%xmm2 movsd 104(%rsp),%xmm3 mulss %xmm3,%xmm2 movsd 96(%rsp),%xmm3 mulss %xmm3,%xmm1 movq 64(%rsp),%rax leaq 1(%rax),%rcx }}} Whereas after we get, {{{#!asm ... movss %xmm6,%xmm4 mulss %xmm6,%xmm4 mulss %xmm6,%xmm4 sqrtss %xmm4,%xmm4 movss _n8ud(%rip),%xmm5 divss %xmm4,%xmm5 movss %xmm5,%xmm4 mulss %xmm3,%xmm4 movss %xmm5,%xmm3 mulss %xmm2,%xmm3 mulss %xmm1,%xmm5 leaq 1(%rdx),%rbx }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 00:08:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 00:08:35 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.c581d3142e0c53eb08905c80c835f095@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So `perf stat` reveals a rather interesting picture. With the patch we retire few instructions (9,146,722,334 vs. 12,346,134,565), perform far fewer branches (908,661,442 compared to 1,308,583,802 without, the predictor missing around 0.01% in both cases), yet see a significantly higher runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 00:14:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 00:14:56 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.37d28cc076e604e18afc28479697bf3c@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Perhaps I'll just start a table of the PMU counters before and after, ||= Metric =||= Before patch =||= After patch =|| || instructions || 12,346,134,565 || 9,146,722,334 || || branches || 1,308,583,802 || 908,661,442 || || branch predict misses || || || || cache-misses || 83,983 || 57,490 || || L1-icache-load-misses || 138,869 || 156,777 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 00:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 00:19:41 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.f5d49dfdc53302ca1698ac2ae4fdba41@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, `sqrtf` is the following on my machine, {{{#!asm 0x00007ffff78892c0 <+0>: pxor %xmm1,%xmm1 0x00007ffff78892c4 <+4>: ucomiss %xmm0,%xmm1 0x00007ffff78892c7 <+7>: ja 0x7ffff78892d0 <__sqrtf+16> 0x00007ffff78892c9 <+9>: sqrtss %xmm0,%xmm0 0x00007ffff78892cd <+13>: retq 0x00007ffff78892ce <+14>: xchg %ax,%ax 0x00007ffff78892d0 <+16>: mov 0x2cccf9(%rip),%rax # 0x7ffff7b55fd0 0x00007ffff78892d7 <+23>: cmpl $0xffffffff,(%rax) 0x00007ffff78892da <+26>: je 0x7ffff78892c9 <__sqrtf+9> 0x00007ffff78892dc <+28>: movaps %xmm0,%xmm1 0x00007ffff78892df <+31>: mov $0x7e,%edi 0x00007ffff78892e4 <+36>: jmpq 0x7ffff788ed50 <__kernel_standard_f> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 00:52:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 00:52:01 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.ef8144ceed5edf208de63e398714e673@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by George): One interesting option clang would give us is to specify -Os, which according to the clang man page is like the clang -O2 option but with extra optimizations to reduce code size. opt and llc don't seem to have that option. Of course this wouldn't help the ghc code gen but might help with clang as the -O3 option along with -Os would allow users to experiment with size/speeed tradeoffs. I have seen discussions about not doing certain optimizations as the code size would be increased and we were unsure if the result would be faster or not. OTOH I don't know very much and maybe all the important code size / speed tradeoffs are made before we get to llvm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 00:52:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 00:52:48 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.f929a19d7671e089a6605ca7ff06d260@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 01:17:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 01:17:07 -0000 Subject: [GHC] #13630: ByteString pinned memory can be leaky Message-ID: <042.fff951e1f463505474531ee41ed62718@haskell.org> #13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- My question on IRC: {{{ How does memory allocation for pinned blocks work? Let's say pinned blocks are 4KB in size, and I allocate first a 3 KB ByteString A and then an 8-byte ByteString B. Now I GC A, no longer need it. Then according to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/Pinned "a single pinned object keeps alive the whole block in which it resides", my small ByteString B keeps the entire block alive. But what happens with the 3KB in the front of that block? Will it be re-used by the next ByteString allocation (say 1KB)? In other words, how smart is allocatePinned as an allocator? }}} The answer: {{{ slyfox: nh2: allocatePinned it quite dump. it only allocated from free tail space }}} {{{ nh2: slyfox: that sounds like a huge potential for memory leak then slyfox: yes, fragmentation is quite bad for bytestrings }}} So it seems that I can get into the unfortunate situation where a super short `ByteString` of a few bytes can waste an entire 4 KB block of memory; some migth call this a leak. One idea to solve it seems to be to change standard `ByteStrings` to not pinned, and to allocate pinned ones explicitly when needed. This seems to be an often-discussed topic and not trivial because many `ByteString` functions are implemented using libc FFI functions. However, it seems there will always be _some_ need for pinned memory, so we should better have an efficient way to manage it in any case. Efficient here means, for example, to re-use freed memory inside a block instead of only using free tail space. It seems that `jemalloc` has a feature to use given blocks of memory and provide a `malloc()` functionality inside them: https://stackoverflow.com/questions/30836359/jemalloc-mmap-and-shared- memory Perhaps this could be used to provide GHC with a simple method to use pinned memory more efficiently? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 07:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 07:47:51 -0000 Subject: [GHC] #13630: ByteString pinned memory can be leaky In-Reply-To: <042.fff951e1f463505474531ee41ed62718@haskell.org> References: <042.fff951e1f463505474531ee41ed62718@haskell.org> Message-ID: <057.74199bdb19441a5cc621b3aef069cd5f@haskell.org> #13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 12:42:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 12:42:01 -0000 Subject: [GHC] #13500: GHCi preprocesses every source file on :reload In-Reply-To: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> References: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> Message-ID: <062.30b30072fde057dfa96121323f0ca421@haskell.org> #13500: GHCi preprocesses every source file on :reload -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3398 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge Comment: This was merged to `master` in 914842e518bc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 12:43:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 12:43:02 -0000 Subject: [GHC] #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 In-Reply-To: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> References: <042.b0d14311de37aaa541c45a265c8fe803@haskell.org> Message-ID: <057.b4ed7e78cfcf96da38f9338138374b33@haskell.org> #13609: regression: `ANN` pragmas no longer ignored in TH-less GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3496 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D3496 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 13:39:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 13:39:41 -0000 Subject: [GHC] #13630: ByteString pinned memory can be leaky In-Reply-To: <042.fff951e1f463505474531ee41ed62718@haskell.org> References: <042.fff951e1f463505474531ee41ed62718@haskell.org> Message-ID: <057.1ee5ad361fb73ea02b7f9cebadc60e88@haskell.org> #13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): I've been wanting to switch to unpinned for ByteString for years, but it's a lot of work. It'd mean fixing up lots of other libs that use ByteString internals and it also requires a solution for the mmap'd ByteString use case (which does have solutions but it's still more work and may need some RTS extensions to be able to have an mmaped ByteArray# that unmaps when it's collected). As a workaround I often recommend people use ShortByteString, which is part of the bytestring package and uses unpinned memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 14:57:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 14:57:08 -0000 Subject: [GHC] #13631: In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone Message-ID: <044.47be1126ba3fb980d5a576a1fcfeebf4@haskell.org> #13631: In GHCi a result is wrong when -fdefer-typed-holes is used with underscore alone -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- I open this ticket instead of {{{#13579}}} to restate it and I closed the other.\\ In fact a result of the compiler which I think is wrong misled me.\\ Therefore I close tickets {{{#13602}}} and {{{#13557}}}.\\ In Haskell2010 Language Report it is said that :\\ 1. underscore "_ " all by itself is a reserved identifier.\\ 2. underscore "_" is treated as a lowercase letter, and can occur wherever a lowercase letter can.\\ So {{{_e}}} is an identifier like {{{__}}}\\ GHCi gives a bad result when he computed the code below.\\ {{{ Prelude> :set -fdefer-typed-holes Prelude> let f = map (\x -> True) [_, _] :2:27: warning: [-Wtyped-holes] * Found hole: _ :: a0 Where: `a0' is an ambiguous type variable * In the expression: _ In the second argument of `map', namely `[_, _]' In the expression: map (\ x -> True) [_, _] * Relevant bindings include f :: [Bool] (bound at :2:5) :2:30: warning: [-Wtyped-holes] * Found hole: _ :: a0 Where: `a0' is an ambiguous type variable * In the expression: _ In the second argument of `map', namely `[_, _]' In the expression: map (\ x -> True) [_, _] * Relevant bindings include f :: [Bool] (bound at :2:5) Prelude> f [True,True] }}} The underscore "_" is alone , all by itself and yet is recognized as an identifier, and GHCi gives a result.\\ This is the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 15:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 15:03:00 -0000 Subject: [GHC] #13579: -fdefer-type-errors and -fdefer-typed-holes flag do not perform their roles In-Reply-To: <044.4b8419965f2c282b3fb30bef94dff64a@haskell.org> References: <044.4b8419965f2c282b3fb30bef94dff64a@haskell.org> Message-ID: <059.3b3ac4bc91519303cea4f8964e90ce38@haskell.org> #13579: -fdefer-type-errors and -fdefer-typed-holes flag do not perform their roles -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: See ticket {{{#13631}}} instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 15:04:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 15:04:48 -0000 Subject: [GHC] #13602: Pattern syntax in expression context must be clarified In-Reply-To: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> References: <044.496c4529d72fbefd2b74c5fdfa9240ad@haskell.org> Message-ID: <059.42e8d84b828e8f1ef6fd80e4cf71c9dd@haskell.org> #13602: Pattern syntax in expression context must be clarified -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: See ticket {{{#13631}}} instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 15:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 15:06:11 -0000 Subject: [GHC] #13557: error found hole: _ is not appropriate in the following case In-Reply-To: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> References: <044.10bfc77c2bad9a4345bf50891acadc84@haskell.org> Message-ID: <059.6acac54af6f359103fcea1f0969244f7@haskell.org> #13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanto): * status: new => closed * resolution: => invalid Comment: See ticket {{{#13631}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:02:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:02:09 -0000 Subject: [GHC] #13606: GHCi segfaults on Windows with D3D code In-Reply-To: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> References: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> Message-ID: <065.ccf5c56a1368b7f5907ffc7a39b5cbd1@haskell.org> #13606: GHCi segfaults on Windows with D3D code ----------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12499 #12498 | Differential Rev(s): Phab:D3513 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3513 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:02:23 -0000 Subject: [GHC] #13606: GHCi segfaults on Windows with D3D code In-Reply-To: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> References: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> Message-ID: <065.d5cf1eb957316661fdea62e5965d0383@haskell.org> #13606: GHCi segfaults on Windows with D3D code ----------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12499 #12498 | Differential Rev(s): Phab:D3513 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:02:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:02:54 -0000 Subject: [GHC] #13606: GHCi segfaults on Windows with D3D code In-Reply-To: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> References: <050.af5542bb296b21a9acc9021e3f18425a@haskell.org> Message-ID: <065.121f608c5b7acedb61a313d15773c94d@haskell.org> #13606: GHCi segfaults on Windows with D3D code ----------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12499 #12498 | Differential Rev(s): Phab:D3513 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:03:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:03:32 -0000 Subject: [GHC] #12499: Support multiple library import libs In-Reply-To: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> References: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> Message-ID: <059.e7989588b832d53ddca96858fd5bdca3@haskell.org> #12499: Support multiple library import libs -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3513 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * differential: => Phab:D3513 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:03:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:03:51 -0000 Subject: [GHC] #12498: Support unconventionally named import libraries In-Reply-To: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> References: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> Message-ID: <059.5338e3d32ea7ef28d1fe86a1fe3c7e67@haskell.org> #12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Phab:D3513 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * differential: => Phab:D3513 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:04:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:04:11 -0000 Subject: [GHC] #12498: Support unconventionally named import libraries In-Reply-To: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> References: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> Message-ID: <059.2b3ba15d160a98f6f3d9f916b560270e@haskell.org> #12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Phab:D3513 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:50:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:50:46 -0000 Subject: [GHC] #13500: GHCi preprocesses every source file on :reload In-Reply-To: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> References: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> Message-ID: <062.acc9b1a3396a3e94fab0a30221be2a34@haskell.org> #13500: GHCi preprocesses every source file on :reload -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: highest | 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:D3398 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as d30ccd45705ca5b613a6282e63ebf48c67369b4d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:51:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:51:52 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors In-Reply-To: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> References: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> Message-ID: <063.938f2c0c6d45c7c8d5abd95a21dc3b31@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T13487 Blocked By: | Blocking: Related Tickets: #12104 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:4 merged to `ghc-8.2` as a97406e978de9bbc333da48cb36d2b65da85dc7a. commment:8 merged as 477e7d2860b2c68c820db004e4ad094f162632ea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:52:22 -0000 Subject: [GHC] #13618: Reified data family instances type variables not related to value constructor fields In-Reply-To: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> References: <044.51f1773cc2fcf5ec9f0a243fd5576e57@haskell.org> Message-ID: <059.6962a95243548d7afc07b527f4793be5@haskell.org> #13618: Reified data family instances type variables not related to value constructor fields -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.2.1-rc1 checker) | Resolution: fixed | 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): Phab:D3505 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as f977b76340aa0924a63592b9262203a7b13dc5b6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 16:55:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 16:55:05 -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.ab30b97d62c9e19db4ab3e0261554ba1@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.4.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): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: While I have a patch for this, it breaks occurrence analysis and I doubt I'll have time to fix it before 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 17:57:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 17:57:13 -0000 Subject: [GHC] #13629: sqrt should use machine instruction on x86_64 In-Reply-To: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> References: <046.4a3e5f0ae22f1713fe095d14d3cfb590@haskell.org> Message-ID: <061.95e1ee2b59c3450ea849b3ef24c81680@haskell.org> #13629: sqrt should use machine instruction on x86_64 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | numeric/num009 Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Phab:D3508 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): The verbose lowering of sqrt that was there before this patch must have stumbled upon some sort of lucky interaction in the processor (arithmetic vs memory unit ports) in that particular hot patch of code in n-body, which is not something that can be relied on in the grand scheme of things. What we ''can'' tell is that this patch produces better code, more closely matching what LLVM produces as well. bgamari has also kindly quantified how much better it is. Thus, I think this ~4% drop in n-body is not something to worry about, as it seems even non-functional changes can knock a few nofib runtime numbers by that amount [1]. Ticket #13570 is also a separate issue: I noticed the poor sqrt lowering when I was investigating that ticket. [1] https://perf.haskell.org/ghc/#revision/945c45ad50ed31e3acb96fdaafb21640c4669f12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:11:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:11:30 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.2e2a951949877218fcf6eeafbaa0a462@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.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 dfeuer): * Attachment "Loop.hs-reduced" added. Reduced version of Loop -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:12:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:12:12 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.2caf72314574f74105fd357df5894bf4@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.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 dfeuer): * Attachment "main.hs-reduced" added. main to go with reduced Loop -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:14:37 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.f24ce99ebc68aaa452604361d206f6a3@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I am getting the very strong feeling that the problem has a lot to do with `UndecidableInstances`, constraint simplification, or something in that general area. Simplifying constraints by hand seems to make the bug go away. Removing the `INLINE` annotation seems to do so as well. I created a reduced test case, which hopefully will be simpler to work on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:15:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:15:19 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> In-Reply-To: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> References: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> Message-ID: <060.f8cd2f21f90c00a78e7bafe356e8fabf@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 7.10.4 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * failure: Incorrect result at runtime => Runtime crash * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:29:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:29:17 -0000 Subject: [GHC] #13623: join points produce bad code for stream fusion In-Reply-To: <048.123971708b7ce58829cc065941274f85@haskell.org> References: <048.123971708b7ce58829cc065941274f85@haskell.org> Message-ID: <063.8b6295e3f9be0702e6e408838fc50f42@haskell.org> #13623: join points produce bad code for stream fusion -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:30:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:30:53 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.354355ddf3b0af662bfda0e16a3d26de@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Changes (by George): * cc: George (removed) * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 18:44:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 18:44:20 -0000 Subject: [GHC] #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.33aaa115eb5e5c711afcf666947b5d6e@haskell.org> #13604: regression in ghc 8.2.1-rc1 (8.2.0.20170404) -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D3514 Comment: I don't think a proper fix can make it for 8.2, so I've put up a revert for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 19:17:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 19:17:13 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.7e3cacca7f1937fedd6a8067f9db95eb@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): The issue isn't GHC 7.6.3 vs. 8.0.2. Rather, it's a 32-bit vs. 64-bit Windows GHC difference. I tested the program on GHC 7.10.2, 7.10.3, and 8.0.2 using both the 32-bit and 64-bit versions, and the 32-bit versions all succeeded whereas the 64-bit versions all failed the second test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 19:40:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 19:40:01 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.27b0fea1c1c10cee1fe874c824dde1f2@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Happily the cause turns out to be simple. In `tidyUnfolding` we tidy the RHS of a stable `CoreUnfolding`. But `CoreUnfolding` also has fields `uf_is_value`, `uf_is_conlike`, etc., which are cached computations on the original RHS. Apparently it's common for these to never be used at any point (the iface will only record `uf_guidance`); so we should evaluate these in `tidyUnfolding`, or just throw away the ones that won't ever be used. I'm in the process of verifying this fix still has the expected result with HEAD. There might be further improvements to be made here, but indications are that this fix at least decreases memory usage during code generation to the point where it is no longer larger than the peak usage during simplification. In other words, max memory usage can't be reduced any more from this side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 19:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 19:42:15 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.6f9b2569825f2bd0d48b68362c2263fd@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): Since I was curious to learn //how// the second test was failing, I cooked up a slight variant of the program: {{{#!hs {-# LANGUAGE PackageImports #-} module Main (main) where import "regex-compat" Text.Regex main :: IO () main = do print $ matchRegexAll (mkRegex "^(a)|(p)$") "p" print $ matchRegexAll (mkRegex "^(ab+c*d?)|(ef{2}g{3,6}h{3,})|(p)$") "p" }}} This requires the `regex-compat` package (a thin shim on top of `regex- posix`). With 32-bit Windows GHC, running this program gives you: {{{ Just ("","p","",[]) Just ("","p","",[]) }}} With 64-bit Windows GHC: {{{ Just ("","p","",["","p"]) Nothing }}} With 64-bit Linux GHC: {{{ Just ("","p","",["","p"]) Just ("","p","",["","","p"]) }}} The most likely culprits are the C files (`regex.h` and friends) that are shipped with `regex-posix`, as they're most likely quite old. I'll see if I can find a more up-to-date version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 20:45:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 20:45:15 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.93af9862eb405a4cbb326e423b763996@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Since the issue appears to be specific to `regex-posix`, I'm going to close this. Moreover, as ezyang notes in https://github.com/haskell/cabal/issues/4336, the `regex-tdfa` library serves as a drop-in replacement for `regex-posix` which //does// pass both of those tests on 64-bit Windows. (I've also verified that `regex-pcre` works as well.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 21:20:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 21:20:08 -0000 Subject: [GHC] #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope In-Reply-To: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> References: <050.565e09c729c0bfb9036ee1e522977124@haskell.org> Message-ID: <065.01e7a2bec031fb5b956ba66b123ac9e7@haskell.org> #13622: Regression: can't export constructor when conflicting, qualified constructor is also in scope -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: mpickering Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3515 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * priority: high => highest * differential: => Phab:D3515 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 21:50:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 21:50:32 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.089b74e756b2fdf3761ace7d9c9955b7@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by kavon): I personally don't see much of a benefit in moving from llc/opt to clang just to merge the interface to LLVM. The only benefit I can imagine is that we can skip the step of having opt generate a .bc and feeding that into llc, though perhaps we can just pipe opt's output directly to llc? This might save some compile time. Otherwise, we can build our own opt & llc and include those if we needed a custom version of LLVM... which is one of my questions, which particular patches for LLVM are needed right now, or is this a preparation step? Off the top of my head, I think the downsides of switching to clang as our interface to LLVM are: - clang limits us to using only the -Ox passes, which are tuned for C/C++. There's likely some benefit to crafting/tuning our own sequence of optimization passes (which is on my todo list). There are also IR passes in LLVM that are not included in the default -Ox sets that could prove useful when tuning. - Special llc flags such as specifying a special stack alignment might be out of reach (not sure how well clang handles options for opt/llc) - AFAIK unoptimized GHC builds prioritize compilation time, running essentially just mem2reg to introduce phi-nodes before handing off to llc. I'm not sure if we can get such customizability with clang. Furthermore, I'm worried that clang's -O0 option will choose llc's -O0 option, which is a _very_ naive register allocator that I believe was meant to aid debugging, because it barely tries to keep values in register from what I've seen it produce. Decoupling LLVM IR optimization and LLVM IR machine code generation lets us still pick a decent register allocator, for example. As an FYI, I'm currently [wiki:Commentary/Compiler/BackendOpt working on the LLVM backend] too, namely, I'm working on removing proc-point splitting when using LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 21:54:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 21:54:27 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.5ba8518954edb037605315bc41343a0c@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Changes (by kavon): * cc: kavon (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 23:40:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 23:40:28 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.1f903472c88d5124bd9c6c1dabd7c644@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * Attachment "ghc-stage2.pdf" added. heap profile with HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 23:40:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 23:40:49 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.3dfda5673d77e2f6c5599992dda97446@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * Attachment "ghc-stage2.2.pdf" added. heap profile with seqUnfolding in tidyUnfolding -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 23:46:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 23:46:36 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.f5e445ec2ac4185f7426be094586aa41@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): After adding `seqUnfolding` there is still a tall but narrow spike in the heap profile. I found that this spike went away with `-v`, so I added a `seqBinds` which also eliminates the spike. Trac won't let me upload another heap profile PDF though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 30 23:51:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Apr 2017 23:51:20 -0000 Subject: [GHC] #13564: Why does memory usage increase so much during CoreTidy? In-Reply-To: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> References: <047.e92939a4cd1c030b3af9ef0cac10654f@haskell.org> Message-ID: <062.30cda72a9fa3fbdcf658bf16599561e6@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * Attachment "ghc-stage2.3.pdf" added. heap profile with seqBinds in tidyTopBinds as well -- Ticket URL: GHC The Glasgow Haskell Compiler