From ghc-devs at haskell.org Wed Mar 1 00:03:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 00:03:55 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.a41f3b4b48e44fea25e2a34baee9b2cb@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): To avoid clutter I will add further examples to this [https://gist.github.com/Icelandjack/1824f4544c86b4ab497282783f94c360 gist]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 00:59:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 00:59:40 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database Message-ID: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Package | 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: -------------------------------------+------------------------------------- It seems that Phab:D3090 (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with, {{{ Creating package registration file: /tmp/pkgConf- compact-0.1.0.1-13684/pkgConf ("/opt/exp/ghc/roots/master/bin/ghc-pkg",["update","-","--global","-- user","-v2"]) /opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error message: ghc-pkg: Couldn't open database /home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification: /home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 01:00:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 01:00:55 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.23c7a8bde1b52b489b98f974cfac1ef9@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: arybczak (added) Comment: Off hand I'm sure what `ghc-pkg` did in this case previously. arybczak, would you be able to look into this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 01:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 01:21:21 -0000 Subject: [GHC] #13355: gmp doesn't build correctly when cross-compiling with clang Message-ID: <047.97137c8ea1f6dfca18c199b187d71be2@haskell.org> #13355: gmp doesn't build correctly when cross-compiling with clang -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The commit in #8497 added this to `libraries/integer-gmp/gmp/ghc.mk`: {{{ CLANG = $(findstring clang, $(shell $(CC_STAGE1) --version)) ifeq "$(CLANG)" "clang" CCX = $(CLANG) else CCX = $(CC_STAGE1) endif }}} and does the build with `$(CCX)` rather than `$(CC_STAGE1)`. However, when cross-compiling, `$(CC_STAGE1)` could be a clang cross- compiler, but then it's certainly not right to use `$(CLANG) = clang`, as that is presumably not a cross-compiler. I don't understand why the issue in #8497 arose in the first place, so it's unclear to me how to proceed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 01:23:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 01:23:24 -0000 Subject: [GHC] #13236: Improve floating for join points In-Reply-To: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> References: <046.131b9b0acf07f9ac039340a172b4672a@haskell.org> Message-ID: <061.40cfffd2293af515b0d1d0de63e4651d@haskell.org> #13236: Improve floating 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 David Feuer ): In [changeset:"6eb52cfc2e31df2561860f43d41766464ccfe8af/ghc" 6eb52cfc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6eb52cfc2e31df2561860f43d41766464ccfe8af" Improve SetLevels for join points C.f. Trac #13286, #13236 * Never destroy a join point unless it goes to top level See Note [Floating join point bindings] * Never float a MFE if it has a free join variable Note [Free join points] * Stop treating nullary join points specially * Enforce the invariant that le_join_ceil >= le_ctxt_lvl (Needs more thought...) Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 01:23:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 01:23:24 -0000 Subject: [GHC] #13286: Late floating of join points In-Reply-To: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> References: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> Message-ID: <061.6ecabedac2607b35468948832591e3db@haskell.org> #13286: Late floating of 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 David Feuer ): In [changeset:"6eb52cfc2e31df2561860f43d41766464ccfe8af/ghc" 6eb52cfc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6eb52cfc2e31df2561860f43d41766464ccfe8af" Improve SetLevels for join points C.f. Trac #13286, #13236 * Never destroy a join point unless it goes to top level See Note [Floating join point bindings] * Never float a MFE if it has a free join variable Note [Free join points] * Stop treating nullary join points specially * Enforce the invariant that le_join_ceil >= le_ctxt_lvl (Needs more thought...) Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 01:26:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 01:26:26 -0000 Subject: [GHC] #13356: gmp/ghc.mk's use of TARGETPLATFORM and BUILDPLATFORM is wrong Message-ID: <047.fe20157f46c7998038a1955d7e7d86ef@haskell.org> #13356: gmp/ghc.mk's use of TARGETPLATFORM and BUILDPLATFORM is wrong -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `libraries/integer-gmp/gmp/ghc.mk` invokes `libgmp`'s configure script with the options {{{ --host=$(TARGETPLATFORM) --build=$(BUILDPLATFORM) }}} Using `TARGETPLATFORM` is wrong, as it is the GHC-munged target triple. For example if the triple passed to the top-level configure script was `--target=aarch64-apple-darwin14` (for iPhone), `TARGETPLATFORM` will be `aarch64-apple-ios`, which `configure` does not understand. Instead of `TARGETPLATFORM` we should use `TargetPlatformFull`. I don't think we have a corresponding variable for `BUILDPLATFORM`, so we should add one if it's important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 03:36:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 03:36:21 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.54c12adfe9f9d631ca8923ba97ee9cc2@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): Ehh, it's a bit tricky. In theory the following fix should do it: {{{#!diff --- a/utils/ghc-pkg/Main.hs +++ b/utils/ghc-pkg/Main.hs @@ -807,7 +807,10 @@ readParseDatabase :: forall mode t. Verbosity readParseDatabase verbosity mb_user_conf mode use_cache path -- the user database (only) is allowed to be non-existent | Just (user_conf,False) <- mb_user_conf, path == user_conf - = mkPackageDB [] =<< F.mapM (const $ GhcPkg.lockPackageDb path) mode + = do lock <- F.forM mode $ \_ -> do + createDirectoryIfMissing True path + GhcPkg.lockPackageDb cache + mkPackageDB [] lock | otherwise = do e <- tryIO $ getDirectoryContents path case e of @@ -828,7 +831,6 @@ readParseDatabase verbosity mb_user_conf mode use_cache path Right fs | not use_cache -> ignore_cache (const $ return ()) | otherwise -> do - let cache = path cachefilename tdir <- getModificationTime path e_tcache <- tryIO $ getModificationTime cache case e_tcache of @@ -888,6 +890,8 @@ readParseDatabase verbosity mb_user_conf mode use_cache path whenReportCacheErrors = when $ verbosity > Normal || verbosity >= Normal && GhcPkg.isDbOpenReadMode mode where + cache = path cachefilename + recacheAdvice | Just (user_conf, True) <- mb_user_conf, path == user_conf = "Use 'ghc-pkg recache --user' to fix." }}} So if we open user database in read/write mode and it doesn't exist, create the missing directory so that we can create a lock file. However, this clashes with the way we try to open a database that contains a specific package for modification: we open in read write mode and if it doesn't contain given package, we "downgrade" to read only by releasing a lock. So in this case we'll always downgrade, because the database is empty and so an empty directory will be left. In particular, it won't contain `package.cache` file and then compiler/main/Packages.hs:readPackageConfig will fail on attempt to read this database, because it expects `package.cache`to be there. I see two possible solutions: 1. We change the way we open database that contains a package for modification: instead of opening in read write mode and downgrading to read only if necessary, we first open in read only and only after we confirm that the database contains a package, we open in read write mode (and then unfortunately we also need to consider the possibility that the database changed between these two reads and downgrade to read only if the package is not there anymore). Although that still has a potential to create the problem if the database is removed between the first read only read and the subsequent read write read :/ 2. We modify compiler/main/Packages.hs:readPackageConfig to catch "not exists" error on reading `package.cache` file and check if the directory contains any `.conf` file. If so, we propagate the error (and possibly print slightly more user friendy message that cache is not there instead of `openBinaryFile: does not exist (No such file or directory)`), but if not, we consider the database to be empty. I think (2) is both simpler and more sensible. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 06:14:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 06:14:29 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.5e93a4ef7c75d5ee790e7f9714b5a351@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"701256df88c61a2eee4cf00a59e61ef76a57b4b4/ghc" 701256df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="701256df88c61a2eee4cf00a59e61ef76a57b4b4" Change catch# demand signature * Give `catch#` a lazy demand signature, to make it more honest. * Make `catchException` and `catchAny` force their arguments so they actually behave as advertised. * Use `catch` rather than `catchException` in `forkIO`, `forkOn`, and `forkOS` to avoid losing exceptions. Fixes #13330 Reviewers: rwbarton, simonpj, simonmar, bgamari, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3244 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 06:15:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 06:15:10 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.6fb60fdee8ef3e21bff855db8a0163a5@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 06:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 06:16:54 -0000 Subject: [GHC] #13357: Check demand signatures for catchRetry# and catchSTM# Message-ID: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> #13357: Check demand signatures for catchRetry# and catchSTM# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #13330 was fixed by giving `catch#` a different (simpler and more honest) demand signature. Are the signatures for `catchRetry#` and `catchSTM#` similarly problematic? We need to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 07:58:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 07:58:27 -0000 Subject: [GHC] #13286: Late floating of join points In-Reply-To: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> References: <046.4117207be66bdbbda608351bbd3dbb23@haskell.org> Message-ID: <061.fe8f9e0f89b0210391d298db3f3c7115@haskell.org> #13286: Late floating of 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: If you read `Note [Floating join point bindings]` you'll see that in the end I decide that we ''should'' float join point to top level if they can go there. I got better results in a handful of cases (see the Note, and comment:1, comment:2), so it seems like a modest win. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:12:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:12:48 -0000 Subject: [GHC] #13068: GHC should not allow modules to define instances of abstract type classes In-Reply-To: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> References: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> Message-ID: <060.9987bb5f524bcf80934e72dec2c4daf1@haskell.org> #13068: GHC should not allow modules to define instances of abstract type classes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3254 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3254 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:13:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:13:46 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.be111bbcf4723823936c2ac7449e1466@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3174 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:17:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:17:32 -0000 Subject: [GHC] #13140: Handle subtyping relation for roles in Backpack In-Reply-To: <045.f307b75ae2f892817529512243583cc2@haskell.org> References: <045.f307b75ae2f892817529512243583cc2@haskell.org> Message-ID: <060.782a07f160c6f38af1eed98777266c97@haskell.org> #13140: Handle subtyping relation for roles in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack hs- Resolution: fixed | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3123 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed Comment: I'm marking this ticket as fixed but I'll open another ticket about role ranges. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:31:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:31:46 -0000 Subject: [GHC] #13358: Role ranges (allow decomposition on newtypes) Message-ID: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> #13358: Role ranges (allow decomposition on newtypes) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Extracted from #13140. Today, there is a strange asymmetry between data types, for which the decomposition rule holds (if `T A ~R T B` then `A ~ρ B`, where ρ is the role of the type), and newtypes, for which the decomposition rule is unsound. I believe the root cause of this problem is the fact that we only maintain a single role per type parameter, while in fact what we need is a role *range* (i.e., and lower and upper role bound) to specify what inferences can be made about a type. Here's how it works. Every type parameter is ascribed a role range, specifying the possible roles by which the type parameter might possibly be used. For example, if I write `data T a = MkT a`, `a` is used exactly at representational role, but we could also say that a *might* be used nominally, giving the role range nominal-representational. The lower bound (nominal is lowest in subroling) specifies at what role the application rule is valid: if I say that the role is at least nominal, then I must provide `a ~N b` evidence to show that `T a ~R T b`. The upper bound (phantom is highest) specifies at what role the decomposition rule is valid. If I say that the role is at most phantom, I learn nothing from decomposition; but if I say the role is at most representational, when `T A ~R T B`, I learn `A ~R B`. Clearly, the role range nominal-phantom permits the most implementations, but gives the client the least information about equalities. How do we tell if a role range is compatible with a type? The lower bound (what we call a role today) is computed by propagating roles through, but allowing substitution of roles as per the subroling relationship `N <= R <= P`. To compute the upper bound, we do exactly the same rules, but with the opposite subroling relation: `P <= R <= N`. Some examples: {{{ type app role T representational type proj role T representational newtype T a = MkT a -- T a ~R T b implies a ~R b type app role T nominal type proj role T representational -- NB: type proj role T nominal is NOT ALLOWED newtype T a = MkT a -- T a ~R T b implies a ~R b, BUT -- a ~R b is insufficient to prove T a ~R T b (you need a ~N b) type app role T nominal type proj role T phantom -- (representational and nominal not allowed) newtype T a = MkT Int -- T a ~R T b implies a ~P b (i.e. we don't learn anything) -- a ~N b implies T a ~R T b }}} Richard wonders if we could use this to solve the "recursive newtype unwrapping" problem. Unfortunately, because our solver is guess-free, we must also maintain the most precise role for every type constructor. See https://ghc.haskell.org/trac/ghc/ticket/13140#comment:12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:33:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:33:39 -0000 Subject: [GHC] #13358: Role ranges (allow decomposition on newtypes) In-Reply-To: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> References: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> Message-ID: <060.ce78784a47b0754e8da4874ed73bc186@haskell.org> #13358: Role ranges (allow decomposition on newtypes) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Extracted from #13140. > > Today, there is a strange asymmetry between data types, for which the > decomposition rule holds (if `T A ~R T B` then `A ~ρ B`, where ρ is the > role of the type), and newtypes, for which the decomposition rule is > unsound. > > I believe the root cause of this problem is the fact that we only > maintain a single role per type parameter, while in fact what we need is > a role *range* (i.e., and lower and upper role bound) to specify what > inferences can be made about a type. Here's how it works. > > Every type parameter is ascribed a role range, specifying the possible > roles by which the type parameter might possibly be used. For example, if > I write `data T a = MkT a`, `a` is used exactly at representational role, > but we could also say that a *might* be used nominally, giving the role > range nominal-representational. > > The lower bound (nominal is lowest in subroling) specifies at what role > the application rule is valid: if I say that the role is at least > nominal, then I must provide `a ~N b` evidence to show that `T a ~R T b`. > The upper bound (phantom is highest) specifies at what role the > decomposition rule is valid. If I say that the role is at most phantom, I > learn nothing from decomposition; but if I say the role is at most > representational, when `T A ~R T B`, I learn `A ~R B`. Clearly, the role > range nominal-phantom permits the most implementations, but gives the > client the least information about equalities. > > How do we tell if a role range is compatible with a type? The lower bound > (what we call a role today) is computed by propagating roles through, but > allowing substitution of roles as per the subroling relationship `N <= R > <= P`. To compute the upper bound, we do exactly the same rules, but with > the opposite subroling relation: `P <= R <= N`. > > Some examples: > > {{{ > type app role T representational > type proj role T representational > newtype T a = MkT a > -- T a ~R T b implies a ~R b > > type app role T nominal > type proj role T representational > -- NB: type proj role T nominal is NOT ALLOWED > newtype T a = MkT a > -- T a ~R T b implies a ~R b, BUT > -- a ~R b is insufficient to prove T a ~R T b (you need a ~N b) > > type app role T nominal > type proj role T phantom -- (representational and nominal not allowed) > newtype T a = MkT Int > -- T a ~R T b implies a ~P b (i.e. we don't learn anything) > -- a ~N b implies T a ~R T b > }}} > > Richard wonders if we could use this to solve the "recursive newtype > unwrapping" problem. Unfortunately, because our solver is guess-free, we > must also maintain the most precise role for every type constructor. See > https://ghc.haskell.org/trac/ghc/ticket/13140#comment:12 New description: Extracted from #13140. Today, there is a strange asymmetry between data types, for which the decomposition rule holds (if `T A ~R T B` then `A ~ρ B`, where ρ is the role of the type), and newtypes, for which the decomposition rule is unsound. I believe the root cause of this problem is the fact that we only maintain a single role per type parameter, while in fact what we need is a role *range* (i.e., and lower and upper role bound) to specify what inferences can be made about a type. Here's how it works. Every type parameter is ascribed a role range, specifying the possible roles by which the type parameter might possibly be used. For example, if I write `data T a = MkT a`, `a` is used exactly at representational role, but we could also say that a *might* be used nominally, giving the role range nominal-representational. The lower bound (nominal is lowest in subroling) specifies at what role the application rule is valid: if I say that the role is at least nominal, then I must provide `a ~N b` evidence to show that `T a ~R T b`. The upper bound (phantom is highest) specifies at what role the decomposition rule is valid. If I say that the role is at most phantom, I learn nothing from decomposition; but if I say the role is at most representational, when `T A ~R T B`, I learn `A ~R B`. Clearly, the role range nominal-phantom permits the most implementations, but gives the client the least information about equalities. How do we tell if a role range is compatible with a type? The lower bound (what we call a role today) is computed by propagating roles through, but allowing substitution of roles as per the subroling relationship `N <= R <= P`. To compute the upper bound, we do exactly the same rules, but with the opposite subroling relation: `P <= R <= N`. Some examples: {{{ type role T representational..representational newtype T a = MkT a -- T a ~R T b implies a ~R b type role T nominal..representational -- NB: nominal..nominal illegal! newtype T a = MkT a -- T a ~R T b implies a ~R b, BUT -- a ~R b is insufficient to prove T a ~R T b (you need a ~N b) type role T nominal..phantom -- NB: nominal..representational illegal! newtype T a = MkT Int -- T a ~R T b implies a ~P b (i.e. we don't learn anything) -- a ~N b implies T a ~R T b }}} Richard wonders if we could use this to solve the "recursive newtype unwrapping" problem. Unfortunately, because our solver is guess-free, we must also maintain the most precise role for every type constructor. See https://ghc.haskell.org/trac/ghc/ticket/13140#comment:12 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:34:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:34:18 -0000 Subject: [GHC] #13335: Non-abstract types also have skolem nature In-Reply-To: <045.1cd550b891f74e462b3401513f54bedb@haskell.org> References: <045.1cd550b891f74e462b3401513f54bedb@haskell.org> Message-ID: <060.321e704f75b6b21f9a4f3f417d02c65f@haskell.org> #13335: Non-abstract types also have skolem nature -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:34:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:34:44 -0000 Subject: [GHC] #13323: Backpack doesn't work with DuplicateRecordFields In-Reply-To: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> References: <045.447bd0a3ac2a0cc00487939ecdd4f71e@haskell.org> Message-ID: <060.f7312aa828faee6e7e83a987919b4593@haskell.org> #13323: Backpack doesn't work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3175 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:35:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:35:40 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.16bdd2d6a3c9dc9f79742d03af66273e@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: dfeuer => (none) * status: closed => new * resolution: fixed => Comment: This is a tricky area so I'd like to be quite sure I understand. Several things: * The `$exceptions_and_strictness` note in `GHC/IO.hs` says > While @test1@ will print "it failed", @test2@ will print "uh oh". Previously it said that `test2` was unpredictable. Are we saying that both are now predictable? That's good but why? * The note does not say that the only difference between `catchException` and `catch` is that the former is strict in the action. Indeed, it'd be better to make that point in the doc for `catchException` itself; it's the ''only'' difference between the two. > Since this strictness is a small optimization and may lead to surprising results, all of the @catch@ and @handle@ variants offered by "Control.Exception" use 'catch' rather than 'catchException'. * But the comment is confusing. If `catchException` is more efficient (and we might want to say why) should we not use it all the time in the libraries if we can? What are the "surprising results" that you have in mind? * Moreover, specifically what "handle variants" do you have in mind? `handle` and `handleJust`? But also `catchJust`. ------------- Finally, does this efficiency matter? What is the nofib perf loss if we use `catchException = catch`? And if there is some, can we see a poster- child example so we can really understand when it's important? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:41:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:41:50 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.42797653ea909f860bfbfa47f4716e71@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Roles Operating System: 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: => Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:41:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:41:58 -0000 Subject: [GHC] #13347: Abstract classes in hs-boot should not be treated as injective In-Reply-To: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> References: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> Message-ID: <060.22062bdc49fd2f97d2fb7a9f0d21f263@haskell.org> #13347: Abstract classes in hs-boot should not be treated as injective -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D3236 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:42:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:42:07 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.034b6257f49081e468ada7179d9afb71@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T9117{,_2,_3} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D546 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:42:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:42:17 -0000 Subject: [GHC] #13347: Abstract classes in hs-boot should not be treated as injective In-Reply-To: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> References: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> Message-ID: <060.3a2bee7401418953f11f5225c7b22723@haskell.org> #13347: Abstract classes in hs-boot should not be treated as injective -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:42:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:42:22 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.6577f2ea09e90069b3cb628dad972268@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9117 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:42:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:42:45 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.bf9cec887c450a0ff7ec9bc7ef711238@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:42:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:42:54 -0000 Subject: [GHC] #9131: Experiment with a dedicated solver for Coercible In-Reply-To: <046.fb02102a150822314d950303bdd7564a@haskell.org> References: <046.fb02102a150822314d950303bdd7564a@haskell.org> Message-ID: <061.feea7daac00a6a4b00030b98659014c9@haskell.org> #9131: Experiment with a dedicated solver for Coercible -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Roles Operating System: 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: => Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:43:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:43:51 -0000 Subject: [GHC] #13358: Role ranges (allow decomposition on newtypes) In-Reply-To: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> References: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> Message-ID: <060.961aad13997ec42d1adf17a6df18e8eb@haskell.org> #13358: Role ranges (allow decomposition on newtypes) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack, Resolution: | Roles Operating System: 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: backpack => backpack, Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:45:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:45:38 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.626098a1223d059fc5802770b2b66dce@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: Typeable, LevityPolymorphism => Typeable, LevityPolymorphism, Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:53:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:53:57 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.afa1c2f6d2205f7db2f0ce0d437ffbb4@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3243 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with comment:1. Let's adopt (2) for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:55:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:55:43 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.0dc1caad242a086fcd741e028cb17795@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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): That does look bogus. Thanks for looking at it Ryan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 08:59:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 08:59:51 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.106f3896f4f1755de1d75802d8b7a626@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: 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): Just to record that Richard and I agreed that `constrainKind` currently has a bug. If `co :: Constraint ~ TYPE r`, then {{{ coercionKind (mkNthCo 0 (mkKindCo co)) }}} should succeed with `LiftedRep ~ r` but will fail because `Constraint` is syntactically `TYPE LiftedRep`. Stop-gap solution: * Make `coreView` do what `coreViewOneStarKind` does now; that is, expand `Constraint` to `TYPE LifteRep`. * Make the typechecker variants of `tcSplitTyConApp`, `tcSplitApp` use `tcView`; and make `tcView` '''not''' do this expansion. That is a more honest reflection of what is actually happening, until we fix it properly. Richard will have a go at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:01:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:01:45 -0000 Subject: [GHC] #13268: Backpack doesn't work with Template Haskell, even when it should In-Reply-To: <045.cd14580b3e7c600311b01bfb065b9b08@haskell.org> References: <045.cd14580b3e7c600311b01bfb065b9b08@haskell.org> Message-ID: <060.a07acc59001524aa5a694cf18c1c0629@haskell.org> #13268: Backpack doesn't work with Template Haskell, even when it should -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: invalid | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: This is a Cabal bug, because Cabal is specifying hs-libraries when it doesn't exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:27:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:27:24 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently In-Reply-To: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> References: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> Message-ID: <061.df99c8b93a9307cfdd78a8d62cdf5a71@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | 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 simonpj): > So it seems that after splitting the function into two pieces, it is small enough(?) so that both pieces inline? Yes that is galling I agree. * Part of the trouble is that strictness analysis does a deep semantic analysis, pulls all the evals to the top, inlines them unconditionally, leaving behind a worker that may now be a lot smaller. The `sizeExpr` code in `CoreUnfold` is necessarily much simpler. * The discount we award for a scrutinised argument is computed in `size_up` here: {{{ alts_size (SizeIs tot tot_disc tot_scrut) -- Size of all alternatives (SizeIs max _ _) -- Size of biggest alternative = SizeIs tot (unitBag (v, 20 + tot - max) `unionBags` tot_disc) tot_scrut }}} For a single-alternative case (and you have a tuple arg here) `tot` = `max`, so there's fixed discount of 20. You could make that into a controllable flag and try varying it. * Idea. If a function ''starts'' with `case x of blah` (even if wrapped in lets) we know that the strictness analyser will find it strict in x. So we know it'll generate a wrapper, and the wrapper will inline. So in the end it'll be as if that case cost nothing at all. It would not be hard to make `sizeExpr` simply count zero for the cost of such cases; including nested. (Certainly for single-alternative ones.) Worth a try? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:34:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:34:18 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently In-Reply-To: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> References: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> Message-ID: <061.8cd328cd57ea68166c6b48f6c3d4face@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | 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 simonpj): > Also, in all cases, map id remains, which should not be the case. I think we are missing {{{ {-# RULES "mapFB/id" forall c. mapFB c (\x->x) = c #-} }}} Want to try adding that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:34:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:34:31 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.d867398c376b9ad8375ae95908923bee@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): This seems to be more complicated than just lifting the restriction, because whenever we have a wanted Show (F T) (where F is the type family), we always flatten this into Show a, a ~ F T; and of course, there is never an instance of Show for a in the top-level. I'm not entirely sure how the solver solves this when Show (F T) is a local constraint; some guidance here would be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:34:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:34:56 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently In-Reply-To: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> References: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> Message-ID: <061.22a867b0593a46e5b2e5a26c7a14065b@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | 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 simonpj): > I just had a project where it made a difference whether I add `{-# RULES "foldr/nil" forall k n . GHC.Base.foldr k n [] = n #-}` to my file or not, despite this rule already being present in the library. I have no explanation for that!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:37:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:37:50 -0000 Subject: [GHC] #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary In-Reply-To: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> References: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> Message-ID: <061.727bdc917143ddad3210ac9aa632f057@haskell.org> #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this is #13343. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:38:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:38:49 -0000 Subject: [GHC] #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar In-Reply-To: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> References: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> Message-ID: <065.aad08a390e59c4b51cfcbc7ee961fd39@haskell.org> #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire Comment: See comment:10 of #11827 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:43:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:43:13 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.4f0f757964050b98eb6a458cc02dcd0d@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's not do this unless there is a really compelling reason. More complication. And soon you'll want {{{ type instance F (G [a]) = blah }}} to work, assuming that `G [a]` can reduce to (say) `[Tree a]`. This way lies madness. Let's not complicate the language of type patterns. Yet anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 09:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 09:57:44 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.80224bb2afc787fac5d74004ebbc3f76@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There is a good reason for (2). Consider {{{ let x = C "foo"# in .x..x..x.....case x of { C s -> ...s...s... }.... }}} We'll do case-of-known-constructor on the case expression, binding `s` to the component. Ah! The component is `"foo"#` so we'll duplicate `"foo"#` at every occurrence of `s`. That is why we do ANF for let-bound constructors. I think we should continue to do so. (Unless, just possibly, the let-binding has a NOINLINE pragma...) For (3) I agree. The only reason to aggressively float literals would be for CSE. ------------- More generally, if it is ''really'' the case that these top level bindings {{{ x = "foo#" y = C x }}} take a lot longer to compile (code generate?) than {{{ y = C "foo"# }}} then I think we should seek insight into ''why''. There is no good reason for it to take longer. Let's not bend ourselves out of shape to accommodate what may possibly be an easily-fixed perf bug in the back end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 10:27:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 10:27:21 -0000 Subject: [GHC] #13358: Role ranges (allow decomposition on newtypes) In-Reply-To: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> References: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> Message-ID: <060.6b9a2a46e341ca9b3c5948e5c2e5ffef@haskell.org> #13358: Role ranges (allow decomposition on newtypes) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack, Resolution: | Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 14:15:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 14:15:48 -0000 Subject: [GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c Message-ID: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c ------------------------------+------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- When you press and hold Ctrl-c, after a few seconds, sometimes > 60 sec, GHCi crash and we can read a message on the screen (of the console) who says: {{{ ghc.exe : failed to create OS thread }}} On the task manager we can read: {{{ ghc memory : 36920K }}} initially, then the memory grows about {{{ ghc memory : 43480K }}} and stay until the crash. I repeated it several times. With Linux if you repeat this, GHCi do not crash. Idem with only the Windows console. Hope this help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 15:08:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 15:08:02 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.d919eecf1ae05b04f9ab6bd5ca3f40c5@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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): Phab:D3257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3257 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 15:47:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 15:47:59 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.2f4617dbeb3fc7cfdfdc5db013295e3e@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): In case it's helpful, I've come up with a much simpler case: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Exh where class Foo a where foo :: Maybe a data Result a b = Neither | This a | That b | Both a b q :: forall a b . (Foo a, Foo b) => Result a b q = case foo :: Maybe a of Nothing -> case foo :: Maybe b of Nothing -> Neither Just c -> That c Just i -> case foo :: Maybe b of Nothing -> This i Just c -> Both i c }}} This produces the following warnings, both of them incorrect: {{{ Exh.hs:13:20: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: Just c -> ... | 13 | Just c -> That c | ^^^^^^^^^^^^^^^^ Exh.hs:15:20: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: Nothing -> ... | 15 | Nothing -> This i | ^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 15:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 15:50:30 -0000 Subject: [GHC] #12949: Pattern coverage checker ignores dictionary arguments (was: Pattern coverage mistake) In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.15079835115bcfef9613f48d03cfdf95@haskell.org> #12949: Pattern coverage checker ignores dictionary arguments -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 17:22:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 17:22:03 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints Message-ID: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | 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: -------------------------------------+------------------------------------- GHC is careful to not infer a HasCallStack constraint for a function, because the user didn't ask for one, it would complicate the type, and because it would incur some runtime overhead. I think this is the right default, but it can make debugging exceptions tedious as you have to manually add HasCallStack constraints to the entire chain of functions in the stack. I sometimes use CPP to give myself a flag to toggle the constraints, but I'd rather not have to resort to CPP. Instead, it would be nice if GHC supported a `-finfer-hascallstack` flag (off by default) that would simply generalize over the HasCallStack constraints rather than defaulting them. Then, if my program blows up I can simply recompile with `-finfer-hascallstack` and get a more informative trace. No manual editing, no preparation with CPP, easy! Furthermore, if we had such a flag, it might be nice to '''enable''' it by default in ghci. The two prime concerns are 1. Complicating type signatures. But `:t` solves the HasCallStack constraint before printing the type, so this is only a concern if you use `:i`. 2. Runtime overhead. I don't think this is a valid concern in ghci. I think this would be a nice and simple improvement to the debugging experience. The downside is that even with `-finfer-hascallstack` you would not get full call-stacks for functions in an imported module that was compiled normally. So this would not help with e.g. partial functions in `base`. (It would be really nice to find a solution to this that doesn't involve building modules in multiple ways..) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 17:26:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 17:26:33 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.848af01b575bdb807dfbf580347ce26c@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, I definitely think more needs to be done in this area. I'm not yet convinced that `catchException` is really useful at the moment; we should probably just use `catch`, and force exactly what we need to. I am also concerned about `catchRetry#` and `catchSTM#` (see #13357). However, I just realized that we probably ''can'' do something a bit more interesting with `catch`. In particular, something definitely used by ''both'' the action ''and'' the recovery function can safely be forced in advance. So if we see, for example, {{{#!hs f x = (x `seq` ...) `catch` \e -> x `seq` ... }}} then we can surely use {{{#!hs f x = IO $ \s -> x `seq` unIO (... `catch` ...) }}} I don't yet know enough about the demand analysis algorithm to see how to do this, but it seems rather likely to be worth trying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 17:52:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 17:52:57 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.7436c6c8fc657a6f191d686530cebf53@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Strangely enough this test appears to be unexpectedly passing as of 701256df88c61a2eee4cf00a59e61ef76a57b4b4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 19:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 19:02:36 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.9c5079fb468bda3998dba6bc5eb8199d@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Oh all right. We can wait till someone else pipes in and requests this :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 19:22:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 19:22:21 -0000 Subject: [GHC] #10749: Boot file instances should imply superclasses In-Reply-To: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> References: <045.db4e226ba3e13bafad10871c24246b1d@haskell.org> Message-ID: <060.c24f912d2831f591f17af2206297e050@haskell.org> #10749: Boot file instances should imply superclasses -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I took a look into solving this, but I realized that I don't actually know how we normally report an error when an instance declaration is made but the superclasses do not hold. The error isn't reported until late when we're discharging top-level wanteds so I actually have no idea where the wanted is coming from (or why it's not coming in the case of hs-boot.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 19:26:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 19:26:44 -0000 Subject: [GHC] #12703: Expand Backpack's signature matching relation beyond definitional equality In-Reply-To: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> References: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> Message-ID: <060.9a78264e178a94fe07646e000480e886@haskell.org> #12703: Expand Backpack's signature matching relation beyond definitional equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): One of the main technical challenges is extending our declaration merging operation to handle any such subtyping relation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 19:27:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 19:27:30 -0000 Subject: [GHC] #13358: Role ranges (allow decomposition on newtypes) In-Reply-To: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> References: <045.4cf37300fb076ce156dcc3891b7818d0@haskell.org> Message-ID: <060.1587350a7d8d0a52453d3b35d9e79a84@haskell.org> #13358: Role ranges (allow decomposition on newtypes) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: backpack, Resolution: | Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 19:36:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 19:36:42 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.603f041534fc079946def6044cd2793e@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Actually, the orphan instance is a family instance, so this is just a case of #13102, I think! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 19:48:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 19:48:24 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.cb09a00ad54277ff88b982d0fb55f8b1@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Simon, it looks like you implemented the first bullet point in your comment above in 55efc9718b520ef354e32c15c4b49cdfecce412f "Combine identical case alternatives in CSE", though the old version is commented out. {{{#!diff +noCSE :: InId -> Bool +noCSE id = not (isAlwaysActive (idInlineActivation id)) + -- See Note [CSE for INLINE and NOINLINE] + || isAnyInlinePragma (idInlinePragma id) + --isStableUnfolding (idUnfolding id) + -- See Note [CSE for stable unfoldings] + || isJoinId id + -- See Note [CSE for join points?] }}} Did you mean to commit this in this form? It did fix the test associated to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 20:00:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 20:00:17 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.2c1309999e15868ef60ae48d2be43e08@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: commit 55efc9718b520ef354e32c15c4b49cdfecce412f {{{ Author: Simon Peyton Jones Date: Tue Feb 28 16:00:49 2017 -0500 Combine identical case alternatives in CSE See Note [Combine case alternatives] in CSE. This opportunity surfaced when I was was studying early inlining. It's easy (and cheap) to exploit, and sometimes makes a worthwhile saving. Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3194 }}} This change seems to handle enough recursive cases to solve the problem in this case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 21:07:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 21:07:12 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.6c3745c586b51bb96a0582eba6010387@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So I did! I was fixing a whole bunch of things, noted this problem, fixed it, and forgot. Then when building the patch sequence I accidentally swept this into the equal-alts patch. I think it'll do fine as-is. Could you add language in `Note [CSE for stable unfoldings]` to explain the use of `isAnyInlinePragma`; and point to this ticket? And delete the commented-out `isStableUnfolding`. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 21:28:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 21:28:13 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.d75a44319d871434dcdf6b9b2b3ab172@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Blimey you are right. Yes, this patch also implements CSE for recurive bindings, as described by `Note [CSE for recursive bindings]`. At least I wrote the Notes! A regression test would be good...re-opening just for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 21:31:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 21:31:51 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.a7217c8ab90ef81c5972c3f28a2fdfda@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | 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): Reasonable idea and easy to implement. What about functions that have a user-supplied type signature? It'd be a bit more awkward, perhaps not impossible, to add a `HasCallStack` constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 22:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 22:07:01 -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.20e928b9950dd0465c3bbda7cf16d40d@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Status on this: Reid/David are going to look into why so much time is going into Lint. Any progress on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 22:36:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 22:36:21 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.c4511454631676466dcbb25deafb5a1e@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree, (2) sounds quite reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 23:13:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 23:13:36 -0000 Subject: [GHC] #12949: Pattern coverage checker ignores dictionary arguments In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.e8963d0e15deaedec95cead7b46f7d96@haskell.org> #12949: Pattern coverage checker ignores dictionary arguments -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): gkaracha, does that help? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 23:16:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 23:16:58 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.ca2b90900e6b1ce7e7c62eb304f44764@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Demand signatures are not expressive enough to express the either/or demand you want in comment:14. Sorry. Not even close. My questions in comment:13 stand though. What goes wrong (in behavior or perf) if we just say `catchException = catch`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 1 23:41:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Mar 2017 23:41:22 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.e7736feabfa348cc54dbb599be4e0e42@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:15 simonpj]: > Demand signatures are not expressive enough to express the either/or demand you want in comment:14. Sorry. Not even close. > > My questions in comment:13 stand though. What goes wrong (in behavior or perf) if we just say `catchException = catch`? I haven't tried `catchException = catch` yet. I'll take a look at that soon. Are you sure demand signatures aren't close to expressive enough for what I want? Because they ''look'' fairly close. We have a way to talk about either-or demand for `case` branches. We have something fairly close to {{{#!hs m `catch#` f = \s -> case ORACLE m s of Succeeded -> m s Failed e -> f e s }}} If we're analyzing ``m `catch#` f``, can't we find the demands for `m` applied to one argument and for `f` applied to two? Because then we can take their least upper bound and get demands for the whole thing applied to the `realWorld#`, right? That doesn't give `catch#` itself a terribly demand signature, but it shouldn't matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 00:12:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 00:12:40 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.177ca97b7337794e10f8bbff362dd63c@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, you could have a special rule for `catch` as we do for `case` I suppose. But we can't express it in the demand signature for `catch`; demand signatures aren't expressive enough. But before cluttering up the demand analyser with special cases, I'd like to see evidence that it made a material difference. I doubt it would. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 00:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 00:17:41 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.af95c08e88322ab5ff634136eb9f9290@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: My suggestion would be that if `RankNTypes` is already on and a user incorrectly uses a dot as above, then the error message should say something like: {{{ Perhaps you meant to write 'forall . '? }}} Not the greatest error message in the world, but still better than the status quo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 01:22:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 01:22:15 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.607ce4b2f5faa78a997e71eb96fbe40c@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * cc: crockeea (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 03:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 03:42:25 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.c8776a28d3f67eaccb28ee453eacc904@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3259 Wiki Page: | -------------------------------------+------------------------------------- Changes (by arybczak): * status: new => patch * differential: => Phab:3259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 03:43:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 03:43:33 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.67e02393a5b74f983d7b474de2ad3f0d@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3259 Wiki Page: | -------------------------------------+------------------------------------- Changes (by arybczak): * differential: Phab:3259 => Phab:D3259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 04:49:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 04:49:51 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.6630eef3b0345be8a3b7e40fdc66d6b9@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 gridaphobe): I think I would want GHC to inject `HasCallStack` into explicit type signatures. One possibility would be to just always add `HasCallStack` as a top-level given, and then silently drop it if it's found to be unused. I know GHC already has code to warn about unused constraints, but I don't know how awkward it would be to make use of that for this purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 04:55:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 04:55:09 -0000 Subject: [GHC] #13361: Better type synonym merging/subtyping for Backpack Message-ID: <045.a42d7c0ae819d1b189509b0bf9b7f21f@haskell.org> #13361: Better type synonym merging/subtyping for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here are two signatures which don't merge today in Backpack: {{{ signature A where data T data U = Mk T signature A where data S data U = Mk S }}} On the one hand, this is not too surprising, because you never said that T and S were the same, so why should I decide that the declarations of U are compatible? OK, but suppose I were to add the missing type synonym: which direction should I put it? What you will find is that, under Backpack's current subtyping rules, *neither* orientation is a subtype of the other: {{{ signature A where data T type S = T data U = Mk T signature A where type T = S data S data U = Mk S }}} The first signature is a supertype of a module that says `data T = MkCommon`, but NOT of a module that says `data S = MkCommon`, since type synonym declarations and data declarations are not compatible. This doesn't smell very good. Indeed, ML's semantic signatures do not have this problem, because when I write these signatures, I actually get a semantic signature of the form `exists c. { type T = c, type S = c, ... }`; i.e., neither declaration is privileged. On the other hand, our behavior is inline with MixML, which does not have these as mutual subtypes. So it's not clear the complexity of changing our internal language justifies the marginal benefit that is to be gotten here. Not planning on fixing this unless someone shouts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 05:38:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 05:38:04 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.737ae81a356ac7855722939d85d1a52e@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): Replying to [comment:18 RyanGlScott]: > Alright. I've opened up #13324 to track the feature request for using type wildcards in derived instance contexts, since that has applications besides `derive-topdown`. > > Song, would this approach work for your needs? Thanks, but I think there still is one problem. When writing the TH code, I encountered three problems. One is the context generation problem which you are trying to solve for me. Another is type synonym. I want to expand it to data or newtype declaration to generate instance, but now I forced user to use `XTypeSynonymInstances`. Richard introduced me `th-expand-syns` which I am not quite sure how it can be used to help on my problem now. The last problem is the most severe one. It is about `isInstance` function. My process of generation standalone instances is dead simple by using type `StateT [Type] Q [Dec]`. The roughly sketched algorithm is the following: For a type `T`, get all its arguments of data constructors and prepare to generate instance of class `C`. But before the generation, for each of the argument `arg_n` we check two things: 1, whether the type `arg_n` already an instance of the class which may be built in GHC. (by using `isInstance` function in `Langauge.Haskell.TH`) 2, whether it has already been generated. (by looking into the state hold by the state monad) If neither the case, we generate an standalone declaration and add the type into the list of state monad for avoiding future duplicated generation. After that call the instance generation function recursively. The above two cases are the base cases for the recursion. The problem is: For case 1, we cannot check a type such as `[a]`, `(a,b)` is an instance of Eq or Ord with `isInstance` function, no matter we give the type class context or not: {{{ {-# LANGUAGE TemplateHaskell,QuasiQuotes,ExplicitForAll #-} import Language.Haskell.TH char :: Q Bool char = do char_t <- [t| Char |] isInstance ''Eq [char_t] > $(char >>= stringE.show) "True poly_a :: Q Bool poly_a = do poly_a_t <- [t| forall a. Eq a => [a] |] isInstance ''Eq [poly_a_t] > $(poly_a >>= stringE.show) "False" poly_a' :: Q Bool poly_a' = do poly_a_t <- [t| forall a. [a] |] isInstance ''Eq [poly_a_t] -- False pair :: Q Bool pair = do pair_t <- [t| forall a b. (a,b) |] isInstance ''Eq [pair_t] -- False pair' :: Q Bool pair' = do pair_t <- [t| forall a b. (Eq a, Eq b) => (a,b) |] isInstance ''Eq [pair_t] -- False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 08:35:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 08:35:33 -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.6230e115cdec9944365d5c56c9ffc7cb@haskell.org> #13242: Panic "StgCmmEnv: variable not found" with ApplicativeDo and ExistentialQuantification -------------------------------------+------------------------------------- Reporter: ljli | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"d118807d141abe4031fdcb1a4db3596dac00c7c7/ghc" d118807/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d118807d141abe4031fdcb1a4db3596dac00c7c7" Document interaction between ApplicativeDo and existentials (#13242) Test Plan: validate Reviewers: austin, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3256 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 08:40:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 08:40:19 -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.1e46e3b155b8af09421ef3c20384bcce@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: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 12:46:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 12:46:14 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default Message-ID: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: numa cache gc | 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 will improve performance a lot by default. If anyone needs different size - there is "-A" RTS option. Machines are very different. Currently this size is 512k by default for all different architectures and hardware no matter what. In most cases machines with larger caches have more RAM as well and vice versa. So this will affect positively both small and larger machines. It will be most efficient in most cases to keep short lived objects in caches. Most modern workstation and server machines have L3 cache as well, that is why I'm asking for "largest cache size". Second idea will be if there are two short lived generations on machines with second and third level caches with sizes that match both. For NUMA machines with non-unified caches (like [http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825 this strange and non-common ARM]) the common solution could be to set first generation to be with size of the largest cache of smallest core. Which will not be the optimal, but close to. [https://www.reddit.com/r/haskell/comments/5rf1r5/ghc_first_generation_of_gc_to_be_as_large_as/ Related Reddit discussion] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 14:39:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 14:39:42 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings Message-ID: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | 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 this program: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 }}} This compiles with no warnings with `-Wall`. But if you tweak `catchAll` to add a catch-all case at the end: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 catchAll _ = error "impossible" }}} Then if you compile it with `-Wall`, you'll get a very misleading warning: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -Wall GHCi, version 8.1.20170228: 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:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘catchAll’: catchAll TooGoodToBeTrue = ... | 17 | catchAll TooGoodToBeTrue = 1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I would have expected the warning to be on the `catchAll _ = error "impossible"` case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 15:15:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 15:15:31 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.853f0e0130e9735d89fff892177119a2@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard and I discussed the bug mentioned in comment:1. Solution {{{ Don't do solveEqualities unless you are generalising (to solve #13337), in tc_hs_sig_type }}} Richard will work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 15:32:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 15:32:23 -0000 Subject: [GHC] #13364: Remove checkValidTelescope Message-ID: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> #13364: Remove checkValidTelescope -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- All of this new `TypeInType` nonsense has provided a number of ways that we can arrive at ill-scoped kinds. Let's assume we have {{{ data SameKind :: k -> k -> Type }}} and then here are three subtly ill-scoped kinds: {{{ forall a (b :: a) (c :: Proxy d). SameKind b d forall a. forall (b :: a). forall (c :: Proxy d). SameKind b d forall d. forall a (b :: a). SameKind b d }}} Despite the close similarity between these cases, they are all handled separately. See `Note [Bad telescopes]` in !TcValidity for an overview, but these are spread between `tcImplicitTKBndrsX`, `tcExplicitTKBndrsX`, and those functions' calls to `checkValidTelescope`, `checkZonkValidTelescope`, and `checkValidInferredKinds`. While I am unaware of a concrete bug this all causes, it's a mess. Better would be to use the existing machinery to prevent skolem-escape: `TcLevel`s and implication constraints. Specifically, it's quite plausible that all this can be avoided by a simple rule: bump the `TcLevel` (and create an implication constraint) for ''every'' new type variable brought into scope (including implicitly). (Actually, implicit variables have an implicit ordering that GHC is free to decide, so all implicitly bound variables should be brought into scope at once, with just one bump in the `TcLevel`.) It might all just work! And then we can delete gobs of hairy code. Hooray! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 15:32:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 15:32:35 -0000 Subject: [GHC] #13364: Remove checkValidTelescope In-Reply-To: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> References: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> Message-ID: <062.3c3c1dd567eccab8b90937925ce5721d@haskell.org> #13364: Remove checkValidTelescope -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire 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 goldfire): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 15:35:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 15:35:05 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.921eadb1730e1576c68064ff183e5f2a@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: (none) => goldfire Comment: Included in that work should be a check of all uses of `solveEqualities` to make sure that they make sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 15:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 15:36:16 -0000 Subject: [GHC] #13364: Remove checkValidTelescope In-Reply-To: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> References: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> Message-ID: <062.c9927cecaf2970816efea809ed73edd1@haskell.org> #13364: Remove checkValidTelescope -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | 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 Thu Mar 2 15:56:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 15:56:44 -0000 Subject: [GHC] Trac email verification for user: ruperthorlick Message-ID: <20170302155644.2F66E3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: ruperthorlick Verification Token: OCnLqZml -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 16:08:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 16:08:21 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs Message-ID: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | 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: -------------------------------------+------------------------------------- With `-XPolyKinds`, GADTs require kind signatures where they should be inferred. Moreover, the error when these kind sigs are omitted is baffling. {{{ {-# LANGUAGE PolyKinds, GADTs #-} import GHC.TypeLits data C (x :: k) a where C1 :: (KnownNat x) => a -> Foo x a C2 :: a -> Foo Int a }}} {{{ error: • Expected kind ‘k’, but ‘x1’ has kind ‘Nat’ • In the first argument of ‘Foo’, namely ‘x’ In the type ‘Foo x a’ In the definition of data constructor ‘C1’ }}} From this error, I would never expect that putting a kind signature on `a` would help here. But a signature shouldn't be required at all: it's clear from the GADT constructors that `a :: *`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 16:15:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 16:15:13 -0000 Subject: [GHC] #12429: Pattern synonym parse error should recommend enabling extension In-Reply-To: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> References: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> Message-ID: <064.4b5c0e4ee60f0e4df4ab3e9ab514d5b5@haskell.org> #12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: ruperthorlick Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T12429 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * owner: (none) => ruperthorlick * testcase: => parser/should_fail/T12429 * version: 7.10.3 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 17:22:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 17:22:16 -0000 Subject: [GHC] #12429: Pattern synonym parse error should recommend enabling extension In-Reply-To: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> References: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> Message-ID: <064.2ee8e5febc5ce8fef0bcbde6dfde3a6b@haskell.org> #12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: ruperthorlick Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T12429 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3261 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * status: new => patch * differential: => Phab:D3261 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 17:34:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 17:34:30 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.40ac755c98d7527c7d3ca15b56fdbaf4@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ruperthorlick Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T12811 Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): D3262 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * owner: (none) => ruperthorlick * testcase: => parser/should_fail/T12811 * differential: => D3262 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 17:34:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 17:34:52 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.55833df5b01589d94981f94a702d9957@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ruperthorlick Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T12811 Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): D3262 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 17:37:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 17:37:10 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.2c0d0824228e7ab500f2a196f93bbb49@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ruperthorlick Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T12811 Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): Phab:D3262 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D3262 => Phab:D3262 Comment: Thanks, Rupert! By the way, the syntax that Trac expects for Phab tickets is (somewhat annoyingly) Phab:D3262, not D3262. I went ahead and fixed it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 18:14:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 18:14:15 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.61069cb280e98158d594787d79f105cb@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | 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: 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 Thu Mar 2 18:22:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 18:22:38 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.6404201f728a105b87141bd8ea8b3053@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10823 | Differential Rev(s): Phab:D3073 Wiki Page: | -------------------------------------+------------------------------------- Comment (by abakst): Here is one benefit of moving `simpleOptPgm` to a separate pass: I am currently writing a static analysis as a CoreToCore plugin pass. Consider the following: {{{ {-# OPTIONS_GHC -fplugin Analysis.Plugin -fplugin-opt Analysis.Plugin:dataNodeProcess #-} module DataNode where import Control.Distributed.Process.ManagedProcess dataNodeProcess :: ProcessDefinition Int dataNodeProcess = defaultProcess { apiHandlers = [handleCall $ \i () -> reply () i] } }}} The associated core *without* optimizations (`ghc -O0 DataNode.hs -ddump- ds`) is {{{ dataNodeProcess dataNodeProcess = case defaultProcess of _ { ProcessDefinition _ ds_d4tk ds_d4tl ds_d4tm ds_d4tn ds_d4to -> ProcessDefinition (: ($ (handleCall $dSerializable_a462 $dSerializable_a462) (\ i_a30r ds_d4tf -> case ds_d4tf of _ { () -> reply $dSerializable_a462 () i_a30r })) []) ds_d4tk ds_d4tl ds_d4tm ds_d4tn ds_d4to } }}} The detail isn't important, but since `defaultProcess` is exported by`ManagedProcess`, the analysis knows what to do. On the other hand, if I run `ghc -O2 DataNode.hs -ddump-ds`, this is (part of) the resulting core: {{{ dataNodeProcess dataNodeProcess = ProcessDefinition (build (\ @ a_d4y4 c_d4y5 n_d4y6 -> c_d4y5 ($ (handleCall $dSerializable_a4an $dSerializable_a4an) (\ i_a33Z ds_d4y0 -> case ds_d4y0 of _ { () -> reply $dSerializable_a4an () i_a33Z })) n_d4y6)) [] [] (defaultProcess2 `cast` ...) (defaultProcess1 `cast` ...) Terminate }}} As `defaultProcess1` and `defaultProcess2` are not exported by `ManagedProcess`, the analysis has no idea what do (which can be quite annoying if it's in a place where we want precision). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 18:57:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 18:57:06 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.edac4847438f3a8bad18dc8d86901a51@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | 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 RyanGlScott): * cc: goldfire (added) Comment: I think there are actually two problems here: 1. The fact that this doesn't typecheck. I //think// this is a known limitation of type inference having to do with the fact that you didn't give a **c**omplete, **u**ser-specified **k**ind **s**ignature (CUSK) for `C`. For reference, if you had typed this: {{{#!hs {-# LANGUAGE PolyKinds, GADTs #-} import GHC.TypeLits data C (x :: k) (a :: k2) where C1 :: (KnownNat x) => a -> C x a C2 :: a -> C Int a }}} Then it works. I'll cc goldfire, out preeminent expert on CUSKs, to be sure. 2. The error message is quite awful. The issue is with `a`, not `x`, so I don't know why GHC is complaining about `x`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 19:17:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 19:17:42 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.c5b36828b8bc51a56fc9048fd1ae5f44@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah. For your third problem, I have a suggestion which just might work. `GHC.Exts` exports a handy type family: {{{#!hs type family Any :: k where {} }}} which inhabits any kind `k`. You can use `Any` as a handy workaround to this `isInstance` limitation: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import GHC.Exts char :: Q Bool char = do char_t <- [t| Char |] isInstance ''Eq [char_t] poly_a :: Q Bool poly_a = do poly_a_t <- [t| [Any] |] isInstance ''Eq [poly_a_t] pair :: Q Bool pair = do pair_t <- [t| (Any,Any) |] isInstance ''Eq [pair_t] }}} Then `$(poly_a >>= stringE.show)` and `$(pair >>= stringE.show)` both give `True`. Granted, there are still some obscure corner cases for which this wouldn't work, like if you only had `instance Eq [Int]` but not `instance Eq a => Eq [a]`. But for what you're trying to do, which is checking instances of the form `instance (C a_1, ..., C a_n) => C (T a_1 ... a_n)`, it should work great! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 19:31:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 19:31:03 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.bbac6fe322218f3dab71efae33cc4758@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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: 9729 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * related: => 9729 Comment: ezyang thought that #9729 might be an example of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 19:32:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 19:32:34 -0000 Subject: [GHC] #13102: orphan family instances can leak through the EPS in --make mode In-Reply-To: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> References: <047.9bce29bafae23f1df388503eed7e71e0@haskell.org> Message-ID: <062.c67b4052af49672dcab2021209d824ba@haskell.org> #13102: orphan family instances can leak through the EPS in --make mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton 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: #9729 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * related: 9729 => #9729 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 20:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 20:07:01 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.9fccff1cc1f829aae88fa2c113a12beb@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7398 | Differential Rev(s): Phab:D3169 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Implemented by bc332b3159613190a4dc33a067c1ab31039a8434 {{{ Prohibit RULES changing constructors Previously, RULES like {-# RULES "JustNothing" forall x . Just x = Nothing #-} were allowed. Simon Peyton Jones say this seems to have been a mistake, that such rules have never been supported intentionally, and that he doesn't know if they can break in horrible ways. Furthermore, Ben Gamari and Reid Barton are considering trying to detect the presence of "static data" that the simplifier doesn't need to traverse at all. Such rules do not play well with that. So for now, we ban them altogether. In most cases, it's possible to work around the ban using hand-written wrapper functions. Reviewers: austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3169 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 20:07:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 20:07:12 -0000 Subject: [GHC] #13290: Data constructors should not have RULES In-Reply-To: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> References: <046.3fb573dd4841b7aa6251886084e9bc17@haskell.org> Message-ID: <061.5cc94845100900481157cf18f0ad5fdd@haskell.org> #13290: Data constructors should not have RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7398 | Differential Rev(s): Phab:D3169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 20:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 20:31:38 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.9d40c35c68dda3e1f56ed27a80d47514@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Reid and I had a rather lengthy discussion about this problem. The take- away message is that while there are a variety of things that we could do to avoid moving string literals up to the top-level (and consequently avoid the costs associated with interface file names, as seen in comment:10), it is unfortunately rather tricky to do in a way that doesn't either come at significant implementation cost or risk regressing #12585. Consequently, we came up with a few ideas for instead reducing the cost of the now-larger interface files. Happily, this effort may also have helpful effects beyond string literals. The gist is that we want make interface file deserialisation more lazy. Reid is working on a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 21:47:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 21:47:15 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.42ebfa4b35b65652370f9bffa19110eb@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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): * cc: gkaracha (added) Comment: George, this is your patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 22:54:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 22:54:09 -0000 Subject: [GHC] #13357: Check demand signatures for catchRetry# and catchSTM# In-Reply-To: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> References: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> Message-ID: <060.fd725cb74be4937f7da2ef8393791dea@haskell.org> #13357: Check demand signatures for catchRetry# and catchSTM# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 23:12:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 23:12:53 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.ee0383eaa826d269b03110e54eea7543@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for making interface-file deserialisation cheaper. But I don't feel that we have a well-characterised problem. ''What exactly is the problem we are trying to solve here?'' Is it ONLY that {{{ x :: Addr# x = "foo"# y :: T y = K x }}} is more expensive than {{{ y :: T y = K "foo"# }}} And if it is more expensive, how much more expensive? And does that cost come from simplifying, spitting out an interface file, code generation, reading in an interface file? I don't think there is much to do with strings here. The same will happen for {{{ x = [True, False, True, ..., True] }}} Perhaps we just don't want to expose the unfolding for a top level constructor. That would be a bit less good on optimisation, but perhaps not a lot. We could measure it. I feel as if we are at risk of taking actions without data to guide them. I'd love to have data. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 23:34:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 23:34:16 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.3992880601b24c1cbccca0f452302c2a@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The increase in interface file size is definitely not the only factor. Another known problem is that CSE is not working properly for top-level unboxed string literals. I found that I could make it work by changing the `Lit l` case in `use_subst` below, in CSE: {{{#!hs addBinding :: CSEnv -- Includes InId->OutId cloning -> InId -> OutId -> OutExpr -- Processed binding -> (CSEnv, OutId) -- Final env, final bndr -- Extend the CSE env with a mapping [rhs -> out-id] -- unless we can instead just substitute [in-id -> rhs] addBinding env in_id out_id rhs' | noCSE in_id = (env, out_id) | use_subst = (extendCSSubst env in_id rhs', out_id) | otherwise = (extendCSEnv env rhs' id_expr', zapped_id) where id_expr' = varToCoreExpr out_id zapped_id = zapIdUsageInfo out_id -- Putting the Id into the cs_map makes it possible that -- it'll become shared more than it is now, which would -- invalidate (the usage part of) its demand info. -- This caused Trac #100218. -- Easiest thing is to zap the usage info; subsequently -- performing late demand-analysis will restore it. Don't zap -- the strictness info; it's not necessary to do so, and losing -- it is bad for performance if you don't do late demand -- analysis -- Should we use SUBSTITUTE or EXTEND? -- See Note [CSE for bindings] use_subst = case rhs' of Var {} -> True Lit l -> litIsTrivial l _ -> False }}} `litIsTrivial` is false for an unboxed string literal (and for an `Integer` literal, and True for other literals). However I don't really understand what is going on here. Is making `use_subst` return True for unboxed string literals the right fix? I also don't think fixing this is going to make a large change to total build time, since gridaphobe says that Phab:D1259 also fixes CSE for top- level string literals, yet it improved overall build time by less than 1% on my test system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 23:59:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 23:59:11 -0000 Subject: [GHC] #13347: Abstract classes in hs-boot should not be treated as injective In-Reply-To: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> References: <045.688c73e62ce88348267ad5b3e6bfa94c@haskell.org> Message-ID: <060.4bb98be8b9f383944b51f6db6e2c32aa@haskell.org> #13347: Abstract classes in hs-boot should not be treated as injective -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3236 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"fb5cd9d6d6185afe6d4ef2f3df3f895b6d0abf4c/ghc" fb5cd9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb5cd9d6d6185afe6d4ef2f3df3f895b6d0abf4c" Properly represent abstract classes in Class and IfaceDecl Summary: Previously, abstract classes looked very much like normal classes, except that they happened to have no methods, superclasses or ATs, and they came from boot files. This patch gives abstract classes a proper representation in Class and IfaceDecl, by moving the things which are never defined for abstract classes into ClassBody/IfaceClassBody. Because Class is abstract, this change had ~no disruption to any of the code in GHC; if you ask about the methods of an abstract class, we'll just give you an empty list. This also fixes a bug where abstract type classes were incorrectly treated as representationally injective (they're not!) Fixes #13347, and a TODO in the code. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, austin Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D3236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 2 23:59:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Mar 2017 23:59:11 -0000 Subject: [GHC] #13068: GHC should not allow modules to define instances of abstract type classes In-Reply-To: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> References: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> Message-ID: <060.7c364ad10d6fca05bd6a0568f38129dd@haskell.org> #13068: GHC should not allow modules to define instances of abstract type classes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3254 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"bba004f2a0642d3bb8c8876543aaa1a48a2f9a43/ghc" bba004f2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bba004f2a0642d3bb8c8876543aaa1a48a2f9a43" Prevent users from defining instances for abstract classes. Summary: Fixes #13068. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 00:58:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 00:58:19 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.6eeee80343d583493b88767767540c82@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: rwbarton Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3243 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fce3d37c367346c67467ce3d56bc015fa9ed6062/ghc" fce3d37/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fce3d37c367346c67467ce3d56bc015fa9ed6062" Don't allow orphan COMPLETE pragmas (#13349) We might support them properly in the future, but for now it's simpler to disallow them. Test Plan: validate Reviewers: mpickering, austin, bgamari, simonpj Reviewed By: mpickering, simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3243 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 00:58:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 00:58:19 -0000 Subject: [GHC] #12429: Pattern synonym parse error should recommend enabling extension In-Reply-To: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> References: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> Message-ID: <064.c9cd2d0c0cdc53087f2b2750222f2394@haskell.org> #12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: ruperthorlick Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T12429 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3261 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4b1f0721ce164d079848d1f8890630dbbf4cbf7a/ghc" 4b1f0721/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b1f0721ce164d079848d1f8890630dbbf4cbf7a" Add suggestion for PatternSynonyms parse error (fixes #12429) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3261 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 00:58:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 00:58:19 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.7cf207cf9ff13f3cd09f55efb27b6062@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ruperthorlick Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T12811 Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): Phab:D3262 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"488a9daa8246e0dd364dc44b8b6b8650fa6f3822/ghc" 488a9daa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="488a9daa8246e0dd364dc44b8b6b8650fa6f3822" Changed parser message for RankNTypes (#12811) Added a check for whether RankNTypes is enabled and changed error message accordingly Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3262 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 01:11:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 01:11:00 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.873260e1fa4ddc8476389e94d9f0a7bf@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: ruperthorlick Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | parser/should_fail/T12811 Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): Phab:D3262 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks Rupert! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 01:11:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 01:11:16 -0000 Subject: [GHC] #12429: Pattern synonym parse error should recommend enabling extension In-Reply-To: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> References: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> Message-ID: <064.cf69c8788ddc67d4c44dc65316b4b99f@haskell.org> #12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: ruperthorlick Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T12429 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3261 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 01:27:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 01:27:28 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file Message-ID: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently if you pass a C source file on the GHC command line you can control whether the compiler treats it as C or C++ via the it's extension: GCC will treat a file ending in `.c` as C, whereas `.cpp` is treated as C++. However, we currently have no means of controlling what language a stub added with in Template Haskell with `addCStub` will be treated as. Consequently it is currently impossible to compile a C++ source file with `addCStub` without using `-optc`. Moreover, you can't have mixed C/C++ stubs at all. It really seems like this interface should be amended to fix this before we release it in 8.2. Perhaps `addCStub` should accept both the source and a set of compiler flags which will be added to the usual flags (allowing one to pass `-x c++` to the compiler when compiling C++ files)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 02:07:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 02:07:35 -0000 Subject: [GHC] Trac email verification for user: dmm Message-ID: <20170303020735.78C6C3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: dmm Verification Token: Z0ffZZV7 -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 02:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 02:13:24 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later In-Reply-To: <043.b25e91253b49ad08042d636adf423d59@haskell.org> References: <043.b25e91253b49ad08042d636adf423d59@haskell.org> Message-ID: <058.6a43903fe32a9f882bf852e7de89b4c4@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmm): I had no issue building stack and purescript with ghc 8.0.1 on FreeBSD 11 after adding #define MAP_NORESERVE 0 to rts/posix/OSMem.c Building 8.0.2 now with same define. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 08:34:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 08:34:25 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.99df1d4b032174265034a5005c424313@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:1 simonpj]: > George, this is your patch. Hello, I think this is Matthew's patch. If I remember mpickering's implementation correctly, both {`F`, `TooGoodToBeTrue`} and {`F`,`T`} are complete (especially in the module where everything is visible). So all the following combinations are exhaustive: {{{ F, TooGoodToBeTrue -- Using COMPLETE F, _ -- Using the Boolean signature F, _ -- Using COMPLETE }}} Hence, I think this is just non-specified semantics, but not necessarily a bug. Maybe Matthew can shed some more light on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 08:39:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 08:39:45 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.b3c45b4c187dda3e6a22edfa6c05d58e@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * keywords: PatternSynonyms => PatternSynonyms, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 08:54:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 08:54:42 -0000 Subject: [GHC] #13367: CSE not working for top-level literal strings Message-ID: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> #13367: CSE not working for top-level literal strings -------------------------------------+------------------------------------- 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 {{{ {-# LANGUAGE MagicHash #-} module S( z ) where import GHC.Exts data T = MkT Addr# x = MkT "foo"# y = MkT "foo"# z = (x,y) }}} You'd expect those literal strings to get CSE'd but currently they are not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 08:58:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 08:58:46 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.edae569d6d05ad55bd18486a3d961f51@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK so you are pointing out a bug in CSE. Very good! Let's make a ticket (#13367) and fix the bug. I have done that; fix validating now. (The same fix is in gridaphobe's patch, but it's orthogonal, so best done separately.) Back to comment:16. Let's assume that this string-CSE thing makes no difference. Then all my questions in comment:16 remain. I just want to be sure that we are fixing the right problem! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 09:32:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 09:32:52 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. In-Reply-To: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> References: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> Message-ID: <062.1c5d6a47c64113616b5dcdfe8b1cda05@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: ruperthorlick Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3968 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * owner: (none) => ruperthorlick * version: 7.6.3 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 10:08:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 10:08:40 -0000 Subject: [GHC] #13368: Derive superclasses automatically if possible Message-ID: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> #13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- 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: #10607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I don't forget, this is like #10607 along another axis. Instead of writing {{{#!hs newtype IO_ a = IO_ (IO a) deriving newtype (Functor, Applicative, Monad, MonadIO) }}} allow writing {{{#!hs newtype IO_ a = IO_ (IO a) deriving newtype MonadIO }}} with the same meaning, are there any technical restrictions to this? This gets annoying in large hierarchies where you need `Eq`, `Ord`, `Num`, `Fractional`, `Floating`, `Real` and `RealFrac` just to derive {{{#!hs newtype F32 = F32 Float deriving newtype RealFloat }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 10:15:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 10:15:37 -0000 Subject: [GHC] #13341: Lift constraint products In-Reply-To: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> References: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> Message-ID: <066.ca9f897eddb9d8b1aa5b38df98811357@haskell.org> #13341: Lift constraint products -------------------------------------+------------------------------------- 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 empty constraint tuple `()` becomes the unit of `:&:` {{{#!hs class Empty a instance Empty a }}} `:&:` and `Empty` would presumably be added to *base*. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 10:37:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 10:37:03 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.99128aa0d5d3224d5de7951bcdb0fac8@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is a bug because the match is not "redundant" as removing it will change the semantics of the function. Similarly if you write {{{ f T = 1 f F = 0 f _ = 3 }}} then removing the F case leaves a complete definition but the correct thing to do is to remove the redundant wildcard clause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 10:50:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 10:50:15 -0000 Subject: [GHC] #13369: Float-out is not idempotent Message-ID: <046.634bbbfff77b021b9c4e1a0c9964fad2@haskell.org> #13369: Float-out is not idempotent -------------------------------------+------------------------------------- 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 {{{ f x = BIG }}} where BIG is bottoming. In HEAD, the float-out pass decides to float BIG to the top level, producing {{{ lvl x = BIG f x = lvl x }}} which is obviously stupid. There's a whole Note to explain this problem and how we avoid it: {{{ Note [Floating from a RHS] ~~~~~~~~~~~~~~~~~~~~~~~~~~ When float the RHS of a let-binding, we don't always want to apply lvlMFE to the body of a lambda, as we usually do, because the entire binding body is already going to the right place (dest_lvl). A particular example is the top level. Consider concat = /\ a -> foldr ..a.. (++) [] We don't want to float the body of the lambda to get lvl = /\ a -> foldr ..a.. (++) [] concat = /\ a -> lvl a That would be stupid. }}} But I forgot to take account of the possibility that `abs_vars` might abstract over Ids. Easily fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 11:48:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 11:48:07 -0000 Subject: [GHC] #13370: exprIsBottom inconsistend with strictness analyser Message-ID: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> #13370: exprIsBottom inconsistend with strictness analyser -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Because of `Note [IO hack in the demand analyser]` (which I hate), an expression like {{{ f :: Int -> State# RealWorld -> (# State# RealWorld, Int #) f x s = case blah of (# s::State# RealWorld, r::() #) -> error (show x) }}} is not reported as a bottoming function by the strictness analyser. But `exprBotStrictness_maybe` will say that the RHS ''is'' bottoming. That ultimately comes from `CoreArity.arityType` which has no analogous hack to the demand analyser. These can't both be right! We could * Cripple `exprBotStrictness_maybe` a bit by adding the hack there too. * Weaken the hack so that it propagates divergence. The demand-analyser hack note says {{{ {- Note [IO hack in the demand analyser] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There's a hack here for I/O operations. Consider case foo x s of { (# s, r #) -> y } Is this strict in 'y'? Normally yes, but what if 'foo' is an I/O operation that simply terminates the program (not in an erroneous way)? In that case we should not evaluate 'y' before the call to 'foo'. Hackish solution: spot the IO-like situation and add a virtual branch, as if we had case foo x s of (# s, r #) -> y other -> return () So the 'y' isn't necessarily going to be evaluated A more complete example (Trac #148, #1592) where this shows up is: do { let len = ; ; when (...) (exitWith ExitSuccess) ; print len } }}} I wonder if we could weaken the hack so that it propagated divergence /exception-thowing, while still making mentioned variables lazy. The big reason I'd like to do this is if we have {{{ case f x s of (# s',r #) -> BIG }}} then I really want to discard the alternative (since `f x s` is guaranteed to throw an exception) to give {{{ case f x s of {} }}} This is absolutely kosher; no change in evaluation order or anything. But weakening the IO hack in this way can change strictness. For example {{{ g A x y z s = x `seq` y `seq` (# s, () #) g B x y z s = x `seq` case blah2 of (# s', _ #) -> y `seq` (# s', () #) g C x y z s = case blah of (# s', _ #) -> error (show z) }}} Currently we treat this as lazy in x,y and z. With the above change, it'd become strict in `x` but not `y` or `z`, which is a little weird. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 11:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 11:59:12 -0000 Subject: [GHC] #13370: exprIsBottom inconsistend with strictness analyser In-Reply-To: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> References: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> Message-ID: <061.de91206436d035c27106c69a412bc4ec@haskell.org> #13370: exprIsBottom inconsistend with strictness analyser -------------------------------------+------------------------------------- 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): PS: the inconsistency actually appears as lint warnings {{{ No alternatives for a case scrutinee not known to diverge for sure: tcGetDefaultTys6 }}} This happens because `FloatOut` hoist an expression like the RHS of `f` above to top level; and then uses `exprBotStrictness_maybe` to give it a cheap-and-cheerful strictness signature, one that says it diverges. That sig enables GHC to discard case alternatives. But then the final demand- analysis phase, just before CoreTidy, returns a more conservative verdict, after which the lint warnings appear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 13:07:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 13:07:49 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.0cbe399ff1e109a96a8f7b43d2df8ec5@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Yes, I guess you're right. This seems like the discussion we had on Phab:D2669, but I thought you actually disabled the redundancy check when `COMPLETE` pragmas are involved so that these discrepancies don't show up, with the commit: - Don't warn about redundancy when COMPLETE is involved -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 13:25:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 13:25:44 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.5ae7798b6e42c768ec1faaa3ef9fe00e@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Consequently, we came up with a few ideas for instead reducing the cost of the now-larger interface files. Happily, this effort may also have helpful effects beyond string literals. The gist is that we want make interface file deserialisation more lazy. Reid is working on a patch. This patch is Phab:D3269. > Back to comment:16. Let's assume that this string-CSE thing makes no difference. Then all my questions in comment:16 remain. I just want to be sure that we are fixing the right problem! I think it will make some substantial difference, but I suspect there is still something else going on. When your CSE fix is ready (I assume it is a simple change), I will try comparing * the commit before the top-level string patch, with * the top-level string patch plus your fix to CSE by doing a `validate --build-only` with detailed tracking of where time is being spent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 13:50:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 13:50:51 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.bf23d63eaeb4e3105de58c7a6f5768c0@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): In the current implementation all stubs go into the same file as the C stubs. This means that multiple calls of `addCStub` have visibility of the the definitions that have been inserted earlier (actually I'm not sure of the order but this could be arranged). We could send each stub to a different file certainly. And ask for forward declarations. > Moreover, you can't have mixed C/C++ stubs at all. Not even doing {{{ addCStub "extern \"C\" { ... }" }}} ? BTW, what's wrong with using `-optc`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 14:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 14:24:04 -0000 Subject: [GHC] #13368: Derive superclasses automatically if possible In-Reply-To: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> References: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> Message-ID: <066.a412118bce632d7939c5e0542c05b979@haskell.org> #13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- 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: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This proposal shares many similarities with the [https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses IntrinsicSuperclasses] and [https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates InstanceTemplates] proposals, so I'll link them here. However, this proposal shares many of their downsides, which I'll briefly expound upon here. First, there's the technical challenges to this proposal. Not all instances are made equal, and `deriving` exposes this in many ways. For instance, suppose you tried this under your proposal: {{{#!hs class Traversable f => Witherable f where ... newtype Wrapped f a = Wrap (f a) deriving newtype Witherable }}} This would attempt the following: * `deriving newtype instance Functor f => Functor (Wrapped f)` * `deriving newtype instance Foldable f => Foldable (Wrapped f)` * `deriving newtype instance Traversable f => Traversable (Wrapped f)` * `deriving newtype instance Witherable f => Witherable (Wrapped f)` But trying to derive `Traversable` that way will fail, as it is ill-roled! See #13153. So not only would this throw an error, but it would throw an error that talks about a completely different class than `Witherable`. Mysterious. What's more, there's quite a number of ambiguities you'd have to deal with. For instance, what happens under your proposal in this scenario? {{{#!hs class Show a => MyShow a where ... data Foo deriving newtype MyShow instance Show Foo }}} Since `Show` is a superclass of `MyShow`, you might expect the `deriving newtype MyShow` clause to derive `instance Show Foo` as well. But there's already an `instance Show Foo`! So we'd either have to error here, or come up with a scheme for defaulting to existing instances when scenarios like the above one crop up. You might respond: "But that's easy! Just use the existing `Show Foo` instance!" But it gets even hairier than that: {{{#!hs class Show a => MyShow1 a where ... class Show a => MyShow2 a where ... data Foo deriving newtype MyShow1 deriving anyclass MyShow2 }}} Now we must ask: which of the two deriving clauses will implicitly derive `Show` behind the scenes? The choice matters, because a `newtype`-derived `Show` instance will be completely different than an `anyclass`-derived one! If the answer to this question is "use the first deriving clause", then now the order in which you write `deriving` clauses matters, which is a property that Haskell has never had up to this point. Finally, there's one more objection I will make not on technical grounds, but on aesthetic ones. This proposal would lose the property that all instances are explicitly asked for by the user. I (personally) find the idea of instances being snuck in behind the scenes quite shady and hard to reason about, and in addition, we'd lose things like concrete source locations for every instance, the ability to annotate all instances with Haddocks, etc. So my opinion in that it's a huge amount of complexity for very little gain and many drawbacks. I like the idea of doing something like this in Template Haskell, so I'm glad that someone is pursuing this in #10607. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 14:25:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 14:25:13 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.279e928a08305c739acb7e3bf5cc5391@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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): Phab:D3257 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0d2f733050ff656b827351108d988e09abc363fc/ghc" 0d2f7330/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d2f733050ff656b827351108d988e09abc363fc" Read COMPLETE sets from external packages Currently, `COMPLETE` pragmas are not read from external packages at all, which quite limits their usefulness. This extends `ExternalPackageState` to include `COMPLETE` sets from other packages, and plumbs around the appropriate values to make it work the way you'd expect it to. Fixes #13350. Test Plan: make test TEST=T13350 Reviewers: rwbarton, mpickering, austin, simonpj, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3257 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 14:25:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 14:25:29 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.cf205791063b41a2a955e51ac10d9a4e@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): But that is not the problem. This warning comes from the built-in constructor set. I think there needs to be some more clever augmentation to the intermediate result in the case that a result of `allCompleteMatches` does not contain the constructor which was used to do the lookup. For example, if `ToGoodToBeTrue` is not in `T, F`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 14:36:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 14:36:18 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.4ab5bcd3828018773861e3bb1c52c441@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Perhaps a dumb question: What's wrong with using -optc? It very well may break other stubs, who expect to be compiled with a C compiler (and therefore will break with C++ name mangling). These users include GHC itself, which uses C stubs for static pointers and profiler initialization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 15:10:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 15:10:36 -0000 Subject: [GHC] #13370: exprIsBottom inconsistent with strictness analyser (was: exprIsBottom inconsistend with strictness analyser) In-Reply-To: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> References: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> Message-ID: <061.5014b53e8437c95bec3522d9116382a3@haskell.org> #13370: exprIsBottom inconsistent with strictness analyser -------------------------------------+------------------------------------- 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 Fri Mar 3 16:08:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 16:08:04 -0000 Subject: [GHC] #13371: instance selection too eager Message-ID: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I see a regression in 8.0.2: the `g_f'` definition is rejected. The error goes away if I do one of: * -XNoMonoLocalBinds * -XNoPolyKinds * pasting the inferred type of `g_f` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 16:09:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 16:09:28 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.6d74df1a3936de8ffeacd1e96346b7b4@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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 aavogt): * Attachment "too_eager.hs" added. minimal test case coming from Data.HList.Dredge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 16:20:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 16:20:05 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.e9c5e5a5bd3c5f585f26a6e687272d2b@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): No error in 8.0.1, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 17:50:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 17:50:01 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.5c66c25814d38c37802e51d61f621896@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > When your CSE fix is ready (I assume it is a simple change) It is, but I got snarled up in something else. Monday I hope -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 18:20:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 18:20:26 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.23477d5fd383c13212224abf49190004@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | 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 goldfire): Ryan nailed it. This is a CUSK issue. When you have a [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #complete-user-supplied-kind-signatures-and-polymorphic-recursion CUSK], inference runs quite differently from when you don't. The error message is actually correct, given that we're doing non-CUSK inference here. What would be better is an `NB: Adding a complete user-specified kind signature might help`. Not clear how easy or hard it would be to know when to add the `NB`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 18:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 18:41:27 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.ec9c3d3e45442e4373d740b0458b7d3a@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2734 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Thanks to philderbeast for taking care of this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 18:51:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 18:51:31 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. In-Reply-To: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> References: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> Message-ID: <062.6a1107cba7a3a05d7ea33836093d5d2a@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: ruperthorlick Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T8501a Blocked By: | Blocking: Related Tickets: #3968 | Differential Rev(s): Phab:D3271 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * status: new => patch * testcase: => parser/should_fail/T8501a * differential: => Phab:D3271 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 20:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 20:59:12 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.74d8e064a1ca90c74f0884bdef9d1585@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: niteria (added) Comment: I tried to figure out where in the 8.0.2 branch this regression was introduced. Unfortunately, I wasn't able to isolate an exact commit, because the range of commits in which it was introduced doesn't build. However, I know for sure it was introduced between: * cc02156b859159eff7d86043f67826c17f2bd170 (where the bug is not present): {{{ From cc02156b859159eff7d86043f67826c17f2bd170 Mon Sep 17 00:00:00 2001 From: Bartosz Nitka Date: Mon, 18 Apr 2016 07:32:03 -0700 Subject: [PATCH] Make benign non-determinism in pretty-printing more obvious This change takes us one step closer to being able to remove `varSetElemsWellScoped`. The end goal is to make every source of non-determinism obvious at the source level, so that when we achieve determinism it doesn't get broken accidentally. Test Plan: compile GHC Reviewers: simonmar, goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2123 GHC Trac Issues: #4012 (cherry picked from commit 0f96686b10fd36d479a54c71a6e1753193e85347) }}} * ae94a31e7f162b4a3ef6b6f837bd6006a98f639a (where the bug is present): {{{ From ae94a31e7f162b4a3ef6b6f837bd6006a98f639a Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Fri, 22 Apr 2016 10:47:14 +0100 Subject: [PATCH] Refactor free tyvars on LHS of rules A RULE can have unbound meta-tyvars on the LHS. Consider data T a = C foo :: T a -> Int foo C = 1 {-# RULES "myrule" foo C = 1 #-} After type checking the LHS becomes (foo alpha (C alpah)) and we do not want to zap the unbound meta-tyvar 'alpha' to Any, because that limits the applicability of the rule. Instead, we want to quantify over it! Previously there was a rather clunky implementation of this quantification, buried in the zonker in TcHsSyn (zonkTvCollecting). This patch refactors it so that the zonker just turns the meta-tyvar into a skolem, and the desugarer adds the quantification. See DsBinds Note [Free tyvars on rule LHS]. As it happened, the desugarer was already doing something similar for dictionaries. See DsBinds Note [Free dictionaries on rule LHS] No change in functionality, but less cruft. (cherry picked from commit 6ad2b42f866fa718855cc5c850e3549bc1428b3c) }}} I doubt that ae94a31e7f162b4a3ef6b6f837bd6006a98f639a was responsible, since it seems to only touch rewrite RULES. Furthermore, niteria authored all commits between cc02156b859159eff7d86043f67826c17f2bd170 and that point. Do you have a hunch what might be happening here, niteria? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 21:35:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 21:35:54 -0000 Subject: [GHC] #13340: Core top-level bindings no longer deduplicated In-Reply-To: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> References: <047.de68d3f334cb0ebd464ac3815b8268c8@haskell.org> Message-ID: <062.c4c758aaee2563631902ae2e164d2dd5@haskell.org> #13340: Core top-level bindings no longer deduplicated -------------------------------------+------------------------------------- Reporter: rwbarton | 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5ed56fc8163690c209f594dbfe9dd49b7053739b/ghc" 5ed56fc8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5ed56fc8163690c209f594dbfe9dd49b7053739b" Comments only, in CSE (#13340) Reviewers: simonpj, austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3268 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 3 23:29:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Mar 2017 23:29:02 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.38aabd8ff49f85032028984d8302d703@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: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 00:36:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 00:36:39 -0000 Subject: [GHC] #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base Message-ID: <045.e8d5052962549532effd4485f8aa5560@haskell.org> #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.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: -------------------------------------+------------------------------------- In #12096 it is requested that we add CallStack to SomeException. This is a more conservative request for adding CallStack to IOError only. IOError is already an abstract data type, so it is a simple matter to augment it with space for a CallStack. The main design flex point is whether or not a `CallStack` should be associated with an IOError when it is constructed, or when it is thrown. There are pros and cons to both: 1. If it is associated at construction time, the call stack will reflect when the IOError was constructed, not when it was thrown. This could be arbitrarily far away from the actual throw site. I've been mostly using CallStack for monadic code, and so my primary concern is with where in the monadic code the exception was thrown, so this info isn't really what I want. 2. If it is associated at throw time, there are a few other problems. First, if someone uses throwIO rather than ioError, we won't actually associate a CallStack with the value. Second, if a user is rethrowing an exception, they may accidentally overwrite the old stack trace; but it was the original one that I wanted. For now, I suggest going with (1). Here is the proposal: * Add `ioeGetCallStack` and `ioeSetCallStack`, for setting and getting the `CallStack` recorded in `IOError` * `userError` and `mkIOError` gain a `HasCallStack` constraint. We have a choice for `annotateIOError`, but my suggestion is to NOT annotate it. * Let's annotate all functions that (transitively) may raise an IOError in base with `HasCallStack`. The primary benefit is now if I have a "file not found" exception or similar, I automatically get a stack trace saying exactly what code was run where the file was not found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 00:58:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 00:58:47 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.62dffce52ecf62c69364b369f93c152e@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, compiling these commits from the HEAD branch (instead of the 8.0.2 branch) turned out to be more fruitful. I discovered that the commit which introduced this regression is c9bcaf3165586ac214fa694e61c55eb45eb131ab: {{{ From c9bcaf3165586ac214fa694e61c55eb45eb131ab Mon Sep 17 00:00:00 2001 From: Bartosz Nitka Date: Tue, 26 Apr 2016 05:58:24 -0700 Subject: [PATCH] Kill varSetElemsWellScoped in quantifyTyVars varSetElemsWellScoped introduces unnecessary non-determinism in inferred type signatures. Removing this instance required changing the representation of TcDepVars to use deterministic sets. This is the last occurence of varSetElemsWellScoped, allowing me to finally remove it. Test Plan: ./validate I will update the expected outputs when commiting, some reordering of type variables in types is expected. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 01:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 01:02:43 -0000 Subject: [GHC] #8263: allow duplicate deriving / standalone deriving In-Reply-To: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> References: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> Message-ID: <060.6e9cb511860ad8c853b8e01b4f1546c9@haskell.org> #8263: allow duplicate deriving / standalone deriving -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm also inclined to reject this idea. Given the current richness of `deriving` language, it's possible to derive two instances which are //almost// the same but with subtle differences, e.g., {{{#!hs deriving stock instance Show Bool deriving newtype instance Show Bool }}} I imagine trying to detect duplicate instances would be a large headache. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 01:09:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 01:09:40 -0000 Subject: [GHC] #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure In-Reply-To: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> References: <045.0ee5e1db2880b1dc802e1b70063a8639@haskell.org> Message-ID: <060.86c1e7a0eb382b903345630c835ac354@haskell.org> #11421: adding a PartialTypeSignatures to a binding affected by MonoLocalBinds leads compile-time failure -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10438 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #10438 Comment: Closing as a duplicate of #10438. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 02:39:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 02:39:54 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.27c9a6ebe34c9cec7bafb6954522558c@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:16 simonpj]: > Is it ONLY that > {{{ > x :: Addr# > x = "foo"# > y :: T > y = K x > }}} > is more expensive than > {{{ > y :: T > y = K "foo"# > }}} > And if it is more expensive, how much more expensive? And does that cost come from simplifying, spitting out an interface file, code generation, reading in an interface file? I think I've found the main source of extra cost from this transformation. When we build a module with `-split-objs`, the code generator emits one assembly file per strongly-connected component of Cmm declarations, and then the driver runs the assembler on each of these files. In the example above, the first program will be translated into two `.o` files using two assembler invocations, while the second will be translated into a single `.o` file with a single assembler invocation. Thus each string literal will, with this change, normally result in an extra assembler invocation (assuming it gets floated to top level, and is only referred to from one place). The builds on https://perf.haskell.org/ghc are done using something like the default (perf) flavour build settings, so when it built this commit (https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53feb3) the libraries were built with `-split-objs`. I ran similar builds myself and found that the number of `.o` files (so, assembler invocations, roughly) increased from 100000 to 133000 with the top-level strings patch. The 33000 extra assembler invocations can plausibly explain the extra ~100 seconds of total build time. But rather than hand-waving estimates, there's a better way to confirm what happened. In fact, we actually mean to build the libraries ''not'' with `-split- objs`, but with `-split-sections`, a new flag that achieves a similar effect but which requires running the assembler only once per module. However, the top-level strings patch (Jan 18) landed in the window between * commit 266a9dc (Jan 10), which accidentally broke detection of `-split- sections` support (https://perf.haskell.org/ghc/#revision/266a9dc4cd34008f1162eb276032c85ef8371842), and * commit 283acec (Feb 4), which fixed `-split-sections` (https://perf.haskell.org/ghc/#revision/283acec1d7307fdbd8cd7b3f1d984a036366d6b4) The first of these two commits increased build time from 1891s to 2150s, a change of +259s, and the second decreased it from 2653s to 2311s, a change of -342s. Let's assume that the increase between these commits (from 2150s to 2653s) is caused mainly by ghc getting slower (e.g., join points core lint), not by ghc getting larger (more modules to compile). The changes of +259s and -342s from these `-split-sections` patches are presumably due mainly to saving 100000 and 133000 assembler invocations respectively; and 342/259 = 1.32 is in remarkably close agreement with these numbers. That suggests that 342-259 = 83 of the 102 seconds by which top-level unboxed strings increased the build time should be attributed to additional invocations of the assembler. The good news is that we do not have to do anything about those 83 seconds, as we do not use `-split-objs` during the GHC build any more. Effectively they were measurement error, due to the build being misconfigured when the top-level strings patch landed. This leaves an increase of 102-83 = 19 seconds (out of a total ~2000, so about 1%) from the top-level strings patch, which can plausibly be explained by (1) larger interface files and (2) lack of CSE for top-level strings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 03:27:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 03:27:48 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.2a7a941e19c3e5aa26d81d7d15e34e38@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Wow, excellent sleuthing! So is the bottom line is that the increase that you believe to '''actually''' be attributable to the top-level strings patch will be fixed by the combined CSE of string literals and lazier interface file patches? (I seem to recall you mentioning a gain of roughly 1% from one or the other, but it's not in this ticket, perhaps IRC..) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 04:02:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 04:02:40 -0000 Subject: [GHC] #13373: Handle long file paths on Windows Message-ID: <045.872d530b642536033e5f70fd0cb14d01@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 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In the past, Cabal and GHC have run into Windows' PATH_MAX path size limitation, which caps the length of file system paths at 260 characters. Examples: * https://github.com/haskell/cabal/issues/3972 * https://ghc.haskell.org/trac/ghc/ticket/10777 It would be really great if Haskell's base libraries handled long file system paths correctly. There are a few possibilities for achieving this: * Call GetShortPathName https://msdn.microsoft.com/en- us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any Windows API function, if we notice the file path is too long. The bad: Windows has to store the alias, and this aliasing mechanism may be disabled (but maybe this never happens in practice). * Rewrite the core libraries to use the Unicode versions of functions, which support longer paths. We need to add the `\\?\` prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so `..` is not interpreted.) Care would need to be taken to not break existing code. * For Windows 10 only, opt into transparent long path support using a manifest. See the bottom of https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath Downside: this only works for Windows 10 An alternative plan is to build and publish an alternative Windows IO library, which is a drop-in replacement for the IO functionality implemented in base but is long paths. We can use this to test paths and provide better functionality to old versions of GHC, before merging the changes back into base proper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 07:12:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 07:12:15 -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.02e5eee4962f76391ce386933949ea1d@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 awson): ''but maybe this never happens in practice'' All my Windows machines have short path names generation disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 07:44:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 07:44:47 -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.fd71d706f42a0803094e7c9641661abc@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: | -------------------------------------+------------------------------------- Old description: > In the past, Cabal and GHC have run into Windows' PATH_MAX path size > limitation, which caps the length of file system paths at 260 characters. > Examples: > > * https://github.com/haskell/cabal/issues/3972 > * https://ghc.haskell.org/trac/ghc/ticket/10777 > > It would be really great if Haskell's base libraries handled long file > system paths correctly. There are a few possibilities for achieving this: > > * Call GetShortPathName https://msdn.microsoft.com/en- > us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any > Windows API function, if we notice the file path is too long. The bad: > Windows has to store the alias, and this aliasing mechanism may be > disabled (but maybe this never happens in practice). > * Rewrite the core libraries to use the Unicode versions of functions, > which support longer paths. We need to add the `\\?\` prefix in this > case. However, this prefix is not supported by all functions, and it > turns off automatic expansion in the path string (so `..` is not > interpreted.) Care would need to be taken to not break existing code. > * For Windows 10 only, opt into transparent long path support using a > manifest. See the bottom of https://msdn.microsoft.com/en- > us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath Downside: this > only works for Windows 10 > > An alternative plan is to build and publish an alternative Windows IO > library, which is a drop-in replacement for the IO functionality > implemented in base but is long paths. We can use this to test paths and > provide better functionality to old versions of GHC, before merging the > changes back into base proper. New description: In the past, Cabal and GHC have run into Windows' PATH_MAX path size limitation, which caps the length of file system paths at 260 characters. Examples: * https://github.com/haskell/cabal/issues/3972 * https://ghc.haskell.org/trac/ghc/ticket/10777 It would be really great if Haskell's base libraries handled long file system paths correctly. There are a few possibilities for achieving this: * Call GetShortPathName https://msdn.microsoft.com/en- us/library/windows/desktop/aa364989(v=vs.85).aspx before calling any Windows API function, if we notice the file path is too long. The bad: Windows has to store the alias, and this aliasing mechanism may be disabled ~~(but maybe this never happens in practice).~~ * Rewrite the core libraries to use the Unicode versions of functions, which support longer paths. We need to add the `\\?\` prefix in this case. However, this prefix is not supported by all functions, and it turns off automatic expansion in the path string (so `..` is not interpreted.) Care would need to be taken to not break existing code. * For Windows 10 only, opt into transparent long path support using a manifest. See the bottom of https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath Downside: this only works for Windows 10 An alternative plan is to build and publish an alternative Windows IO library, which is a drop-in replacement for the IO functionality implemented in base but is long paths. We can use this to test paths and provide better functionality to old versions of GHC, before merging the changes back into base proper. -- Comment (by ezyang): I stand corrected. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 10:34:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 10:34:15 -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.76f972803556bb10f46313e6144c4e56@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: | -------------------------------------+------------------------------------- Comment (by mnislaih): Both choices are viable, I think Java does (1), whereas C# goes with (2) but keeps a list of call stacks to avoid losing the original stack on rethrow. If we later wanted to add a call stack to SomeException, would (2) become the more natural choice ? If so, would it be worth adapting the proposal to add the call stack to SomeException now, but only surface it in IOError ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 13:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 13:04:39 -0000 Subject: [GHC] #12488: Explicit namespaces doesn't enforce namespaces In-Reply-To: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> References: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> Message-ID: <064.40b871c68bedb7ecf39920ee19456be5@haskell.org> #12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ruperthorlick Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * owner: (none) => ruperthorlick -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 15:29:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 15:29:50 -0000 Subject: [GHC] #12488: Explicit namespaces doesn't enforce namespaces In-Reply-To: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> References: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> Message-ID: <064.0821e008dd34e3ceb8adf00363afe87f@haskell.org> #12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ruperthorlick Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ruperthorlick): Replying to [comment:1 mpickering]: > Simon says that we should just reject the use of explicit namespace qualifiers in the subcomponents of the export item in the parser. > This would work and be a fairly easy change, however I stumled across the following in DynFlags.hs: {{{ -- We turn this on so that we can export associated type -- type synonyms in subordinates (e.g. MyClass(type AssocType)) , (LangExt.TypeFamilies, turnOn, LangExt.ExplicitNamespaces) }}} So for the above they might want to export `Foo (type A)` Does this mean we need something more complicated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 16:47:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 16:47:21 -0000 Subject: [GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores In-Reply-To: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> References: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> Message-ID: <060.be88ed328dc1bd2538acbaa4772ffadd@haskell.org> #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores --------------------------------------------+------------------------------ Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by varosi): Isn't it good idea if GHC runtime is doing this once per second or the like? So this way it will automatically work on similar machines? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 17:25:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 17:25:53 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.0254f0626d9d68d555d0882063f0a012@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bitonic): * owner: (none) => bitonic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 20:04:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 20:04:28 -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.1e63626fe2f0c5f9699293afc52648dd@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 ekmett): Using long paths would fix the sort of weird things that arise with `Con.hs` and the like on Windows as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 20:08:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 20:08:34 -0000 Subject: [GHC] #13374: Let exprSize ignore case analysis Message-ID: <046.671de8a2aab9f9a923ec4fb0350342ed@haskell.org> #13374: Let exprSize ignore case analysis -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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 came out of a discussion at #1335, where Simon says: > > So it seems that after splitting the function into two pieces, it is small enough(?) so that both pieces inline? > > Yes that is galling I agree. > > * Part of the trouble is that strictness analysis does a deep semantic analysis, pulls all the evals to the top, inlines them unconditionally, leaving behind a worker that may now be a lot smaller. The sizeExpr code in CoreUnfold is necessarily much simpler. > > * The discount we award for a scrutinised argument is computed in size_up here: > > {{{ > alts_size (SizeIs tot tot_disc tot_scrut) > -- Size of all alternatives > (SizeIs max _ _) > -- Size of biggest alternative > = SizeIs tot (unitBag (v, 20 + tot - max) > `unionBags` tot_disc) tot_scrut > }}} > > For a single-alternative case (and you have a tuple arg here) tot = max, so there's fixed discount of 20. You could make that into a controllable flag and try varying it. > > * Idea. If a function starts with case x of blah (even if wrapped in lets) we know that the strictness analyser will find it strict in x. So we know it'll generate a wrapper, and the wrapper will inline. So in the end it'll be as if that case cost nothing at all. It would not be hard to make sizeExpr simply count zero for the cost of such cases; including nested. (Certainly for single-alternative ones.) > > Worth a try? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 20:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 20:26:05 -0000 Subject: [GHC] #13353: foldr/nil rule not applied consistently In-Reply-To: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> References: <046.1368f7459a333abc39463fbef8e6d99d@haskell.org> Message-ID: <061.10c2f1c79827f8ca3612884b61b6fdd0@haskell.org> #13353: foldr/nil rule not applied consistently -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | 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 nomeata): I moved the `exprSize` idea to #13374. > I have no explanation for that!! Might be a misunderstanding in how I use the GHC API. (It seems that the instance of `map` on the RHS of a rule has no rules in its `IdInfo`, and so it does not fire. I’ll ask on the mailing list about that once I get to it.) > Want to try adding that? [mapFB rule] I’m trying that: Phab:D3275 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 20:38:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 20:38:31 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.79ed85cf78f9bc9e80c5317687795833@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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 niteria): This reproduces on recent HEAD. This appears to be another case of unspoken assumptions about the order. On top of c9bcaf3165586ac214fa694e61c55eb45eb131ab it suffices to make this change: {{{ --- a/compiler/typecheck/TcMType.hs +++ b/compiler/typecheck/TcMType.hs @@ -874,7 +874,7 @@ quantifyZonkedTyVars gbl_tvs (DV{ dv_kvs = dep_tkvs, dv_tvs = nondep_tkvs }) -- closeOverKinds all_cvs: do not quantify over coercion -- variables, or any any tvs that a covar depends on - nondep_tvs = dVarSetElems $ + nondep_tvs = varSetElems . dVarSetToVarSet $ nondep_tkvs `dVarSetMinusVarSet` gbl_tvs -- No worry about dependent covars here; they are -- all in dep_tkvs }}} to make the problem go away. It also fixes the problem on HEAD, except you have to use `nonDetEltsUFM` instead of `varSetElems`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 21:15:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 21:15:07 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite Message-ID: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the merge of the package database locking business, `ghc-pkg dump` spews a message on `stderr` on Windows, {{{ $ "C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" dump WARNING: cache is out of date: C:\msys64\home\ben\ghc\inplace\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. name: xhtml version: 3000.2.1 id: xhtml-3000.2.1 ... }}} When the testsuite driver sees this it (namely `testutil.getStdout`) assumes something has gone terribly wrong and aborts. From a cursory look it's not clear how we got into this situation; the file indeed exists and was certainly touched during the build. However, running `ghc-pkg recache` indeed seems to fix the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 21:45:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 21:45:34 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.0f49b077f7aef1309c82152efb1e7d45@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1205, Wiki Page: | Phab:D3019 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2e43848236a4b80015d8fb09a87f6f6a746c1365/ghc" 2e438482/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2e43848236a4b80015d8fb09a87f6f6a746c1365" Fixes a spaceleak in `maximumBy` and `minimumBy` (#10830). This involved changing the implementation from using `foldr11` to using `foldl1`. Test Plan: validate Reviewers: austin, hvr, bgamari, dalaing, dfeuer Reviewed By: bgamari Subscribers: RyanGlScott, dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 22:09:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 22:09:33 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.bd4c2132fbe3e0b273b1dda55279a969@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1205, Wiki Page: | Phab:D3019 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed Comment: I'm going to close this ticket, as the immediate issue of `maximumBy` and `minimumBy` using too much stack space with lists has been fixed with 2e43848236a4b80015d8fb09a87f6f6a746c1365. There's still the other issue of ways to improve the current situation even better that ekmett discusses in comment:26, but I believe that is best left to a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 22:40:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 22:40:52 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.f43d6a21264503f9fe0e3f7b35f4a475@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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 niteria): Broken GHC infers: {{{ g_f :: forall (b :: k0) k c a. F a (Proxy b) => a -> c }}} , while the working one infers {{{ g_f :: forall k (b :: k) c a. F a (Proxy b) => a -> c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 4 23:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Mar 2017 23:16:50 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.ebf90e735b1aa57c98003eb3e44dd85d@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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 niteria): * cc: goldfire (added) Comment: I think this has been broken since 6746549772c5cc0ac66c0fce562f297f4d4b80a2. Running before c9bcaf3165586ac214fa694e61c55eb45eb131ab with `-dunique- increment=-1` reproduces the problem. It appears that when we `growThetaTyVarsDSet` we add some kind variables to the nondependent type var set, but the vars inside depend on the newly added kind var. We then linearize without any regard for dependencies, because there shouldn't be any. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 00:57:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 00:57:13 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.e2251d85c1e3ad55330f10d96da22575@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: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I don't think there is any way to attach a stack trace directly to the `SomeException` data type without breaking code that catches and rethrows exceptions of type `e` (with the constraint `Exception e`). So the not- very-nice conclusion is that we in fact *have* to embed the call stack in every exception type. This doesn't mean that `throw` can't also know how to attach call stacks: for example, the `Exception` type class could be extended with methods for getting and putting the call stack (and the exception instance can even make decisions like whether or not to keep all call stacks around, or just keep the first one, etc). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 01:07:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 01:07:31 -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.1cfeb8c5983c344d32deaa4139822526@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: | -------------------------------------+------------------------------------- Comment (by ezyang): I've mentioned on the other ticket that I don't think adding call stacks to the SomeException type is wise (since you lose the callstacks when you unwrap SomeException and work with `Exception e => e`). So, if the best you can do is add call stack manipulating functions to the Exception type class, (2) can be made to work, since the Exception generic functions can use the methods in the type class to attach a call stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 04:44:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 04:44:37 -0000 Subject: [GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions Message-ID: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- Reporter: jberryman | 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: #8668 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a boiled down version of a library I'm working on. It's possible this is the same issue as #8668 which seems to have stalled. Hopefully this example is simpler and useful in that case. Also likely the same as this https://github.com/jmoy/testing-specialize I have a library which defines the classes `H` and `S`; library consumers are likely to define their own `H` instances, and import `S` instances declared by ''other'' library authors (not me), who will depend on my `H`. Performance depends on all of it getting fully-specialized `hash` (i.e. for each combination of `H` and `S` that the consumer uses). But I don't really want `hash` inlined at every call site. Here is the code to repro with explanation below. I'm compiling like: `ghc --make -Wall -O2 -rtsopts -funbox-strict-fields -ddump-to-file -ddump- simpl -dsuppress-module-prefixes -dsuppress-uniques -ddump-core-stats -ddump-inlinings -ddump-asm -fforce-recomp Main.hs`, and we get the same bad behavior on GHC 7.10.3 and GHC 8.0.1: Lib.hs: {{{#!hs module Lib where class H h where hash :: (S s)=> s -> h -> s class S s where mix :: s -> Int -> s instance H Int where {-# INLINABLE hash #-} hash s = \x -> s `mix` x -- make this look big: `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x }}} S.hs: {{{#!hs module S where import Lib newtype Foo = Foo Int deriving Show instance S Foo where {-# INLINABLE mix #-} mix (Foo x) y = Foo (x+y) }}} And the `Main` I'm using, though you can just call print; it's obvious dumping inlinings when the functions get specialized and unboxed (look for "Inlining done: $fNumInt_$c+"): {{{#!hs module Main where import Lib import S import Criterion.Main main = defaultMain [ bench "foo" $ whnf (hash (Foo 1)) (1::Int) ] }}} If I use the `INLINABLE` pragmas above or omit them entirely we get bad code. If I put an `INLINE` on the `hash` declaration in Lib (and no pragmas in S), we get good unboxed additions and things are fast. Finally and most bizarrely, if I omit the `INLINE` pragma in `hash` (and similarly no pragmas in `S`) but make the body small enough (5 lines of the "`mix` x `mix` x..." junk) then we also get nice unboxed code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 04:47:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 04:47:41 -0000 Subject: [GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions In-Reply-To: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> References: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> Message-ID: <063.4ebcc5938d838d4ca0ff97ecc4e07da7@haskell.org> #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- Reporter: jberryman | 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: #8668 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jberryman: Old description: > This is a boiled down version of a library I'm working on. It's possible > this is the same issue as #8668 which seems to have stalled. Hopefully > this example is simpler and useful in that case. Also likely the same as > this https://github.com/jmoy/testing-specialize > > I have a library which defines the classes `H` and `S`; library consumers > are likely to define their own `H` instances, and import `S` instances > declared by ''other'' library authors (not me), who will depend on my > `H`. > > Performance depends on all of it getting fully-specialized `hash` (i.e. > for each combination of `H` and `S` that the consumer uses). But I don't > really want `hash` inlined at every call site. > > Here is the code to repro with explanation below. I'm compiling like: > `ghc --make -Wall -O2 -rtsopts -funbox-strict-fields -ddump-to-file > -ddump-simpl -dsuppress-module-prefixes -dsuppress-uniques -ddump-core- > stats -ddump-inlinings -ddump-asm -fforce-recomp Main.hs`, and we get the > same bad behavior on GHC 7.10.3 and GHC 8.0.1: > > Lib.hs: > > {{{#!hs > module Lib where > > class H h where > hash :: (S s)=> s -> h -> s > > class S s where > mix :: s -> Int -> s > > instance H Int where > {-# INLINABLE hash #-} > hash s = \x -> > s `mix` x > -- make this look big: > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x > }}} > > S.hs: > > {{{#!hs > module S where > > import Lib > > newtype Foo = Foo Int > deriving Show > > instance S Foo where > {-# INLINABLE mix #-} > mix (Foo x) y = Foo (x+y) > }}} > > And the `Main` I'm using, though you can just call print; it's obvious > dumping inlinings when the functions get specialized and unboxed (look > for "Inlining done: $fNumInt_$c+"): > > {{{#!hs > module Main where > > import Lib > import S > > import Criterion.Main > > main = defaultMain [ > bench "foo" $ whnf (hash (Foo 1)) (1::Int) > ] > }}} > > If I use the `INLINABLE` pragmas above or omit them entirely we get bad > code. > > If I put an `INLINE` on the `hash` declaration in Lib (and no pragmas in > S), we get good unboxed additions and things are fast. > > Finally and most bizarrely, if I omit the `INLINE` pragma in `hash` (and > similarly no pragmas in `S`) but make the body small enough (5 lines of > the "`mix` x `mix` x..." junk) then we also get nice unboxed code. New description: This is a boiled down version of a library I'm working on. It's possible this is the same issue as #8668 which seems to have stalled. Hopefully this example is simpler and useful in that case. Also likely the same as this https://github.com/jmoy/testing-specialize I have a library which defines the classes `H` and `S`; library consumers are likely to define their own `H` instances, and import `S` instances declared by ''other'' library authors (not me), who will depend on my `H`. Performance depends on all of it getting fully-specialized `hash` (i.e. for each combination of `H` and `S` that the consumer uses). But I don't really want `hash` inlined at every call site. Here is the code to repro with explanation below. I'm compiling like: `ghc --make -Wall -O2 -rtsopts -funbox-strict-fields -ddump-to-file -ddump- simpl -dsuppress-module-prefixes -dsuppress-uniques -ddump-core-stats -ddump-inlinings -ddump-asm -fforce-recomp Main.hs`, and we get the same bad behavior on GHC 7.10.3 and GHC 8.0.1: Lib.hs: {{{#!hs module Lib where class H h where hash :: (S s)=> s -> h -> s class S s where mix :: s -> Int -> s instance H Int where {-# INLINABLE hash #-} hash s = \x -> s `mix` x -- make this look big: `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x `mix` x }}} S.hs: {{{#!hs module S where import Lib newtype Foo = Foo Int deriving Show instance S Foo where {-# INLINABLE mix #-} mix (Foo x) y = Foo (x+y) }}} And the `Main` I'm using, though you can just call print; it's obvious dumping inlinings when the functions get specialized and unboxed (look for "Inlining done: $fNumInt_$c+"): {{{#!hs module Main where import Lib import S import Criterion.Main main = defaultMain [ bench "foo" $ whnf (hash (Foo 1)) (1::Int) ] }}} If I use the `INLINABLE` pragmas above or omit them entirely we get bad code. If I put an `INLINE` on the `hash` declaration in Lib (and no pragmas in S), we get good unboxed additions and things are fast. Finally and most bizarrely, if I omit the `INLINE` pragma in `hash` (and similarly no pragmas in `S`) but make the body small enough (5 lines of the "`mix` x `mix` x..." junk) then we also get nice unboxed code. **EDIT**: Also if I move the `S` constraint into the head of `H` then INLINABLE and stuff seem to work as expected: {{{#!hs -- lousy workaround; we can tell users to just not touch the `s` -- parameter in their own instances: class (S s)=> H s h where hash :: s -> h -> s }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 04:58:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 04:58:20 -0000 Subject: [GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions In-Reply-To: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> References: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> Message-ID: <063.ae3120445248ad494b756707d37d559f@haskell.org> #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8668 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jberryman): * keywords: => Inlining * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 05:05:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 05:05:53 -0000 Subject: [GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions In-Reply-To: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> References: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> Message-ID: <063.618923823e76e0b4d37e30a36e9bded4@haskell.org> #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8668 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): Also adding (per "SPECIALIZE for imported functions" from the user guide) in Main the following: {{{#!hs {-# SPECIALIZE hash :: Foo -> Int -> Foo #-} }}} ...results in a warning I don't really understand: {{{ Ignoring useless SPECIALISE pragma for class method selector ‘hash’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 10:15:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 10:15:35 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.6d96aa2ed0224f713fc6641d32727322@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: Operating System: 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): I reached the same conclusion, we have to embed call stacks in every exception type. But I don't think this is incompatible with adding them at the SomeException level. We cannot touch SomeException without breaking all the existing Exception instances, so we introduce a new primitive ancestor SomeExceptionWithCallStack in the hierarchy: {{{ SomeExceptionWithCallStack ^ ^ | | | | SomeException IOError }}} {{{ data SomeExceptionWithCallStack = SomeExceptionWithCallStack Exception [CallStack] data IOError = IOError { ... callStack : [CallStack], ...} class ExceptionWithCallStack e where toExceptionWithCallStack :: e -> SomeExceptionWithCallStack fromExceptionWithCallStack :: SomeExceptionWithCallStack -> Maybe e instance ExceptionWithCallStack SomeException ... instance ExceptionWithCallStack IOError ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 10:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 10:17:19 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.27409b9ff4c9abb242013e773554cfd0@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arybczak): I compiled ghc from scratch and here's how inplace/lib/package.conf.d changes: 10:18 - compilation start 10:25 - rts registered 10:33 - all other core packages registered (I think that's after ghc- stage1 is built) 10:54 - a lock file is created (after ghc-stage2 is built) The thing is that ghc-stage2, when run, reads package db and creates a lock file, which wasn't there yet because all previous modifications of package db were done using ghc-pkg with no locking support. Then, ghc-pkg fails its naive modtime check (i.e. modtime of package.conf.d is higher than package.cache precisely because ghc created lock file when reading the database) and hence the warning. Note that read lock is acquired on Windows only, that's why this doesn't happen on other platforms. I think we can either make the modtime check in ghc-pkg less naive (i.e. compare max(modtime of .conf files) to modtime of package.cache instead of modtime of the directory) or just call recache command. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 10:19:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 10:19:21 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.ae4a730ee2f4240f8812d0385d1716b4@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | 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 arybczak): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 10:31:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 10:31:17 -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.679c5bdfdf94c92606d5a1221a8239f2@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: | -------------------------------------+------------------------------------- Comment (by mnislaih): I think there might be a way to add call stacks at the top level, see my reply in the other ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 11:34:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 11:34:06 -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.777e600c68ab85408338f52817adb922@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 Rufflewind): I have a [https://github.com/haskell/directory/blob/b82ca0194767bf418330bd1ed89ea541716e596a/System/Directory/Internal/Windows.hsc#L313-L325 helper function] which can be used to add `\\?\` to paths and takes care of the subtleties of `..` etc: So far I've managed to [https://github.com/haskell/directory/commit/f77655a2e17c6f7076c7cf9d7de83f5b7f585b63 use this] for most of the direct Win32 API calls. However, `c_stat` (from GHC's `System.Posix.Internals`) is used quite a bit and does not support longer paths AFAIK, so that probably needs to be replaced somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 13:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 13:16:43 -0000 Subject: [GHC] Trac email verification for user: simplifierticks Message-ID: <20170305131643.6B59E3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: simplifierticks Verification Token: PCGVgBOg -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 13:39:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 13:39:18 -0000 Subject: [GHC] #13377: Compiler error: Simplifier ticks exhausted Message-ID: <054.ff8f621057290b15e10c0e04b20aa3a5@haskell.org> #13377: Compiler error: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: | Owner: (none) simplifierticks | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- 2.4 Programming jointly with types and values Exercise 2.4.1 (Fixpoint). The lambda term: y = = \f->(\x->f (x x)) (\x->f (x x)) (that encodes a fixed point combinator in the untyped lambda calculus) does not type check in Haskell. Try it! Interestingly though, recursion on the type level can be used to introduce recursion on the value level. If we define the recursive type: data F a = = F { unF :: F a->a } then we can “annotate” the definition of y with applications of F and unF such that y typechecks. Do it! This works on someones else his computer: {{{#!hs data F a = F { unF :: F a -> a } -- y = \f -> (\x -> f (x x)) (\x -> f (x x)) y = \f -> (\x -> x $ F x) (\x -> f . unF x $ x) }}} Compiler error: ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone x_s1Gq To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6480 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Increased -fsimpl-tick-factor to 100.000 still the error occurred -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 13:46:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 13:46:38 -0000 Subject: [GHC] #13377: Compiler error: Simplifier ticks exhausted In-Reply-To: <054.ff8f621057290b15e10c0e04b20aa3a5@haskell.org> References: <054.ff8f621057290b15e10c0e04b20aa3a5@haskell.org> Message-ID: <069.6b9c92f52e0876520d97c2a4a2f5b9e4@haskell.org> #13377: Compiler error: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: simplifierticks | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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 mpickering): * status: new => closed * resolution: => invalid Comment: This is a known problem which will not be fixed. See this section in the user guide - https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html?highlight=ticks #bugs-in-ghc and also recent discussion in #13125. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 14:08:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 14:08:09 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm Message-ID: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building recent HEAD (e.g. 669333d8) with llvm via quick-llvm fails. The stage2 compiler is broken. Building the compiler with quick-llvm {{{ "inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -fllvm -Wall -hide-all-packages -i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP- DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id filepath-1.4.1.1 -package-id ghc-boot-8.1 -package-id ghc-8.1 -package-id unix-2.7.2.1 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.1 -package-id haskeline-0.7.3.0 -package-id time-1.8 -package-id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O0 -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical- monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -optl-optl-Wl,-arch -optl-optl-Wl,x86_64 -fPIC -dynamic -O0 -H64m -fllvm -Wall -hide-all-packages -i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id filepath-1.4.1.1 -package-id ghc-boot-8.1 -package-id ghc-8.1 -package-id unix-2.7.2.1 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.1 -package-id haskeline-0.7.3.0 -package-id time-1.8 -package-id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O0 -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical- monad-instances -fno-use-rpaths -optl-Wl,-rpath -optl- Wl,'@loader_path/../haskeline-0.7.3.0' -optl-Wl,-rpath -optl- Wl,'@loader_path/../ghc-8.1' -optl-Wl,-rpath -optl- Wl,'@loader_path/../terminfo-0.4.0.2' -optl-Wl,-rpath -optl- Wl,'@loader_path/../hoopl-3.10.2.2' -optl-Wl,-rpath -optl- Wl,'@loader_path/../ghci-8.1' -optl-Wl,-rpath -optl-Wl,'@loader_path /../ghc-boot-8.1' -optl-Wl,-rpath -optl- Wl,'@loader_path/../transformers-0.5.2.0' -optl-Wl,-rpath -optl- Wl,'@loader_path/../hpc-0.6.0.3' -optl-Wl,-rpath -optl-Wl,'@loader_path /../template-haskell-2.12.0.0' -optl-Wl,-rpath -optl- Wl,'@loader_path/../pretty-1.1.3.3' -optl-Wl,-rpath -optl-Wl,'@loader_path /../ghc-boot-th-8.1' -optl-Wl,-rpath -optl- Wl,'@loader_path/../process-1.4.3.0' -optl-Wl,-rpath-optl- Wl,'@loader_path/../directory-1.3.0.2' -optl-Wl,-rpath -optl- Wl,'@loader_path/../unix-2.7.2.1' -optl-Wl,-rpath -optl- Wl,'@loader_path/../filepath-1.4.1.1' -optl-Wl,-rpath -optl- Wl,'@loader_path/../time-1.8' -optl-Wl,-rpath -optl- Wl,'@loader_path/../binary-0.8.4.1' -optl-Wl,-rpath -optl- Wl,'@loader_path/../containers-0.5.10.2' -optl-Wl,-rpath -optl- Wl,'@loader_path/../bytestring-0.10.8.2' -optl-Wl,-rpath -optl- Wl,'@loader_path/../deepseq-1.4.3.0' -optl-Wl,-rpath -optl- Wl,'@loader_path/../array-0.5.1.2' -optl-Wl,-rpath -optl- Wl,'@loader_path/../base-4.10.0.0' -optl-Wl,-rpath -optl-Wl,'@loader_path /../integer-gmp-1.0.0.1' -optl-Wl,-rpath -optl-Wl,'@loader_path/../ghc- prim-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'@loader_path/../rts' ghc/stage2/build/Main.dyn_o ghc/stage2/build/GHCi/UI.dyn_o ghc/stage2/build/GHCi/UI/Info.dyn_o ghc/stage2/build/GHCi/UI/Monad.dyn_o ghc/stage2/build/GHCi/UI/Tags.dyn_o ghc/stage2/build/hschooks.dyn_o Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /usr/bin/install -c -m 755 ghc/stage2/build/tmp/ghc-stage2 inplace/lib/bin /ghc-stage2 "rm" -f inplace/bin /ghc-stage2 echo '#!/bin/sh' >> inplace/bin/ghc-stage2 echo 'executablename="/ghc/inplace/lib/bin/ghc-stage2"' >> inplace/bin/ghc-stage2 echo 'datadir="/ghc/inplace/lib"' >> inplace/bin/ghc-stage2 echo 'bindir="/ghc/inplace/bin"' >> inplace/bin/ghc-stage2 echo 'topdir="/ghc/inplace/lib"' >> inplace/bin /ghc-stage2 echo 'pgmgcc="gcc"' >> inplace/bin/ghc-stage2 echo 'export DYLD_LIBRARY_PATH="/ghc/libraries/haskeline/dist- install/build:/ghc/compiler/stage2/build:/ghc/libraries/terminfo/dist- install/build:/ghc/libraries/hoopl/dist-install/build:/ghc/libraries/ghci /dist-install/build:/ghc/libraries/ghc-boot/dist- install/build:/ghc/libraries/transformers/dist- install/build:/ghc/libraries/hpc/dist-install/build:/ghc/libraries /template-haskell/dist-install/build:/ghc/libraries/pretty/dist- install/build:/ghc/libraries/ghc-boot-th/dist- install/build:/ghc/libraries/process/dist- install/build:/ghc/libraries/directory/dist- install/build:/ghc/libraries/unix/dist- install/build:/ghc/libraries/filepath/dist- install/build:/ghc/libraries/time/dist-install/build:/ghc/libraries/binary /dist-install/build:/ghc/libraries/containers/dist- install/build:/ghc/libraries/bytestring/dist- install/build:/ghc/libraries/deepseq/dist- install/build:/ghc/libraries/array/dist-install/build:/ghc/libraries/base /dist-install/build:/ghc/libraries/integer-gmp/dist- install/build:/ghc/libraries/ghc-prim/dist- install/build:/ghc/rts/dist/build${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}"' >> inplace/bin/ghc-stage2 cat ghc/ghc.wrapper >> inplace/bin /ghc-stage2 chmod +x inplace/bin /ghc-stage2 "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -fllvm -Wall -hide-all-packages -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -Iutils/ghctags/dist- install/build -iutils/ghctags/dist-install/build/ghctags/autogen -Iutils/ghctags/dist-install/build/ghctags/autogen -optP-include -optPutils/ghctags/dist-install/build/ghctags/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id containers-0.5.10.2 -package-id Cabal-2.0.0.0 -package-id ghc-8.1 -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir utils/ghctags/dist- install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -fllvm -Wall -hide-all-packages -i -iutils/check- api-annotations/. -iutils/check-api-annotations/dist-install/build -Iutils /check-api-annotations/dist-install/build -iutils/check-api-annotations /dist-install/build/check-api-annotations/autogen -Iutils/check-api- annotations/dist-install/build/check-api-annotations/autogen -optP- include -optPutils/check-api-annotations/dist-install/build/check-api- annotations/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id containers-0.5.10.2 -package-id Cabal-2.0.0.0 -package-id directory-1.3.0.2 -package-id ghc-8.1 -Wall -XHaskell2010 -no-user- package-db -rtsopts -Wnoncanonical-monad-instances -odir utils /check-api-annotations/dist-install/build -hidir utils/check-api- annotations/dist-install/build -stubdir utils/check-api-annotations/dist- install/build -c utils/check-api-annotations/./Main.hs -o utils/check- api-annotations/dist-install/build/Main.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -fllvm -Wall -hide-all-packages -i -iutils/check- ppr/. -iutils/check-ppr/dist-install/build -Iutils/check-ppr/dist- install/build -iutils/check-ppr/dist-install/build/check-ppr/autogen -Iutils/check-ppr/dist-install/build/check-ppr/autogen -optP-include -optPutils/check-ppr/dist-install/build/check-ppr/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id Cabal-2.0.0.0 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.1 -package-id ghc-8.1 -Wall -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir utils/check-ppr/dist-install/build -hidir utils/check-ppr /dist-install/build -stubdir utils/check-ppr/dist-install/build -c utils/check-ppr/./Main.hs -o utils/check-ppr/dist-install/build/Main.dyn_o ghc-stage2: internal error: ghc-stage2: internal error: ghc-stage2: internal error: evacuate(static): strange closure type 0evacuate(static): strange closure type 0evacuate(static): strange closure type 0 (GHC version 8.1.20170304 for x86_64_apple_darwin) (GHC version 8.1.20170304 for x86_64_apple_darwin) (GHC version 8.1.20170304 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [utils/check-ppr/dist-install/build/Main.dyn_o] Abort trap: 6 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/check-api-annotations/dist-install/build/Main.dyn_o] Abort trap: 6 make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Abort trap: 6 make: *** [all] Error 2 }}} Building and linking against the debug rts, gives the following result in lldb. {{{ (lldb) settings set -- target.run-args "+RTS" "-DS" "-Dl" "-Ds" "-RTS" (lldb) run Process 3546 launched: '/ghc/inplace/lib/bin/ghc-stage2' (x86_64) 7fffae4753c0: created capset 0 of type 2 7fffae4753c0: created capset 1 of type 3 7fffae4753c0: cap 0: initialised 7fffae4753c0: assigned cap 0 to capset 0 7fffae4753c0: assigned cap 0 to capset 1 7fffae4753c0: allocated 1 more capabilities 7fffae4753c0: new task (taskCount: 1) 7fffae4753c0: returning; I want capability 0 7fffae4753c0: resuming capability 0 7fffae4753c0: cap 0: created thread 1 7fffae4753c0: new bound thread (1) 7fffae4753c0: cap 0: schedule() ghc-stage2: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 88 (GHC version 8.1.20170304 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Process 3546 stopped * thread #1: tid = 0x6df55a1, 0x00007fffa5756dd6 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main- thread', stop reason = signal SIGABRT frame #0: 0x00007fffa5756dd6 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fffa5756dd6 <+10>: jae 0x7fffa5756de0 ; <+20> 0x7fffa5756dd8 <+12>: movq %rax, %rdi 0x7fffa5756ddb <+15>: jmp 0x7fffa574fcdf ; cerror_nocancel 0x7fffa5756de0 <+20>: retq (lldb) bt all warning: could not load any Objective-C class information. This will significantly reduce the quality of type information available. * thread #1: tid = 0x6df55a1, 0x00007fffa5756dd6 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main- thread', stop reason = signal SIGABRT * frame #0: 0x00007fffa5756dd6 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fffa5842787 libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x00007fffa56bc420 libsystem_c.dylib`abort + 129 frame #3: 0x0000000102d09e61 ghc- stage2`rtsFatalInternalErrorFn(s="ASSERTION FAILED: file %s, line %u\n", ap=0x00007fff5fbfefe0) + 273 at RtsMessages.c:182 frame #4: 0x0000000102d0a16a ghc-stage2`barf(s="ASSERTION FAILED: file %s, line %u\n") + 346 at RtsMessages.c:46 frame #5: 0x0000000102d0a1a7 ghc- stage2`_assertFail(filename="rts/sm/Sanity.c", linenum=88) + 39 at RtsMessages.c:61 frame #6: 0x0000000102d3358e ghc- stage2`checkClosureShallow(p=0x0000000103412930) + 62 at Sanity.c:88 frame #7: 0x0000000102d31422 ghc- stage2`checkSmallBitmap(payload=0x0000000105c05368, bitmap=0, size=1) + 66 at Sanity.c:53 frame #8: 0x0000000102d31181 ghc- stage2`checkStackFrame(c=0x0000000105c05360) + 161 at Sanity.c:114 frame #9: 0x0000000102d3157b ghc- stage2`checkStackChunk(sp=0x0000000105c05360, stack_end=0x0000000105c05388) + 43 at Sanity.c:171 frame #10: 0x0000000102d321d4 ghc- stage2`checkSTACK(stack=0x0000000105c05000) + 116 at Sanity.c:515 frame #11: 0x0000000102d32154 ghc- stage2`checkTSO(tso=0x0000000105c05388) + 372 at Sanity.c:553 frame #12: 0x0000000102d10edd ghc- stage2`schedule(initialCapability=0x000000010353b640, task=0x0000000105900c30) + 461 at Schedule.c:323 frame #13: 0x0000000102d10b7b ghc- stage2`scheduleWaitThread(tso=0x0000000105c05388, ret=0x0000000000000000, pcap=0x00007fff5fbff328) + 203 at Schedule.c:2552 frame #14: 0x0000000102d06655 ghc- stage2`rts_evalIO(cap=0x00007fff5fbff328, p=0x0000000103412930, ret=0x0000000000000000) + 69 at RtsAPI.c:460 frame #15: 0x0000000102d46860 ghc- stage2`ioManagerStartCap(cap=0x00007fff5fbff328) + 32 at Signals.c:211 frame #16: 0x0000000102d4689e ghc-stage2`ioManagerStart + 46 at Signals.c:221 frame #17: 0x0000000102d0a9cb ghc- stage2`hs_init_ghc(argc=0x00007fff5fbff558, argv=0x00007fff5fbff550, rts_config=RtsConfig @ 0x00007fff5fbff4c0) + 843 at RtsStartup.c:290 frame #18: 0x0000000102d09c8a ghc-stage2`hs_main(argc=1, argv=0x00007fff5fbff690, main_closure=0x00000001030fd720, rts_config=RtsConfig @ 0x00007fff5fbff570) + 58 at RtsMain.c:51 frame #19: 0x00000001000c2b9c ghc-stage2`main + 188 frame #20: 0x00007fffa5628255 libdyld.dylib`start + 1 thread #2: tid = 0x6df560a, 0x00007fffa5756fda libsystem_kernel.dylib`__semwait_signal + 10 frame #0: 0x00007fffa5756fda libsystem_kernel.dylib`__semwait_signal + 10 frame #1: 0x00007fffa56ddb72 libsystem_c.dylib`nanosleep + 199 frame #2: 0x00007fffa56dda66 libsystem_c.dylib`usleep + 54 frame #3: 0x0000000102d45a02 ghc- stage2`itimer_thread_func(_handle_tick=0x0000000102d1dc00) + 82 at Pthread.c:132 frame #4: 0x00007fffa583faab libsystem_pthread.dylib`_pthread_body + 180 frame #5: 0x00007fffa583f9f7 libsystem_pthread.dylib`_pthread_start + 286 frame #6: 0x00007fffa583f1fd libsystem_pthread.dylib`thread_start + 13 (lldb) dis -s 0x0000000103412930 ghc-stage2`base_GHCziConcziIO_ensureIOManagerIsRunning_closure: 0x103412930 <+0>: andb %cl, %al 0x103412932 <+2>: wait 0x103412933 <+3>: addb (%rcx), %al 0x103412935 <+5>: addb %al, (%rax) 0x103412937 <+7>: addb %al, (%rax) 0x103412939 <+9>: addb %al, (%rax) 0x10341293b <+11>: addb %al, (%rax) 0x10341293d <+13>: addb %al, (%rax) 0x10341293f <+15>: addb %dl, -0x38(%rax) ghc-stage2`base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure: 0x103412942 <+2>: wait 0x103412943 <+3>: addb (%rcx), %al 0x103412945 <+5>: addb %al, (%rax) 0x103412947 <+7>: addb %al, (%rax) 0x103412949 <+9>: addb %al, (%rax) 0x10341294b <+11>: addb %al, (%rax) 0x10341294d <+13>: addb %al, (%rax) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 16:10:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 16:10:09 -0000 Subject: [GHC] Trac email verification for user: lars Message-ID: <20170305161009.A388D3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: lars Verification Token: UZ8JL-No -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 16:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 16:14:26 -0000 Subject: [GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c In-Reply-To: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> References: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> Message-ID: <059.87dc3be46efb625fb75b37781b44075b@haskell.org> #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c -------------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => upstream * architecture: x86 => Unknown/Multiple Comment: Thanks for the report, this seems to be an issue with the mingw-w64 runtime. I haven't narrowed it down yet, but essentially something seems to be eating the events and it never reaches ghci. `CtrlHandler` is never called. The following example shows the issue. It works when compiled using the Microsoft compiler but doesn't with mingw-w64's GHC. {{{ #include #include BOOL CtrlHandler( DWORD fdwCtrlType ) { switch( fdwCtrlType ) { // Handle the CTRL-C signal. case CTRL_C_EVENT: printf( "Ctrl-C event\n\n" ); Beep( 750, 300 ); return( TRUE ); // CTRL-CLOSE: confirm that the user wants to exit. case CTRL_CLOSE_EVENT: Beep( 600, 200 ); printf( "Ctrl-Close event\n\n" ); return( TRUE ); // Pass other signals to the next handler. case CTRL_BREAK_EVENT: Beep( 900, 200 ); printf( "Ctrl-Break event\n\n" ); return FALSE; case CTRL_LOGOFF_EVENT: Beep( 1000, 200 ); printf( "Ctrl-Logoff event\n\n" ); return FALSE; case CTRL_SHUTDOWN_EVENT: Beep( 750, 500 ); printf( "Ctrl-Shutdown event\n\n" ); return FALSE; default: return FALSE; } } int main( void ) { if( SetConsoleCtrlHandler( (PHANDLER_ROUTINE) CtrlHandler, TRUE ) ) { printf( "\nThe Control Handler is installed.\n" ); printf( "\n -- Now try pressing Ctrl+C or Ctrl+Break, or" ); printf( "\n try logging off or closing the console...\n" ); printf( "\n(...waiting in a loop for events...)\n\n" ); while( 1 ){ } } else { printf( "\nERROR: Could not set control handler"); return 1; } return 0; } }}} This also doesn't work in an msys2 console, even though it appears to. In the case of msys2 bash is disabling `ENABLE_PROCESSED_INPUT` so that `CTRL+C` is not processed by the system and is reported as a input stream. Bash is then just terminating the process by force. In the case of GHCi, something does clearly happen with the runtime since it suddenly starts allocating a large amount of memory and enters some kind of deadlock. So there are two separate issues here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 16:17:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 16:17:38 -0000 Subject: [GHC] #13329: Windows CMD.EXE "Quick Edit Mode" In-Reply-To: <050.6dd8a7e9c30afcf63396503e6ba3ff0b@haskell.org> References: <050.6dd8a7e9c30afcf63396503e6ba3ff0b@haskell.org> Message-ID: <065.b78de7871a67321b59a9ec884ca1d6bb@haskell.org> #13329: Windows CMD.EXE "Quick Edit Mode" -------------------------------------+------------------------------------- Reporter: irongremlin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: clipboard, | quick edit Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): We don't seem to do anything that should be causing this issue in GHC itself. This is likely related to something in MingW-w64's CRT0, though I have yet to confirm this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 18:05:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 18:05:44 -0000 Subject: [GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals In-Reply-To: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> References: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> Message-ID: <062.a8624195c9cc0d05263039e068872950@haskell.org> #13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T13257 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3281 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * owner: (none) => ruperthorlick * testcase: => deSugar/should_compile/T13257 * differential: => Phab:D3281 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 18:05:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 18:05:52 -0000 Subject: [GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals In-Reply-To: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> References: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> Message-ID: <062.229883c9bb1d941ecd90942627eac0eb@haskell.org> #13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick Type: feature request | 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: | deSugar/should_compile/T13257 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3281 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 19:13:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 19:13:37 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.3d6080bdff8272813e5f29dc82f386d0@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I'll add thoughts and examples to this [https://gist.github.com/Icelandjack/06bcc4f62cb42ada120839bf409a53e4 gist] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 19:34:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 19:34:52 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.93d62a7526617e09b1e0d3274bd9f7f7@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: (none) => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 19:47:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 19:47:33 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.f715059120b8ca57e5913b5e2c8471e5@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D3282 Comment: The problem is actually that string sections produced by the LLVM backend are not getting merged, and the number of resulting sections was too large for what is apparently an internal limit in `ld.bfd` (`ld.gold` was happy to produce an executable with ~120000 sections). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 19:52:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 19:52:06 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.a9f9dff7088f63b26427fd41a28e0818@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > (I seem to recall you mentioning a gain of roughly 1% from one or the other, but it's not in this ticket, perhaps IRC..) Yes, I think I mentioned on IRC that your D1259 sped up the build by about 1%; likely because it fixes CSE, but not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 19:59:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 19:59:47 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining Message-ID: <048.3a3cc2c8142cd380727a72eb402237bb@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 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: -------------------------------------+------------------------------------- Compiling the attached example yields quadratic behavior and a big space leak (eventually the oom killer kills it) during inlining. Tested on both ghc 7.10.3 and 8.0.1 I compiled with `-fforce-recomp --make -O2 -ddump-inlinings Main.hs` In cases where the process was able to run for a while I could see that each chunk of inlinings was getting slower linearly (every minute or so you can hit enter and which the line break go up your terminal a little slower than the last time). I assume the slowdown is due to GC over the growing heap due to a leak, but maybe the inlining algorithm is quadratic. Apologies if this is a dupe; I had trouble searching for similar issues. (I did find #13316 but don't understand if this could be related) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 20:00:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 20:00:52 -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.7c5434d95d03cadffb260fa95bdae7e4@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 YitzGale): How are other compilers dealing with this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 20:00:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 20:00: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.daf60d2ccf412dc340d1f2ee6618086d@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 jberryman): * Attachment "Main.hs" added. Main.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 20:40:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 20:40:53 -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.120efa7891ca2a9c2dc3aebd64d76ae3@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 rwbarton): Even the space usage is quadratic, so something does seem amiss here. I recommend cutting the example down to at most 100 lines if you want to compile it in a reasonable amount of time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 20:56:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 20:56:32 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.ec06943ea22b7345915d6e9c0953d4ca@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Okay so `checkClosureShallow` is getting passed the address of `base_GHCziConcziIO_ensureIOManagerIsRunning_closure`, which is all well and good. Running the disassembly of the closure back through an assembler gives {{{ Contents of section .text: 0000 20c89b02 01000000 00000000 00000000 ............... }}} which also looks fine (a pointer to some code, followed by a zero or unused word). Based on the definition of `LOOKS_LIKE_CLOSURE_PTR`, it appears that the info table that is supposed to be located before whatever symbol is at `0x01029bc820` is missing; probably a dead code stripping issue again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 22:43:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 22:43:40 -0000 Subject: [GHC] #13341: Lift constraint products In-Reply-To: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> References: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> Message-ID: <066.375a75bf68d86336c42eb39812fe3c0c@haskell.org> #13341: Lift constraint products -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I want to get a discussion going, could we lift constraint products > automatically. > > Although not partially applicable, we can consider `(,)` as having kind > > {{{#!hs > (,) :: Constraint -> Constraint -> Constraint > }}} > > I propose also giving it kinds > > {{{#!hs > (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) > > (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> > Constraint) > > -- etc. > }}} > > == Translation > > {{{#!hs > (Eq, Num, Show) > (Monad, Foldable) > (Category, Profunctor) > }}} > > gets turned into something like > > {{{#!hs > class (c a, d a) => (c :&: d) a > instance (c a, d a) => (c :&: d) a > infixl 7 :&: > > Eq:&:Num:&:Show > Monad:&:Foldable > Category:&:Profunctor > }}} > > == Uses > > Very often I need to be able to combine constraints. > > A small modification of [https://hackage.haskell.org/package/free- > functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] > > {{{#!hs > type c :~ d = forall xx. c x :- d xx > > class HasSuperClasses (c :: k -> Constraint) where > type SuperClasses c :: k -> Constraint > type SuperClasses c = c > > superClasses :: c :~ SuperClasses c > containsSelf :: SuperClasses c :~ c > > instance HasSuperClasses Functor where > superClasses :: Functor :~ Functor > superClasses = Sub Dict > > containsSelf :: Functor :~ Functor > containsSelf = Sub Dict > > instance HasSuperClasses Foldable where > superClasses :: Foldable :~ Foldable > superClasses = Sub Dict > > containsSelf :: Foldable :~ Foldable > containsSelf = Sub Dict > }}} > > I want to be able to write > > {{{#!hs > instance HasSuperClasses Traversable where > type Traversable = (Traversable, Functor, Foldable) > > superClasses :: Traversable :~ (Traversable, Functor, Foldable) > superClasses = Sub Dict > > containsSelf :: (Traversable, Functor, Foldable) :~ Traversable > containsSelf = Sub Dict > }}} > > If this doesn't pose any difficulties I'll open a GHC proposal. New description: I want to get a discussion going, could we lift constraint products automatically. Although not partially applicable, we can consider `(,)` as having kind {{{#!hs (,) :: Constraint -> Constraint -> Constraint }}} I propose also giving it kinds {{{#!hs (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) -- etc. }}} == Translation {{{#!hs (Eq, Num, Show) (Monad, Foldable) (Category, Profunctor) }}} gets turned into something like {{{#!hs class (c a, d a) => (c :&: d) a instance (c a, d a) => (c :&: d) a infixl 7 :&: Eq:&:Num:&:Show Monad:&:Foldable Category:&:Profunctor }}} == Uses Very often I need to be able to combine constraints. A small modification of [https://hackage.haskell.org/package/free- functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] {{{#!hs type c :~ d = forall xx. c x :- d xx class HasSuperClasses (c :: k -> Constraint) where type SuperClasses c :: k -> Constraint type SuperClasses c = c superClasses :: c :~ SuperClasses c containsSelf :: SuperClasses c :~ c instance HasSuperClasses Functor where superClasses :: Functor :~ Functor superClasses = Sub Dict containsSelf :: Functor :~ Functor containsSelf = Sub Dict instance HasSuperClasses Foldable where superClasses :: Foldable :~ Foldable superClasses = Sub Dict containsSelf :: Foldable :~ Foldable containsSelf = Sub Dict }}} I want to be able to write {{{#!hs instance HasSuperClasses Traversable where type Traversable = (Traversable, Functor, Foldable) superClasses :: Traversable :~ (Traversable, Functor, Foldable) superClasses = Sub Dict containsSelf :: (Traversable, Functor, Foldable) :~ Traversable containsSelf = Sub Dict }}} If this doesn't pose any difficulties I'll open a GHC proposal. == Etc. == With #12369, why not make them all instances of the same data family (including `(,)` and `Product`) {{{#!hs data family (,) :: k -> k -> k -- (,) :: Type -> Type -> Type data instance (a, b) = (a, b) -- Data.Functor.Product.Product :: (k -> Type) -> (k -> Type) -> (k -> Type) data instance (f, g) a = Pair (f a) (g a) -- Data.Bifunctor.Product.Product :: (k -> k' -> Type) -> (k -> k' -> Type) -> (k -> k' -> Type) data instance (f, g) a b = Pair2 (f a b) (g a b)) }}} the type class could be made an instance of this “data” family: {{{#!hs -- (,) :: Constraint -> Constraint -> Constraint -- (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) class (c a, d a) => (c, d) a instance (c a, d a) => (c, d) a -- (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) class (c a b, d a b) => (c, d) a b instance (c a b, d a b) => (c, d) a b }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 23:36:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 23:36:24 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong Message-ID: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `primops.txt.pp` includes the following note: > `raiseIO#` needs to be a primop, because exceptions in the `IO` monad must be ''precise'' - we don't want the strictness analyser turning one kind of bottom into another, as it is allowed to do in pure code. > > But we ''do'' want to know that it returns bottom after being applied to two arguments, so that this function is strict in `y` > {{{#!hs > f x y | x>0 = raiseIO blah > | y>0 = return 1 > | otherwise = return 2 > }}} I believe the "But we do" portion is, unfortunately, entirely wrong. From a user perspective, it is extremely strange to replace a precise exception with an imprecise one. That is, I strongly believe the above code should be considered ''lazy'' in `y`. The function `f` calculates an `IO` action; the value of `y` is only necessary to calculate that action if `x` is non- positive. We can, conservatively, say for certain that the second component of the result of `raiseIO#` (i.e., the "return value") is bottom. We can also say, given {{{#!hs case raiseIO# e s of (# s', r #) -> q }}} that `q` is dead (we could replace it by `(# s', undefined #)`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 5 23:40:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Mar 2017 23:40:24 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.a1f2f047b4f460f4901e70948e9e947b@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've set an optimistic milestone for this, but we will probably need to wait for 8.4 to dig a bit deeper into how demand analysis interacts with `raise#`, `raiseIO#`, `retry#`, `catch#`, `catchSTM#`, and `catchRetry#`. There seem to be subtle problems in multiple places. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 00:27:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 00:27:59 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.8bacee0d7b1eb5e9afa3a4d8258f3715@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ThreeFx): Just a note: The culprit seems to be `displayLintResults` in `compiler/coreSyn/CoreLint.hs`. Using `log_action` with the severity `SevDump` writes the given text to `stdout`. By changing this to `SevWarning` it is written to `stderr` instead, although the error message is worse than before because it is even more redundant: {{{ : warning: *** Core Lint warnings : in result of Occurrence analysis *** test.hs:4:1: warning: [RHS of f :: [()] -> [()]] INLINE binder is (non-rule) loop breaker: f }}} Since linting `Core` is a compiler developer thing 99% of the time, IMO it is more important to print concise and clear error messages/warnings than to write to the correct output (the first line overshadows the linting error). But these are just my 2 cents. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 01:14:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 01:14:32 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.313612cc86841c510ab8eb61440e3569@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think it's just a bit of imprecise wording. It's right that `raiseIO#` returns bottom after being applied to ''two'' arguments, as: {{{#!hs raiseIO# :: a -> State# RealWorld -> (# State# RealWorld, b #) }}} But the function in the example is strict in `y` only after being applied to a third argument, i.e., executed. You can try this: {{{#!hs import Control.Exception f :: Int -> Int -> IO Int f x y | x > 0 = throwIO StackOverflow | y > 0 = return 1 | otherwise = return 2 u :: Int u = -1 {-# NOINLINE u #-} main :: IO () main = f u undefined `seq` return () }}} and it's not optimized to bottom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 01:23:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 01:23:36 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.f2ba827f869fe3de999f40e8540c9166@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): @rwbarton, no, I understood that just fine. The trouble is that I don't think it's valid to analyze that as bottom when applied to three arguments, because then we lose the perfectly well-defined ''action'' of throwing a precise exception. Instead of performing that action, we can end up throwing an imprecise exception evaluating something we have no business evaluating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 03:01:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 03:01:00 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.c2567a86bc5d9969e615e14e2708f2e4@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Full test case: {{{#!hs import Control.Exception {-# NOINLINE f #-} f :: Int -> Int -> IO Int f x y | x>0 = throwIO (userError "What") | y>0 = return 1 | otherwise = return 2 main = f 2 undefined >>= print }}} I would expect this to throw the "What" exception, but when it's compiled with optimization I get the "undefined" exception. If I had written `throw (userError "What")`, that would be acceptable, because we don't make any guarantees about which imprecise exception in the imprecise exception set we actually throw. But here we are re-ordering evaluation in such a fashion as to throw an imprecise exception instead of a precise one, and I don't think that's legit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 03:02:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 03:02:26 -0000 Subject: [GHC] Trac email verification for user: Neuromancer42 Message-ID: <20170306030226.5AF273A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: Neuromancer42 Verification Token: PUcrY7cG -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 03:57:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 03:57:42 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule Message-ID: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Roboguy reports (via IRC) that the following causes a GHC panic: {{{#!hs {-# LANGUAGE RankNTypes #-} module Crash where data Exp a = Exp fromExp :: Exp a -> a fromExp _ = error "Impossible" toExp :: a -> Exp a toExp _ = Exp newtype Iter a b = Iter { getIter :: forall r. (a -> r) -> (b -> r) -> r } iterLoop :: (a -> Iter a b) -> a -> b iterLoop f x = getIter (f x) (iterLoop f) id -- This rewrite rule results in a GHC panic: "opt_univ fell into a hole" on GHC 8.0.1, 8.0.2, and 8.1. {-# RULES "fromExp-into-iterLoop" [~] forall (f :: Int -> Iter (Exp Int) (Exp Char)) (init :: Int). fromExp (iterLoop f init) = fromExp (iterLoop (f . fromExp) (toExp init)) #-} }}} I have confirmed this, and see the following error: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170305 for x86_64-unknown-linux): opt_univ fell into a hole {a1WD} Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:398:29 in ghc:OptCoercion }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 06:08:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 06:08:23 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.636095c60940a75d744479b03a9e415f@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): The offending commit is this one: https://phabricator.haskell.org/rGHC0a6c257de5c217436ec61fdf4b06bca059181f83 found via git bisect after ~5hrs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 06:15:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 06:15:36 -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.a2558f3cd8b3be72d0c277e84cec3e88@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 Rufflewind): Turns out, despite what [https://msdn.microsoft.com/en- us/library/windows/desktop/aa365530.aspx MSDN] says, `SetCurrentDirectoryW` does not seem to support long paths through the `\\?\` prefix. I saw an [https://news.ycombinator.com/item?id=13093529 anecdote] that it ''does'' work if one opts-in through the Win10-only feature (through manifest and/or (?) registry tweak), as long as you append a backslash. Since it still did not work with the `\\?\` prefix even after appending a backslash, so I can only assume that `\\?\` is broken for `SetCurrentDirectoryW`, but the registry/manifest tweak likely does work. My guess is that because in the past `SetCurrentDirectoryW` never supported `\\?\` to begin with, when they added the Win10 feature, whoever updated the documentation probably copy-pasted that section throughout and forgot that `\\?\` was ''specifically not enabled'' for `SetCurrentDirectoryW` unlike many other functions, likely because it would make the counterpart `GetCurrentDirectoryW` risky for improperly written programs. TL;DR: It does not seem possible to set the current directory to a long path except through the Win-10 only mechanism. Also, a lot of Windows functions will choke on relative paths if the resulting path becomes too long, so users will have to use exclusively `\\?\`-style absolute paths. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 08:33:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 08:33:48 -0000 Subject: [GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores In-Reply-To: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> References: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> Message-ID: <060.400bc8589b0c6f7896b754329170bc86@haskell.org> #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores --------------------------------------------+------------------------------ Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by simonmar): Yes, perhaps `+RTS -N` should automatically readjust at some regular interval. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 09:46:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 09:46:30 -0000 Subject: [GHC] #13341: Lift constraint products In-Reply-To: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> References: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> Message-ID: <066.4f9f2cc1d61f057c4850fb5a74bf5c73@haskell.org> #13341: Lift constraint products -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I want to get a discussion going, could we lift constraint products > automatically. > > Although not partially applicable, we can consider `(,)` as having kind > > {{{#!hs > (,) :: Constraint -> Constraint -> Constraint > }}} > > I propose also giving it kinds > > {{{#!hs > (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) > > (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> > Constraint) > > -- etc. > }}} > > == Translation > > {{{#!hs > (Eq, Num, Show) > (Monad, Foldable) > (Category, Profunctor) > }}} > > gets turned into something like > > {{{#!hs > class (c a, d a) => (c :&: d) a > instance (c a, d a) => (c :&: d) a > infixl 7 :&: > > Eq:&:Num:&:Show > Monad:&:Foldable > Category:&:Profunctor > }}} > > == Uses > > Very often I need to be able to combine constraints. > > A small modification of [https://hackage.haskell.org/package/free- > functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] > > {{{#!hs > type c :~ d = forall xx. c x :- d xx > > class HasSuperClasses (c :: k -> Constraint) where > type SuperClasses c :: k -> Constraint > type SuperClasses c = c > > superClasses :: c :~ SuperClasses c > containsSelf :: SuperClasses c :~ c > > instance HasSuperClasses Functor where > superClasses :: Functor :~ Functor > superClasses = Sub Dict > > containsSelf :: Functor :~ Functor > containsSelf = Sub Dict > > instance HasSuperClasses Foldable where > superClasses :: Foldable :~ Foldable > superClasses = Sub Dict > > containsSelf :: Foldable :~ Foldable > containsSelf = Sub Dict > }}} > > I want to be able to write > > {{{#!hs > instance HasSuperClasses Traversable where > type Traversable = (Traversable, Functor, Foldable) > > superClasses :: Traversable :~ (Traversable, Functor, Foldable) > superClasses = Sub Dict > > containsSelf :: (Traversable, Functor, Foldable) :~ Traversable > containsSelf = Sub Dict > }}} > > If this doesn't pose any difficulties I'll open a GHC proposal. > > == Etc. == > > With #12369, why not make them all instances of the same data family > (including `(,)` and `Product`) > > {{{#!hs > data family (,) :: k -> k -> k > > -- (,) :: Type -> Type -> Type > data instance (a, b) = (a, b) > > -- Data.Functor.Product.Product :: (k -> Type) -> (k -> Type) -> (k -> > Type) > data instance (f, g) a = Pair (f a) (g a) > > -- Data.Bifunctor.Product.Product :: (k -> k' -> Type) -> (k -> k' -> > Type) -> (k -> k' -> Type) > data instance (f, g) a b = Pair2 (f a b) (g a b)) > }}} > > the type class could be made an instance of this “data” family: > > {{{#!hs > -- (,) :: Constraint -> Constraint -> Constraint > > -- (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) > class (c a, d a) => (c, d) a > instance (c a, d a) => (c, d) a > > -- (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' > -> Constraint) > class (c a b, d a b) => (c, d) a b > instance (c a b, d a b) => (c, d) a b > }}} New description: I want to get a discussion going, could we lift constraint products automatically. Although not partially applicable, we can consider `(,)` as having kind {{{#!hs (,) :: Constraint -> Constraint -> Constraint }}} I propose also giving it kinds {{{#!hs (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) -- etc. }}} == Translation {{{#!hs (Eq, Num, Show) (Monad, Foldable) (Category, Profunctor) }}} gets turned into something like {{{#!hs class (c a, d a) => (c :&: d) a instance (c a, d a) => (c :&: d) a infixl 7 :&: Eq:&:Num:&:Show Monad:&:Foldable Category:&:Profunctor }}} == Uses Very often I need to be able to combine constraints. A small modification of [https://hackage.haskell.org/package/free- functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] {{{#!hs type c :~ d = forall xx. c x :- d xx class HasSuperClasses (c :: k -> Constraint) where type SuperClasses c :: k -> Constraint type SuperClasses c = c superClasses :: c :~ SuperClasses c containsSelf :: SuperClasses c :~ c instance HasSuperClasses Functor where superClasses :: Functor :~ Functor superClasses = Sub Dict containsSelf :: Functor :~ Functor containsSelf = Sub Dict instance HasSuperClasses Foldable where superClasses :: Foldable :~ Foldable superClasses = Sub Dict containsSelf :: Foldable :~ Foldable containsSelf = Sub Dict }}} I want to be able to write {{{#!hs instance HasSuperClasses Traversable where type Traversable = (Traversable, Functor, Foldable) superClasses :: Traversable :~ (Traversable, Functor, Foldable) superClasses = Sub Dict containsSelf :: (Traversable, Functor, Foldable) :~ Traversable containsSelf = Sub Dict }}} If this doesn't pose any difficulties I'll open a GHC proposal. == Etc. == With #12369, why not make them all instances of the same data family (including `(,)` and `Product`) {{{#!hs data family (,) :: k -> k -> k -- (,) :: Type -> Type -> Type data instance (a, b) = (a, b) -- Data.Functor.Product.Product :: (k -> Type) -> (k -> Type) -> (k -> Type) data instance (f, g) a = f a `Pair` g a -- Data.Bifunctor.Product.Product :: (k -> k' -> Type) -> (k -> k' -> Type) -> (k -> k' -> Type) data instance (f, g) a b = f a b `Pair2` g a b }}} the type class could be made an instance of this “data” family: {{{#!hs -- (,) :: Constraint -> Constraint -> Constraint -- (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) class (c a, d a) => (c, d) a instance (c a, d a) => (c, d) a -- (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) class (c a b, d a b) => (c, d) a b instance (c a b, d a b) => (c, d) a b }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 10:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 10:29:43 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.9219619ae15eb79b4b8fe3017d27127b@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: bug | Status: new Priority: high | 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 mboes): I'm not convinced there is any bug here. inline-c snippets really are stubs, and C ones at that, no different from the ones produced by the `capi` calling convention and foreign exports. So it makes sense to treat them as such. And even to include the inline-c snippets in the same stubs file as the other stubs, since any compiler options should apply equally to both. Now, should we furthermore support C++? I'm unconvinced that this should be done as part of `addCStub`. After all, C++ is an entirely separate language. It so happens that a large subset of C is included in C++, but that's incidental. In fact C++ is so different that name mangling is different, and not understood by GHC at all. So I think that if users want not just C stubs but also C++ stubs, that it makes sense to have `addCppStubs`, which ideally would take into account Cabal's `cpp-options`, just as `addCStubs` takes into account `cc- options`. And why not, in the future `addJavaStubs`, `addCsharpStubs` etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 10:30:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 10:30:38 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.0fac40e39decfafabe3a88a402e535e8@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: bug | Status: new Priority: high | 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 mboes): Argh forget what I said about `cpp-options`... That's CPP as in the preprocessor obviously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 10:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 10:58:32 -0000 Subject: [GHC] Trac email verification for user: henenenerik Message-ID: <20170306105832.A87713A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: henenenerik Verification Token: 3-SC1QCT -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 10:59:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 10:59:17 -0000 Subject: [GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels Message-ID: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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 latent bug, so there's no test case. Given code like {{{ let f = \x y z -> e1 in e2 }}} we have `SetLevels` put a “join ceiling” around `e1` to be sure that we don't let a join point float out, since any jump to that join point from `e1` would be invalid. However, an oversight in `lvlFloatRhs` has us putting the join ceiling around the lambdas instead—in other words, it appears that we might produce {{{ let f = join j = ... in \x y z -> ... jump j ... in e2 }}} (which is wrong because you can't jump out of a lambda) rather than {{{ let f = \x y z -> join j = ... in ... jump j ... in e2 }}} As it happens, this bug is latent because of the way `FloatOut` and `SetLevels` interact. `FloatOut` correctly understands where the join ceiling //should// be. Then, at each join ceiling, `FloatOut` drops all bindings marked “float me to the nearest join ceiling,” so if `j` is so marked, the latter example (the correct one) is the result and not the former. Nonetheless, `lvlFloatRhs` as written is clearly wrong. (This of course illustrates a shortcoming of the “join ceiling” scheme, at least as implemented: we rely on `FloatOut` and `SetLevels` agreeing on where the join ceilings are. It's easy to specify where they //should// be, but since there are two modules implementing them, we have twice the opportunities to get it wrong.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 10:59:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 10:59:39 -0000 Subject: [GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels In-Reply-To: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> References: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> Message-ID: <064.56f4427306dde9e61f6ff90ee0422f12@haskell.org> #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukemaurer): * owner: (none) => lukemaurer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 11:00:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 11:00:10 -0000 Subject: [GHC] Trac email verification for user: henenenerik Message-ID: <20170306110010.7FB173A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: henenenerik Verification Token: 3-SC1QCT -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 11:10:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 11:10:39 -0000 Subject: [GHC] #13383: ghc: panic! Message-ID: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> #13383: ghc: panic! -------------------------------------+------------------------------------- Reporter: henenenerik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Panic | Operating System: Windows Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tried to compile some code provided in the course I'm taking and caused ghc to panic. Got this in my command prompt: {{{ [1 of 1] Compiling Main ( temp.hs, temp.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] throw_a2dw :: t_a2dv[tau:1] (CHoleCan: throw) [W] throw_a2eY :: t_a2eX[tau:1] (CHoleCan: throw) [W] throw_a2fc :: t_a2fb[tau:1] (CHoleCan: throw)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 11:11:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 11:11:04 -0000 Subject: [GHC] #13383: ghc: panic! In-Reply-To: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> References: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> Message-ID: <065.9e91e2e462e44b71cee4bd9027dcea87@haskell.org> #13383: ghc: panic! -------------------------------------+------------------------------------- Reporter: henenenerik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Panic Operating System: Windows | 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 henenenerik): * failure: Incorrect API annotation => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 11:11:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 11:11:39 -0000 Subject: [GHC] #13383: ghc: panic! In-Reply-To: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> References: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> Message-ID: <065.134b87e0aaaee5844dcda0e683f445b9@haskell.org> #13383: ghc: panic! -------------------------------------+------------------------------------- Reporter: henenenerik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Panic Operating System: Windows | 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 henenenerik): * Attachment "temp.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 11:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 11:50:21 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.dcde089c127322b94ef5888c18ff8693@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: bug | Status: new Priority: high | 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 bitonic): The situation is that right now `addCStubs` streams content to the same file that is used for Haskell-from-C exports and `capi` calls, which I think is very fragile. This file includes imports and CPP macros outside the control of the person using `addCStub`, and thus code using `addCStub` might very well break if we change how that file is generated of simply if the C code conflicts with the content that is already in the stubs file. Moreover, if we want to add multi-language support, we needed to generate multiple files anyway. So me, rwbarton, and bgamari concluded that it would be better to just let the user emit an arbitrary number of files that will be compiled and linked with the current module. This is well-suited to `inline-c` since we can collect all the stubs and emit them at once with `addModFinalizer`. Hopefully this makes the motivation for the change clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 12:17:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 12:17:17 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.32cd6794e4894d372fca9e0746833459@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: feature request | Status: new Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D3280 * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 13:43:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 13:43:38 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.3117e1fdbe99f78ad00ddcdbcea3d712@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So our options seem to be, in increasing order of desirability: 0. Just don't use `-dead_strip` at link time by default on Darwin. But it doesn't really fix the problem, since a downstream link process could still use `-dead_strip`. Furthermore it would break dead code stripping for the NCG, which currently does work. (We'd then have to use `-split- objs` everywhere to get the same effect.) 1. Disable subsections-via-symbols for modules compiled with the LLVM backend. angerman found that llc unconditionally enables subsections-via- symbols on Darwin with a "funny hack" (https://github.com/llvm- mirror/llvm/blob/f61ad6ec119554f251f44f54c9cf42d8b713866e/lib/Target/X86/X86AsmPrinter.cpp#L607-L612). But we could remove the directive in the LLVM mangler. This would be a sound thing to do, but we'd have no way to do dead code stripping when using LLVM; and on iOS LLVM is the only available option. 2. Insert symbols that point to the start of info tables and give them some kind of externally-visible linkage or mark them as `.no_dead_strip`. I don't think the LLVM input language gives us any way to do this, but we could probably do it in the mangler. This would give us some degree of dead code stripping, but it would keep ''all'' info tables live, even those that were attached to functions that got stripped. As far as I can see that's not a problem except in that the eventual object file will not be as small as it could be. I think this was the strategy used by https://phabricator.haskell.org/D206, but with the adoption of prefix data it's not so easy to implement any more. 3. Insert symbols that point to the start of info tables, and also insert a reference at the end of each function to the start of its info table. Again we could probably do this in the mangler, though it would be more complicated. Ideally we would have some kind of "suffix data" mechanism for this... This would give the best dead code stripping (at the cost of slightly larger code in the non-stripped case) and it's the strategy used by the NCG. (See where `X86.Ppr.pprNatCmmDecl` uses `platformHasSubsectionsViaSymbols`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 13:46:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 13:46:47 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.895f6497b8e62d879b600d3e79930ff0@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great stuff. My CSE patch is done but I have to re-validate having caught up with HEAD. In flight... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 13:57:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 13:57:12 -0000 Subject: [GHC] #13383: ghc: panic! In-Reply-To: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> References: <050.2a2c8f68d74c3a809b0fbeb94a09ccb8@haskell.org> Message-ID: <065.d6b0100641a15d6e964c7b1844359078@haskell.org> #13383: ghc: panic! -------------------------------------+------------------------------------- Reporter: henenenerik | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Panic Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple 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 bug report. This is a duplicate of #13106, which has been fixed as of GHC 8.0.2. The error relates to the fact that `throw` is not defined. On 8.0.2 or later, it properly reports this: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( temp.hs, interpreted ) temp.hs:7:11: error: Variable not in scope: throw :: Exception -> Exceptional Int temp.hs:16:50: error: Variable not in scope: throw :: Exception -> Exceptional String temp.hs:19:25: error: Variable not in scope: throw :: Exception -> Exceptional String }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 13:59:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 13:59:20 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule In-Reply-To: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> References: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> Message-ID: <060.053524128df68364adb11fabf2c2df5a@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To make things even more interesting, this error does not occur on GHC 7.8 or 7.10. Here's the error you get with 7.10.3: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Crash ( Bug.hs, interpreted ) Bug.hs:25:23: Couldn't match type ‘Exp Int’ with ‘Int’ Expected type: Exp Int -> Iter (Exp Int) (Exp Char) Actual type: Int -> Iter (Exp Int) (Exp Char) In the first argument of ‘iterLoop’, namely ‘f’ In the first argument of ‘fromExp’, namely ‘(iterLoop f init)’ Bug.hs:25:25: Couldn't match expected type ‘Exp Int’ with actual type ‘Int’ In the second argument of ‘iterLoop’, namely ‘init’ In the first argument of ‘fromExp’, namely ‘(iterLoop f init)’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 14:06:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 14:06:01 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later In-Reply-To: <043.b25e91253b49ad08042d636adf423d59@haskell.org> References: <043.b25e91253b49ad08042d636adf423d59@haskell.org> Message-ID: <058.c19b93054264f309720f8688470ccc2b@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmm): While 8.0.2 did build fine, I see lots of these on console: {{{ swap_pager_getswapspace(8): failed swap_pager_getswapspace(14): failed swap_pager_getswapspace(9): failed ... }}} That may have existed for 8.0.1 too and I missed it. Given the nature of use for MAP_NORESERVE change, it may be responsible for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 14:26:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 14:26:58 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule In-Reply-To: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> References: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> Message-ID: <060.683391f6396d21aec815f29e8a53afb7@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: Commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2 (Add kind equalities to GHC) introduced this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 14:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 14:32:49 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.8d6aedf05963b91a38e06b3117204e54@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think printing to the correct output is out primary importance here. If you don't interleave outputs and only inspect `stderr` for errors then you will not see these warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 14:45:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 14:45:13 -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.a8367f1d3f4819c53aa69a9690545d22@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): Phab link for the "I still want to try the effect of earlier inlining of INLINE thing" part: https://phabricator.haskell.org/D3203 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 14:49:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 14:49:50 -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.62827b5912e2ee587759123136994e64@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 simonpj): It's committed in HEAD. {{{ commit 2effe18ab51d66474724d38b20e49cc1b8738f60 Author: Simon Peyton Jones Date: Tue Feb 28 16:07:20 2017 -0500 The Early Inline Patch This very small patch switches on sm_inline even in the InitialPhase (aka "gentle" phase). There is no reason not to... and the results are astonishing. }}} Back to you Mikolaj! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 14:57:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 14:57:17 -0000 Subject: [GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels In-Reply-To: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> References: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> Message-ID: <064.e6d817cd69a236d6e25282f59135e31f@haskell.org> #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I want to kill off the entire join-ceiling thing. I don't think `FloatOut` should float join-points at all. Instead the simplifier can, as it does now for local bindings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:09:47 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern In-Reply-To: <047.984d4241873e1562c305a37585f1b95c@haskell.org> References: <047.984d4241873e1562c305a37585f1b95c@haskell.org> Message-ID: <062.7007b1dc22cce7a3be5b2340072fd33e@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T13260 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3286 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * owner: (none) => ruperthorlick * testcase: => parser/should_fail/T13260 * differential: => Phab:D3286 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:10:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:10:02 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern In-Reply-To: <047.984d4241873e1562c305a37585f1b95c@haskell.org> References: <047.984d4241873e1562c305a37585f1b95c@haskell.org> Message-ID: <062.dd9f3f0feb668d0c8ed1ee303b13e239@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick 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: | parser/should_fail/T13260 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3286 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ruperthorlick): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:20:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:20:43 -0000 Subject: [GHC] #13367: CSE not working for top-level literal strings In-Reply-To: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> References: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> Message-ID: <061.b326292cefe18277187272aa223b0a73@haskell.org> #13367: CSE not working for top-level literal strings -------------------------------------+------------------------------------- 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:"9304df5230a7a29d3e992916d133e462b854e55f/ghc" 9304df52/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9304df5230a7a29d3e992916d133e462b854e55f" Fix CSE (again) on literal strings Fixes Trac #13367. See Note [Take care with literal strings] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:20:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:20:43 -0000 Subject: [GHC] #13369: Float-out is not idempotent In-Reply-To: <046.634bbbfff77b021b9c4e1a0c9964fad2@haskell.org> References: <046.634bbbfff77b021b9c4e1a0c9964fad2@haskell.org> Message-ID: <061.b72730e6c7826dfe19645b3fb5c0e33c@haskell.org> #13369: Float-out is not idempotent -------------------------------------+------------------------------------- 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:"fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2/ghc" fb9ae288/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2" Make FloatOut/SetLevels idemoptent on bottoming functions This fixes Trac #13369. It turned out that I really had got the bottoming-float code wrong, again. The new story is explained in Note [Bottoming floats], esp item (3), and Note [Floating from a RHS]. I didn't make a regression test; it's hard to to so. Nofib result are good -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- banner -2.2% -4.6% 0.00 0.00 +0.0% bspt -1.3% -1.6% 0.01 0.01 +0.0% cacheprof -1.8% -0.3% +3.7% +3.7% -0.9% digits-of-e2 -1.0% -1.5% -0.5% -0.5% +0.0% expert -1.3% -0.2% 0.00 0.00 +0.0% n-body -1.1% -0.2% +0.1% +0.1% +0.0% veritas -2.9% -0.1% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -2.9% -4.6% -7.4% -7.4% -19.8% Max -1.0% +0.0% +5.2% +5.1% +10.0% Geometric Mean -1.2% -0.1% +0.5% +0.5% -0.1% I /think/ all this is due to this error-floating change; but it's possible that some was due to commit "Fix CSE (again) on literal strings" a couple of commits earlier. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:23:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:23:52 -0000 Subject: [GHC] #13369: Float-out is not idempotent In-Reply-To: <046.634bbbfff77b021b9c4e1a0c9964fad2@haskell.org> References: <046.634bbbfff77b021b9c4e1a0c9964fad2@haskell.org> Message-ID: <061.e98ecddde0f0161719433719fc245cb5@haskell.org> #13369: Float-out is not idempotent -------------------------------------+------------------------------------- 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 Mon Mar 6 15:23:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:23:24 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.2c05e03fbe1b56c1894ec0903e081a2e@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): angerman has a patch implementing 1 at Phab:D3287. We should actually be able to implement 2 by generating symbols that point to the start of info tables with some inline assembly (http://llvm.org/docs/LangRef.html#module-level-inline-assembly) {{{ module asm ".set foo_info_start, foo - 12" module asm ".global foo_info_start" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:24:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:24:58 -0000 Subject: [GHC] #13367: CSE not working for top-level literal strings In-Reply-To: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> References: <046.74c8fe18b502e44e6574c25bf4704ba4@haskell.org> Message-ID: <061.6db84f3b5f3284e622a0419edcea7075@haskell.org> #13367: CSE not working for top-level literal strings -------------------------------------+------------------------------------- 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: | simplCore/should_compile/T13367 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T13367 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:25:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:25:45 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.e70f13512a663ed99a4f7aec07eac22b@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK done {{{ commit 9304df5230a7a29d3e992916d133e462b854e55f Author: Simon Peyton Jones Date: Fri Mar 3 11:00:04 2017 +0000 Fix CSE (again) on literal strings Fixes Trac #13367. See Note [Take care with literal strings] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:32:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:32:21 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.5bf3e42c9ad2c5968b3e953c05cc1fa9@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 RyanGlScott): Two more thoughts to consider. One: how should this interact with your feature request in #13117? That is, you had previously requested that if you wrote this: {{{#!hs data V a deriving Functor }}} then GHC should generate this: {{{#!hs instance Functor V where fmap _ x = case x of {} }}} But `V`'s type parameter is phantom here, so you could just as well implement it like this (as Eric Mertens originally pointed out in https://mail.haskell.org/pipermail/libraries/2017-January/027603.html): {{{#!hs instance Functor V where fmap _ = coerce }}} Which choice should we make here? Two (a follow-up question to comment:1, after reading Eric's comment about role annotations in https://mail.haskell.org/pipermail/libraries/2017-January/027603.html): consider this code: {{{#!hs data Foo a = Foo deriving instance Foldable Foo }}} In this scenario, the type parameter to `Foo` is phantom, so the generated `Foldable` instance is: {{{#!hs instance Foldable Foo where foldMap _ _ = mempty }}} Now what happens if you add a role annotation to `Foo`? {{{#!hs type role Foo nominal data Foo a = Foo deriving instance Foldable Foo }}} Now, since `Foo`'s type parameter is no longer phantom, the generated `Foldable` instance will be: {{{#!hs instance Foldable Foo where foldMap _ Foo = mempty }}} That is to say, the choice of role can affect what the strictness of `foldMap` will be. Is this desirable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 15:58:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 15:58:16 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.755c5df2ed3ea41b3dffca721fb38bbd@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Or better, use `.no_dead_strip` rather than `.global`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 18:38:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 18:38:41 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.7bce33fb5934bd0506e42fbbb40007a1@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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): Phab:D3257 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8ca4bb1ce9d94bb9f519f620c1f5ed8063007d33/ghc" 8ca4bb1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ca4bb1ce9d94bb9f519f620c1f5ed8063007d33" Read COMPLETE sets from external packages Currently, `COMPLETE` pragmas are not read from external packages at all, which quite limits their usefulness. This extends `ExternalPackageState` to include `COMPLETE` sets from other packages, and plumbs around the appropriate values to make it work the way you'd expect it to. Requires a `binary` submodule update. Fixes #13350. Test Plan: make test TEST=T13350 Reviewers: rwbarton, mpickering, austin, simonpj, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3257 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 19:13:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 19:13:29 -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.12adced7c6a57d5b15be74c0ecfcbd82@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 not too surprised this is a difficult case. `>>` is `infixl`. So we start with `(((f bs >> f b) >> f bs) >> f bs) >> f bs` and we end up (eventually) re-associating everything the other way. How did an example like this arise in practice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 19:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 19:21:28 -0000 Subject: [GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c In-Reply-To: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> References: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> Message-ID: <059.1ab532ef66d3db6d62fbc55c1315cc5e@haskell.org> #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c -------------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by Phyx-): * status: upstream => new Comment: It seems that the issue is not GCC, but the trigger does still not fire in GHC for some reason. Need to investigate further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 19:35:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 19:35:54 -0000 Subject: [GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions In-Reply-To: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> References: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> Message-ID: <063.03648c747d4c56ae8c24a45b57d19a5e@haskell.org> #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- 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: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8668 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This appears to be fixed in master. See #5835 and #12791. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 19:43:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 19:43:29 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.1a2c11fd41b5f4644793669b2a90630c@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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 dfeuer): * priority: normal => high * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:10:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:10:15 -0000 Subject: [GHC] #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.a90c53e1db784fb65731efcda1562671@haskell.org> #13027: The let/app invariant, evaluated-ness, and reallyUnsafePtrEquality# -------------------------------------+------------------------------------- Reporter: erikd | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: #11444 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I believe this should now be resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:14:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:14:42 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.38519d282a929e69e5ff8e3176e68f78@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me like making the modtime check less naive is the right solution here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:16:26 -0000 Subject: [GHC] #13370: exprIsBottom inconsistent with strictness analyser In-Reply-To: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> References: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> Message-ID: <061.2de57748b3707030f9cfbe5a8c9ee76b@haskell.org> #13370: exprIsBottom inconsistent with strictness analyser -------------------------------------+------------------------------------- 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): All this looks to me like a piece of a bigger puzzle we need to solve relating to strictness in the presence of: 1. Imprecise exceptions (which we have a whole paper about) 2. Precise exceptions (which I think we ''don't'' have a good story around at all--see #13380) 3. `catch` and friends. I had a (crazy?) thought last night. This may or may not make any sense at all, but it's driven by the fundamentally simple idea that ''precise'' exceptions should be modeled by something that looks vaguely similar to `ExceptT SomeException (State (State# RealWorld))`, but that fits into the `IO` type we're pretty much stuck with. Right now, `State# RealWorld` is terrifically boring for its entire life. But I don't know if it needs to be. Imagine if we had instead (very, very approximately) {{{#!hs data OK = OK State# RealWorld = (# OK | SomeException #) }}} where the "state of the real world" includes what precise exception (if any) we have encountered. Now we could talk about ''precise'' exceptions in Core in an entirely different fashion: {{{#!hs instance Monad IO where return x = IO $ \s -> (# s, x #) -- If the state has become exceptional, then performing additional -- actions is useless. m >>= f = IO $ \s -> case unIO m s of (# (# | e #), _ #) -> (# (# | e #), undefined #) (# s', r #) -> unIO (f r) s' throwIO e = IO $ \s -> (# (# | e #), undefined #) -- Function for catching only precise exceptions catchIO m f = IO $ \s -> case unIO m s of (# (# | e #), _ #) -> unIO (f e) realWorld# }}} Then `seq#` could take on the "magical" job of turning imprecise exceptions into precise ones, allowing us to implement `catch`. {{{#!hs catch# m f s = case seq# (m s) of (# (# | e #), _ #) -> f e realWorld# --Imprecise exception executing (m s) (# _, (# (# | e #), _ #) #) -> f e realWorld# --Precise exception executing (m s) (# _, res #) -> res }}} We'd need to perform some sort of magic in code generation to get rid of this wacky `State#` and implement exceptions in the usual fashion (I have no idea what that would look like myself). But in Core, I think we'd greatly confine the weirdness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:18:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:18:22 -0000 Subject: [GHC] #13370: exprIsBottom inconsistent with strictness analyser In-Reply-To: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> References: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> Message-ID: <061.81a3a394300161017ef72f64726cc2dc@haskell.org> #13370: exprIsBottom inconsistent with strictness analyser -------------------------------------+------------------------------------- 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 Mon Mar 6 20:23:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:23:40 -0000 Subject: [GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.63fad9300c1fae9fff2870e01993efee@haskell.org> #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:26:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:26:35 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.19967196b4311cebfa2f1d680f87e3ab@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc 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 dfeuer): * failure: None/Unknown => Runtime performance bug * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:41:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:41:34 -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.955e8a2bcfd7d39e13c69e6b0518fd9a@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 jberryman): > How did an example like this arise in practice? In attempting to space profile some code where there seemed to be a constant small amount of allocation at each call site I tried creating a file like this one. I filed the bug because it seemed likely that this was evidence of performance issues in more realistic code. > I'm not too surprised this is a difficult case ... we end up (eventually) re-associating everything the other way Ah, interesting! This does seem to be related to `(>>)` and not the code I marked `INLINE` in the Main file. The code compiles quickly with: {{{ import Prelude hiding ((>>)) import qualified Prelude as P infixr 1 >> {-# NOINLINE (>>) #-} (>>) = (P.>>) }}} The NOINLINE is necessary, and we see `f` get inlined everywhere. But my naive response, knowing nothing about how to implement an inliner, and looking at a 191kb core file with a bunch of nested: {{{ of _ [Occ=Dead] { (# ipv, ipv1 #) -> case hPutStr2 stdout ipv1 True ipv of _ [Occ=Dead] { (# ipv2, ipv3 #) -> case hPutStr2 stdout ipv1 True ipv2 of _ [Occ=Dead] { (# ipv4, ipv5 #) -> case hPutStr2 stdout ipv1 True ipv4 of _ [Occ=Dead] { (# ipv6, ipv7 #) -> case hPutStr2 stdout ipv1 True ipv6 ... }}} ...is that I could do this inlining case manually in milliseconds (vs ~40 seconds for whatever number of lines I was just testing with) with vim, sed, a bash script, etc. and without GB of memory for my working set. And so I am inclined to believe that there is a space leak here. Who knows if real code will benefit from fixing it though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:43:23 -0000 Subject: [GHC] #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions In-Reply-To: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> References: <048.eb8da202bb2996fcfeb70c826114f591@haskell.org> Message-ID: <063.e238ce6e4a331b53b541bdd25f21b84a@haskell.org> #13376: GHC fails to specialize a pair of polymorphic INLINABLE functions -------------------------------------+------------------------------------- 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: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8668, #5835, | Differential Rev(s): #12791 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: #8668 => #8668, #5835, #12791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 20:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 20:44:02 -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.976d831bceb9851dc654324b08fb4be5@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 jberryman): These seem to be the slow inlinings which we don't see in the `infixr` variation I posted: {{{ Inlining done: System.IO.putStrLn1 Inlining done: GHC.IO.Handle.Text.hPutStrLn1 Inlining done: GHC.Base.thenIO1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 21:04:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 21:04:26 -0000 Subject: [GHC] #13141: Don't check for Perl in ./configure when not splitting objects In-Reply-To: <047.a2722241ec56f4afc6afd14ced53477d@haskell.org> References: <047.a2722241ec56f4afc6afd14ced53477d@haskell.org> Message-ID: <062.9708999a518619e69d54526386bc66b0@haskell.org> #13141: Don't check for Perl in ./configure when not splitting objects -------------------------------------+------------------------------------- Reporter: dobenour | Owner: dobenour Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It looks like this has been resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 21:23:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 21:23:28 -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.69ce9ef026b64a90b1db303faef4e56a@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 dfeuer): * cc: dfeuer (added) Comment: If the `NOINLINE` is necessary, then I think I must be quite wrong about the source of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 21:32:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 21:32:28 -0000 Subject: [GHC] #13364: Remove checkValidTelescope In-Reply-To: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> References: <047.3f3b61edc31539fbdbe5a670e9376e58@haskell.org> Message-ID: <062.91e9e39df2bfd62783594004bd92b69a@haskell.org> #13364: Remove checkValidTelescope -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.4.1 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 dfeuer): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 21:36:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 21:36:03 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.c6a4d71ee309722d88fe5a413c69dcd5@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | 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 dfeuer): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 21:55:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 21:55:25 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 Message-ID: <046.609524b4d023b0557873a020ac7b7847@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- 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: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of 749740f9c3cb25ee95e04a21c1ef73e1bf96afb1, {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20170306: http://www.haskell.org/ghc/ :? for help Prelude> sqrt (-1) :: Double -1.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:02:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:02:02 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.31f78f7d85d216d04c7b4999feeed500@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ummmm.... {{{ ben at schildmann MINGW64 ~/ghc$ hi.c #include #include void main() { printf("%f\n", sqrt(-1)); } ben at schildmann MINGW64 ~/ghc$ gcc hi.c -O0 ben at schildmann MINGW64 ~/ghc$ ./a.exe -1.000000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:04:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:04:56 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.52e7329154aafd45ccde165d97e1c048@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is relevant: https://sourceforge.net/p/mingw/bugs/2337/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:07:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:07:30 -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.167a9ae323574566d7f8237a944a52a7@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 mpickering): I think that the problem is that `>>` and then `thenIO` gets inlined which in this case causes the compiler to generate heaps of code to simplify. I tried using `Identity` and it compiled instantly. It seems plausible that that this shouldn't take a long time but more investigation into what exactly is taking a long time is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:08:43 -0000 Subject: [GHC] #13385: ghci fails to start when -XRebindableSyntax is passed Message-ID: <046.49534d46a543f72893ed665a08de1bb0@haskell.org> #13385: ghci fails to start when -XRebindableSyntax is passed -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Running "ghci -XRebindableSyntax" yields the following output: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help :1:6: error: Not in scope: ‘>>’ :1:70: error: Not in scope: ‘>>’ :1:135: error: Not in scope: ‘return’ }}} This appears to be a regression, as it does not occur with ghc-7.10.3. Originally reported as a stack issue by Michal Konecny - https://github.com/commercialhaskell/stack/issues/3043 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:10:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:10:54 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.a504bcf68e37d320a57a319a0c8b3ea6@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:26:23 -0000 Subject: [GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals In-Reply-To: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> References: <047.3e0304e938f8544e8155e6db1481b408@haskell.org> Message-ID: <062.a1b9a60628e01facf5095efd808544b5@haskell.org> #13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick Type: feature request | 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: | deSugar/should_compile/T13257 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3281 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3fdabe9873e311571f614d455d1b16bc3f4fdc0f/ghc" 3fdabe98/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3fdabe9873e311571f614d455d1b16bc3f4fdc0f" Changed OverLit warnings to work with negative literals (#13257) Test Plan: Validate, check generated warnings Reviewers: austin, bgamari, dfeuer Reviewed By: bgamari, dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3281 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:26:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:26:24 -0000 Subject: [GHC] #11076: Demand information of foreign calls is wrong In-Reply-To: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> References: <044.34bd2569f92bdaaaa2887dd523555186@haskell.org> Message-ID: <059.c2ddc4f8b05073a4afdd4e7174e550c3@haskell.org> #11076: Demand information of foreign calls is wrong -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"494907f89d129370ec5ab178cec860a64b456ac8/ghc" 494907f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="494907f89d129370ec5ab178cec860a64b456ac8" testsuite: Add test for #11076 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:26:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:26:24 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern In-Reply-To: <047.984d4241873e1562c305a37585f1b95c@haskell.org> References: <047.984d4241873e1562c305a37585f1b95c@haskell.org> Message-ID: <062.e9f30d87e426e022600fdd670bee6a76@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick 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: | parser/should_fail/T13260 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3286 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6177c0d8bdc6f5c0675b2eace592620abb658787/ghc" 6177c0d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6177c0d8bdc6f5c0675b2eace592620abb658787" Disallow unboxed string literals in patterns (#13260) Signed-off-by: Rupert Horlick Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3286 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:26:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:26:24 -0000 Subject: [GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note In-Reply-To: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> References: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> Message-ID: <060.44726c84a6942b2346036b65144a91b0@haskell.org> #13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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:"18312086a48c90b22583c81fdb7bd2d7bfd38991/ghc" 18312086/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18312086a48c90b22583c81fdb7bd2d7bfd38991" base: Kill out-of-date Notes These were rendered out-of-date by D1103. Resolves #13174. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:26:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:26:46 -0000 Subject: [GHC] #13260: panic on unboxed string literal in pattern In-Reply-To: <047.984d4241873e1562c305a37585f1b95c@haskell.org> References: <047.984d4241873e1562c305a37585f1b95c@haskell.org> Message-ID: <062.a7400317bdbdef6bd36b13b49068b559@haskell.org> #13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ruperthorlick Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T13260 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3286 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 Mon Mar 6 22:26:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:26:54 -0000 Subject: [GHC] #13174: Fix mismatch between unsafeDupablePerformIO and note In-Reply-To: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> References: <045.73f7102f83f6e244f51cbad5d4ef6298@haskell.org> Message-ID: <060.f38ccbb530d7b0f4145dc0cb32a197df@haskell.org> #13174: Fix mismatch between unsafeDupablePerformIO and note -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:53:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:53:20 -0000 Subject: [GHC] #13350: COMPLETE sets aren't read from external packages In-Reply-To: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> References: <050.f87ee6dfd90d7f08113d1c686252d2d1@haskell.org> Message-ID: <065.33617c50049b2d4b5bea67995f0f3600@haskell.org> #13350: COMPLETE sets aren't read from external packages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | testsuite/tests/patsyn/should_compile/T13350 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => testsuite/tests/patsyn/should_compile/T13350 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 22:54:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 22:54:24 -0000 Subject: [GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores In-Reply-To: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> References: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> Message-ID: <060.e0c5fdba9f89058465788f2da69215dd@haskell.org> #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores --------------------------------------------+------------------------------ Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by varosi): Or may be operating systems could have already mechanisms to signal of such changes without pulling them regularly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:15:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:15:11 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.9de28fb4c75a2207e959ef192a65e5f4@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: Operating System: 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): So, in my head, I want to minimize the amount of changes to code necessary to take advantage of call stacks. Adding CallStacks to each of the exception types individually means that you have to modify each exception type to contain a CallStack (so, linear in the number of exception types.) Creating a new `SomeExceptionWithCallStack` means that we have to modify all occurrences of catch-rethrow to preserve call stacks (so, linear in the number of catch-rethrows in code everywhere.) I admit that there is a tradeoff here, but the benefits of `SomeExceptionWithCallStack` don't make sense to me. I imagine there are a lot more catch-rethrows than there are exception types, and you will have to go through and fix each one of them. Admittedly, if you get a call stack that is missing info you need, it shouldn't be hard to track down (since the error will have the call stack of the bad rethrow attached :) Perhaps I am not seeing some other hidden costs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:16:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:16:56 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.14ded057fc786d8ed90e8427ded11da2@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | 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 crockeea: Old description: > With `-XPolyKinds`, GADTs require kind signatures where they should be > inferred. Moreover, the error when these kind sigs are omitted is > baffling. > > {{{ > {-# LANGUAGE PolyKinds, GADTs #-} > > import GHC.TypeLits > > data C > (x :: k) > a > where > C1 :: (KnownNat x) => a -> Foo x a > C2 :: a -> Foo Int a > }}} > > {{{ > error: > • Expected kind ‘k’, but ‘x1’ has kind ‘Nat’ > • In the first argument of ‘Foo’, namely ‘x’ > In the type ‘Foo x a’ > In the definition of data constructor ‘C1’ > }}} > > From this error, I would never expect that putting a kind signature on > `a` would help here. But a signature shouldn't be required at all: it's > clear from the GADT constructors that `a :: *`. New description: With `-XPolyKinds`, GADTs require kind signatures where they should be inferred. Moreover, the error when these kind sigs are omitted is baffling. {{{ {-# LANGUAGE PolyKinds, GADTs #-} import GHC.TypeLits data Foo (x :: k) a where C1 :: (KnownNat x) => a -> Foo x a C2 :: a -> Foo Int a }}} {{{ error: • Expected kind ‘k’, but ‘x1’ has kind ‘Nat’ • In the first argument of ‘Foo’, namely ‘x’ In the type ‘Foo x a’ In the definition of data constructor ‘C1’ }}} From this error, I would never expect that putting a kind signature on `a` would help here. But a signature shouldn't be required at all: it's clear from the GADT constructors that `a :: *`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:27:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:27:50 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.c321a14f7973a4752ab00a3839a13bdc@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: Operating System: 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): Sounds like you are comparing the costs of 1) adding CallStacks to individual exception types vs 2) fixing call-rethrow occurrences to use the `...WithCallStack` variants. And concluding that the cost of 2) is higher, therefore `SomeExceptionWithCallStack` is a more expensive solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:29:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:29:51 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.5f5134e53c84021151d2b4be4b2770dc@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: Operating System: 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): But surely if we had `SomeExceptionWithCallStack` then both 1) and 2) are available options, they are not mutually exclusive, right ? You could choose to apply 1) to IOError and leave the other exception types untouched, applying 2) where viable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:33:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:33:44 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.a9085f157dd9cddc26a316d6b7456a0e@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: Operating System: 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 benefit of `SomeExceptionWithCallStack` is that *all* exceptions carry call stacks. Library code could print call stacks on uncaught exception errors regardless of whether the exception type is an instance of SomeExceptionWithCallStack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:41:51 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.154e5180439be399d503b1a9259fb631@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ThreeFx Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ThreeFx): * owner: (none) => ThreeFx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:43:34 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.4f34ff84a4275afbe3cf92cafa72b483@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: Operating System: 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): After thinking a bit more about it, I've realised why the `SomeExceptionWithCallStack` approach doesn't work well with the per- Exception type CallStacks: we end up with two CalltStacks stored in the same exception. Now I understand why C# and F# have special primitives for `rethhrow` .... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:51:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:51:35 -0000 Subject: [GHC] #13130: atomicModifyMutVar# has incorrect type In-Reply-To: <045.780a635d79815aa0591355968d4537c8@haskell.org> References: <045.780a635d79815aa0591355968d4537c8@haskell.org> Message-ID: <060.82e7b4af2d161f9baadcec61c459f77b@haskell.org> #13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d91b10458885aede47ff17fa649b2c0fd9fdf3ca/ghc" d91b104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d91b10458885aede47ff17fa649b2c0fd9fdf3ca" primops: Add comment describing type of atomicModifyMutVar# This resolves #13130. It's not entirely clear to me why we don't use an unboxed tuple here but this is at least better than the status quo. [skip ci] Test Plan: Read it Reviewers: simonmar, austin, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3288 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:52:22 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.5d03ef127882e64317fc6cb5b492d0c7@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: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): @ezyang are you sure that there are that many explicit catch-rethrows in Haskell code? We certainly have tools (e.g. `catches` and `catchJust`) to avoid having to explicitly rethrow exceptions. And it would be much less work to add the `CallStack` to `SomeException` and update `Control.Exception` '''if''' `catchJust` and co are actually used. Seems like something we could investigate on Hackage before making a decision :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 6 23:56:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Mar 2017 23:56:36 -0000 Subject: [GHC] #13344: Core string literal patch regresses compiler performance considerably In-Reply-To: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> References: <046.9889ddd58f4ff9c7b2c7850e1cbd5ad0@haskell.org> Message-ID: <061.bb6f351ae84f037a4f8e89bd2aaf7a9f@haskell.org> #13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: As perhaps expected, the above commit sped up the build by 20 seconds: https://perf.haskell.org/ghc/#revision/9304df5230a7a29d3e992916d133e462b854e55f (click the "=" at the top right to see the build time) which means that we've accounted for the regressions from the top-level strings patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 00:00:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 00:00:02 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.33cc4efadff4aaed224c47343c1825d1@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: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I know that `catchIO` and then `throwIO` if the `IOError` does not match a predicate is a common idiom. It's somewhat difficult to regex for them but if you grep for `throwIO` with a reference to a variable, there are tons and tons of them. Here are three random ones I picked out: {{{ -- system-fileio removeTree root = do items <- listDirectory root forM_ items $ \item -> Exc.catch (removeFile item) (\exc -> do isDir <- isRealDir item if isDir then removeTree item else Exc.throwIO (exc :: IOError)) -- HsSVN do err <- wrapSvnError =<< _fs_commit_txn conflictPathPtrPtr reposPtr newRevPtr txnPtr poolPtr case err of Nothing -> liftM (Right . fromIntegral) (peek newRevPtr) Just e -> if svnErrCode e == FsConflict then return . Left =<< peekCString =<< peek conflictPathPtrPtr else throwIO e -- DPM (Darcs.Lock.withLock fname (writeIORef ref True >> io)) `catch` (\ (e::SomeException) -> do b <- readIORef ref if b then throwIO e else failIO ("Could not obtain lock " ++ show fname ++ ", aborting.")) }}} I just grepped for `throwIO` and picked out three random examples that looked like they were rethrowing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 00:05:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 00:05:06 -0000 Subject: [GHC] #13349: Make GHC handle orphan COMPLETE sets of conlikes better In-Reply-To: <050.1ed46c9c098322461a08260277adee24@haskell.org> References: <050.1ed46c9c098322461a08260277adee24@haskell.org> Message-ID: <065.c2e108868e1a4c30a79c4b5a3c60eca9@haskell.org> #13349: Make GHC handle orphan COMPLETE sets of conlikes better -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3243 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 00:06:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 00:06:24 -0000 Subject: [GHC] #13338: New versions of time and Cabal are causing a Core Lint error on Windows In-Reply-To: <047.4049513ac602284cecca46022b61971a@haskell.org> References: <047.4049513ac602284cecca46022b61971a@haskell.org> Message-ID: <062.87010b9dfcc5f42888c926599e225183@haskell.org> #13338: New versions of time and Cabal are causing a Core Lint error on Windows -------------------------------------+------------------------------------- Reporter: rwbarton | 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: None/Unknown | Test Case: | simplCore/should_compile/T13338 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3217 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 00:40:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 00:40:44 -0000 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size In-Reply-To: <045.907bdf02870cf9d7a457cb5fba873bca@haskell.org> References: <045.907bdf02870cf9d7a457cb5fba873bca@haskell.org> Message-ID: <060.ffd72318c2fbc562174053e74ac671ed@haskell.org> #3094: Some GHC.* module should export word size and heap object header size -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries | Version: 6.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 6.12.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 00:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 00:42:25 -0000 Subject: [GHC] #5611: Asynchronous exception discarded after safe FFI call In-Reply-To: <048.a1f4840a208dec01f4783b6a8911d995@haskell.org> References: <048.a1f4840a208dec01f4783b6a8911d995@haskell.org> Message-ID: <063.fd7e8d7bf48f30890f225a665bcd7d85@haskell.org> #5611: Asynchronous exception discarded after safe FFI call -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.0.3 Resolution: | Keywords: FFI, | exception 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): * milestone: 7.2.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:10:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:10:25 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.1064618f0af19a4ec31d23f2a1cf4cbe@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 RyanGlScott): There's one more scenario that this proposed change would wreak havoc with. It's quite possible for users to define unlawful `Functor` instances and depend on them in other derived `Functor` instances: {{{#!hs newtype Unlawful a = Unlawful Int instance Functor Unlawful where fmap f (Unlawful i) = Unlawful (i + 1) newtype WrapUnlawful a = WrapUnlawful (Unlawful a) deriving Functor }}} But under this proposal, the generated `Functor` instance for `WrapUnlawful` would be: {{{#!hs instance Functor WrapUnlawful where fmap _ = coerce }}} This would be another departure in behavior, as now `fmap`ping over a `WrapUnlawful` wouldn't apply `(+1)` to the field of the `Unlawful` (icky as it may be). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:22:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:22:55 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.957a8cb3043c399b4387b2fbad0c8658@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 dfeuer): The question about `fmap` strictness looks like a red herring to me. There's no real difference between the empty case definition and the `coerce` definition. The illegitimate `fmap` is of very little interest to me. Someone who cares about preserving their map count or whatever just won't be able to use `Functor` deriving for types explicitly mentioning their bogus one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:32:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:32:21 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.a2a0c8211f421a65826401ec72bf13ed@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 RyanGlScott): > The question about `fmap` strictness looks like a red herring to me. There's no real difference between the empty case definition and the `coerce` definition. Sure, I just wanted to note the "conflict". > The illegitimate `fmap` is of very little interest to me. Someone who cares about preserving their map count or whatever just won't be able to use `Functor` deriving for types explicitly mentioning their bogus one. That's also fine, just make sure we note this if this gets implemented. Luckily, `Functor`/`Foldable`/`Traversable` happen to be pretty rigid, law-abiding classes, so this restriction won't really hurt anyone in practice. What is your opinion on the `RoleAnnotations` example above? This is the only thing that genuinely concerns me, since I think having the strictness of a derived `Foldable` instance change depending on whether a type parameter is phantom or non-phantom is quite unintuitive. I'm not sure of a good workaround, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:36:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:36:02 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.cef17042143241fcc01739b3dabddf57@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.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 dfeuer): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:36:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:36:54 -0000 Subject: [GHC] #5611: Asynchronous exception discarded after safe FFI call In-Reply-To: <048.a1f4840a208dec01f4783b6a8911d995@haskell.org> References: <048.a1f4840a208dec01f4783b6a8911d995@haskell.org> Message-ID: <063.054fe96ac96d2da7f622babcf1ccec22@haskell.org> #5611: Asynchronous exception discarded after safe FFI call -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.0.3 Resolution: | Keywords: FFI, | exception, Exceptions 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): * keywords: FFI, exception => FFI, exception, Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:51:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:51:54 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.f29b5a8d2e8982cd2c32590b535668bf@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 dfeuer): The role annotation should (I believe) only affect instances derived outside the module. So I believe the concern would be for a type that is defined ''using'' a type defined in another module that has a role annotation. But again, that matches the "what the user would likely write by hand" scenario: we can only do as well as the user could. Yes, it's true that this introduces some potential for surprises; the user won't get a nice error message when they make the change. Do you think this is a judgement call that should be made through the proposal process? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:58:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:58:11 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.7f55a1a21af7cebdbe40a47a8bd7a5a3@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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 01:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 01:59:36 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.a7f50efce4f99e95f3a12666257b9627@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | 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): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 02:01:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 02:01:20 -0000 Subject: [GHC] #13370: exprIsBottom inconsistent with strictness analyser In-Reply-To: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> References: <046.45e6c52c5ad70071bfd0672a8992864e@haskell.org> Message-ID: <061.ecd7dd4d7429bb2ebf7d6629ba06f14e@haskell.org> #13370: exprIsBottom inconsistent with strictness analyser -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 02:07:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 02:07:22 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.69e5ee07c1f0e97ea259c5d5ee45a6bc@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 bgamari): For what it's worth, I've collected some rather related thoughts (but in reference to DWARF stack traces) on wiki:Exceptions/StackTraces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 02:11:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 02:11:00 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.396068c5eaa25b72d687a44c5a05c36b@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 RyanGlScott): Sadly, a role annotation would affect the datatype even in the module in which it is originally defined: {{{#!hs {-# LANGUAGE RoleAnnotations, TemplateHaskell #-} import Language.Haskell.TH type role Foo nominal data Foo a = Foo a $(return []) main :: IO () main = putStrLn $(reifyRoles ''Foo >>= stringE . show) }}} {{{ $ runghc Bug.hs [NominalR] }}} The issue is really that role annotations are only a crude approximation of the property we actually want here. For `Functor` and `Traversable`, we really are using `coerce`, so a phantom role annotation is precisely what you need. But we aren't using `coerce` in the proposed `Foldable` instance, and moreover, the property we really want to ensure is that the type parameter doesn't appear anywhere in any constructor's fields. Sadly, a phantom role does not always imply this. I'm tempted to suggest a workaround in which we re-infer the roles for every data type, but this time, we ignore all user-supplied role annotations. That way, we would get precisely the right information about whether the last type parameter appears somewhere in the datatype's definition. But sadly, this would necessarily break abstraction in the case where a constructor's field mentions an abstract type that has been given a role annotation of representational or nominal. Another option we could choose is to simply skip over this optimization for `Foldable`. That's likely not what you'd prefer, but there are a number of properties which make dealing with `Foldable` awkward that aren't present with `Functor` and `Traversable`. In any event, presenting this idea via a proposal would certainly be a good thing. I'm curious to know what others think about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 02:21:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 02:21:14 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.7540e294c14defbd1d1dd446a3aeed27@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 dfeuer): You're right that the role is only an approximation for `Foldable`, but using that approximation has an important advantage: it ensures that deriving `foldMap` will never be worse than using `foldMapDefault` with a derived `Traversable` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 02:32:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 02:32:58 -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.0b24c6c3f61047b384d8abb8370d8757@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): [[https://perf.haskell.org/ghc/#revision/6bab649bde653f13c15eba30d5007bef4a9a9d3a|Gipeda]] suggests that the patch didn't have much of an effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 02:58:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 02:58:54 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.d73a0c44eb6013ef0c670f8d7625dca6@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): Thanks for the pointer bgamari. It looks like your proposal is essentially the same initially specified in this ticket. Your wiki page does comment that call stacks are preserved if you rethrow SomeException. But this often doesn't happen in practice. For example, the `system-fileio` example above rethrows an `IOError`: oops, call stack lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 03:19:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 03:19:59 -0000 Subject: [GHC] #13330: forkIO has inconsistent behavior under optimization In-Reply-To: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> References: <045.f03dc5d6a1e9bd1b806718c8b2822920@haskell.org> Message-ID: <060.efa485b55ebf50cbd1c67a852842a4c7@haskell.org> #13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3189 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This was fixed by 701256df88c61a2eee4cf00a59e61ef76a57b4b4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 03:42:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 03:42:13 -0000 Subject: [GHC] #13130: atomicModifyMutVar# has incorrect type In-Reply-To: <045.780a635d79815aa0591355968d4537c8@haskell.org> References: <045.780a635d79815aa0591355968d4537c8@haskell.org> Message-ID: <060.fe8b0188c902401f70707dc9385551ee@haskell.org> #13130: atomicModifyMutVar# has incorrect type -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 04:20:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 04:20:08 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.5f49e88d20aacef036d6b6d678ba2d35@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 RyanGlScott): One way we could help mitigate the effect of this is by doing an additional optimization for derived `Foldable` instances. First, we check each constructor, and if it does not contain an occurrence of the last type parameter, we filter out that constructor. Then we generate the `foldMap` cases as normal for fhe constructors that remain, and if any constructors were filtered out, we generate a catch-all `foldMap _ _ = mempty` case at the end. This should at least help in the case when all the data constructors of a phantom type are in scope, but its role has been annotated as something other than phantom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 07:02:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 07:02:21 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.85b8c09610aa2b3b1acb57562365df8b@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- Comment: I'll get you a patched version later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 07:03:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 07:03:15 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.291dfa82d6797a5851cf24bfd5d3f21e@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: upstream Priority: highest | Milestone: 8.2.1 Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 08:15:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 08:15:30 -0000 Subject: [GHC] #13386: Poor compiler performance with type families Message-ID: <049.c62ef75e26f3d606baae71cbfbd84e45@haskell.org> #13386: Poor compiler performance with type families -------------------------------------+------------------------------------- Reporter: adamgundry | 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 | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs {-# LANGUAGE DataKinds, TypeApplications, TypeFamilies, TypeOperators, UndecidableInstances #-} {-# OPTIONS_GHC -freduction-depth=0 #-} module TypeFamilyPerf where import GHC.TypeLits type DivisibleBy x y = Help x y 0 (CmpNat x 0) type family Help x y z b where Help x y z EQ = True Help x y z LT = False Help x y z GT = Help x y (z+y) (CmpNat x z) foo :: DivisibleBy y 3 ~ True => proxy y -> () foo _ = () type N = 1002 k = foo @N undefined }}} On my machine `ghc-8.0.2 -O0` takes 4-5s to compile this module, with the time increasing as `N` increases (but note that it must be a multiple of 3, otherwise typechecking fails quickly). The problem seems to be that desugaring creates an enormous number of coercions in the representation of `k`. Perhaps this isn't terribly surprising, but I think we can do better. It should be possible to represent a proof of `DivisibleBy 1002 3 ~ True` compactly: the only information required should be the LHS and the number of reduction steps to take (and perhaps caching the RHS might be worthwhile). {{{ [1 of 1] Compiling TypeFamilyPerf ( TypeFamilyPerf.hs, TypeFamilyPerf.o ) *** Parser [TypeFamilyPerf]: !!! Parser [TypeFamilyPerf]: finished in 0.50 milliseconds, allocated 0.655 megabytes *** Renamer/typechecker [TypeFamilyPerf]: !!! Renamer/typechecker [TypeFamilyPerf]: finished in 91.70 milliseconds, allocated 58.617 megabytes *** Desugar [TypeFamilyPerf]: Result size of Desugar (after optimization) = {terms: 44, types: 70, coercions: 6,058} !!! Desugar [TypeFamilyPerf]: finished in 3781.83 milliseconds, allocated 8775.375 megabytes *** Simplifier [TypeFamilyPerf]: Result size of Simplifier iteration=1 = {terms: 27, types: 62, coercions: 6,060} Result size of Simplifier = {terms: 27, types: 62, coercions: 6,053} !!! Simplifier [TypeFamilyPerf]: finished in 42.93 milliseconds, allocated 68.321 megabytes *** CoreTidy [TypeFamilyPerf]: Result size of Tidy Core = {terms: 27, types: 62, coercions: 6,053} !!! CoreTidy [TypeFamilyPerf]: finished in 0.52 milliseconds, allocated 0.766 megabytes Created temporary directory: /tmp/ghc5526_0 *** CorePrep [TypeFamilyPerf]: Result size of CorePrep = {terms: 32, types: 74, coercions: 6,053} !!! CorePrep [TypeFamilyPerf]: finished in 0.37 milliseconds, allocated 0.160 megabytes *** Stg2Stg: *** CodeGen [TypeFamilyPerf]: !!! CodeGen [TypeFamilyPerf]: finished in 0.00 milliseconds, allocated 1.310 megabytes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 08:43:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 08:43:29 -0000 Subject: [GHC] #13387: Segfault when profiling on OS X Message-ID: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> #13387: Segfault when profiling on OS X -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I built a profiled version of GHC using the `prof` flavour. Then attempting to profile some programs with this executable causes segfaults reliably. 1. Build GHC with the `prof` flavour 2. inplace/bin/ghc-stage2 Main.hs -O2 -fforce-recomp +RTS -p -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 08:43:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 08:43:42 -0000 Subject: [GHC] #13387: Segfault when profiling on OS X In-Reply-To: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> References: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> Message-ID: <064.67e96f3d5fcb6fd84f7ba316e626622b@haskell.org> #13387: Segfault when profiling on OS X -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: 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): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 09:50:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 09:50:00 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.21b7fef1586e4942771948ff1a6ebb5f@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: upstream Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 10:36:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 10:36:59 -0000 Subject: [GHC] #13386: Poor compiler performance with type families In-Reply-To: <049.c62ef75e26f3d606baae71cbfbd84e45@haskell.org> References: <049.c62ef75e26f3d606baae71cbfbd84e45@haskell.org> Message-ID: <064.bbb6cf7fe1210c30a7e8821ac0d11e67@haskell.org> #13386: Poor compiler performance with type families -------------------------------------+------------------------------------- Reporter: adamgundry | 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 performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #8095 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 12:45:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 12:45:15 -0000 Subject: [GHC] #11006: Warning: Glomming in Main In-Reply-To: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> References: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> Message-ID: <060.c3b341b51481fbb83039bbc007bad5ab@haskell.org> #11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ThreeFx): Shouldn't the `expectFail` test annotation be deleted in that case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 13:19:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 13:19:15 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.47d3e9ac9bbadf5116b926dbd1477524@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): When compiling with avx, e.g. `-mavx2`, we already add `-stack- alignment=32` to the `llc` invocation. This begs the question if we need (2) anymore after all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 13:33:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 13:33:20 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.eef178293efe1c9ab7582bf5bfde6c87@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: gmainland (added) Comment: This was added already in 2013. afdb2fc3d2013ced6c136853f4e24e84b6f150e9 \\ Author: Geoffrey Mainland \\ AuthorDate: Thu Feb 14 21:25:54 2013 +0000 \\ Commit: Geoffrey Mainland \\ CommitDate: Sun Sep 22 22:33:59 2013 -0400 **Set LLVM option -stack-alignment=32 when compiling AVX instructions.** ---- Then mangler code however was created earlier in 2011. f8c51678b0e60aad8ee1e4c57af746fa792a3546\\ Author: Geoffrey Mainland \\ AuthorDate: Sat Nov 26 12:45:23 2011 +0000\\ Commit: Geoffrey Mainland \\ CommitDate: Sun Sep 22 22:33:59 2013 -0400 **Fixup stack spills when generating AVX instructions.** LLVM uses aligned AVX moves to spill values onto the stack, which requires 32-bye aligned stacks. Since the stack in only 16-byte aligned, LLVM inserts extra instructions that munge the stack pointer. This is very very bad for the GHC calling convention, so we tell LLVM to assume the stack is 32-byte aligned. This patch rewrites the spill instructions that LLVM generates so they do not require an aligned stack. ---- Could it be that the Mangler code is some ancient relict? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 14:45:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 14:45:16 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.024c0809b1d707831b3350dfd148bbec@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * differential: => Phab:D3290 Comment: We can actually use `.alt_entry` to prevent the linker from splitting up info tables from the following function bodies. Really this should be done in LLVM but for now we can do it ourselves. This is actually slightly better than what we do in the NCG and we could switch the NCG over to using `.alt_entry` too, provided that `.alt_entry` is supported on a sufficiently wide range of Mac OS versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 14:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 14:50:30 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.5a1a15f67207461e1d7ac62f60245222@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have a fix in Phab:D3289. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 15:40:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 15:40:43 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.07eb1e58d3aa18cbe3fabbef0e7bf7fb@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 ndtimofeev): We can substitute `?callStack` in `catch` from actual value to value from caught exception value. {{{#!hs catch' :: Exception e => IO a -> (HasCallStack => e -> IO a) -> IO a catch' eval handler = eval `catch` \err@(SomeExceptionWithStack stack _) -> let ?callStack = stack in case fromException err of Just ex -> handler ex _ -> throw err }}} Now all `throw` called from `catch` handler will be implicit rethrow. It looks like a ugly hack and required Rank2Types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 15:42:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 15:42:09 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs Message-ID: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I saw this recently, {{{ libraries\Win32\Graphics\Win32\Window.hsc:188:46: error: Not in scope: type constructor or class `Int32' | 188 | cW_USEDEFAULT = fromIntegral (#{const CW_USEDEFAULT} :: Int32) | ^^^^^ }}} Clearly the caret is pointing to the wrong place in the line. Note that the file in question is a `hsc2hs` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 15:57:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 15:57:41 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs In-Reply-To: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> References: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> Message-ID: <061.df205bcf09ab4737a042b64b523a696d@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's an easier way to reproduce this: {{{#!hs module Bug where #define LONG_CONSTANT_NAME 42 lONG_CONSTANT_NAME = #{const LONG_CONSTANT_NAME} :: Int32 }}} {{{ $ hsc2hs Bug.hsc $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive -Wall Bug.hs GHCi, version 8.1.20170303: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hsc:5:28: error: Not in scope: type constructor or class ‘Int32’ | 5 | lONG_CONSTANT_NAME = #{const LONG_CONSTANT_NAME} :: Int32 | ^^^^^ Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 16:02:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 16:02: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.f7e971380195f23a86487a852a156ebd@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 gridaphobe): Actually that's not so bad, it's the same trick we use for `GHC.Stack.withFrozenCallStack`. And this should also give us locations for the rethrows, which sounds like a nice touch to me (e.g. maybe you were expecting the exception to be caught and need to figure out why it was rethrown). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 16:43:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 16:43:18 -0000 Subject: [GHC] #13389: Strange behaviours of memory with GHCi under Windows and Linux Message-ID: <044.d9fe5dc4caec74460d9f31301efea452@haskell.org> #13389: Strange behaviours of memory with GHCi under Windows and Linux -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With Windows : Initially the memory in the computer is at 34% use. I open 30 consoles Windows of GHCi. The memory grows until 70% use. I decided to crash a console with this function {{{ f x = x**6 + f x }}} Suddenly the % of memory fall to around 35%. Then I decided to open 30 others consoles Windows GHCi. The memory grows to 83% use. I crashed a console with the same function and the memory fall to 41%. Then I looked at the task manager and I see 29 process of GHC had a memory between 444K and 356K, and 30 process of GHC had a memory between 34704K and 20160K. I decided to made a crash dump file with a process of GHC with 440K of memory. When the crash dump file begin, the memory of the process grows to 80376K and stay until the dump file stop to write. With Linux : I repeted the same behaviour. Initially the memry had 29% use. After the crash of GHCi the memory fall to 8% use. I looked at the task manager and somes process of GHC had 40Kio and others 8192o. I decided to stop (not to kill) a process of GHC and then to continue it. After that the memory of the process grows to 75Mio.\\ Hope this help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 16:50:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 16:50:10 -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.d4511fd8b36202dc6ab71ca29c94606e@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by ThreeFx): Even with `fno-state-hack` this program succeeds under GHC version 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 17:52:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 17:52:15 -0000 Subject: [GHC] #13387: Segfault when profiling on OS X In-Reply-To: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> References: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> Message-ID: <064.dd6e5c55ac0b4945fa031b1b96db720f@haskell.org> #13387: Segfault when profiling on OS X -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: 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): Adding `-fno-state-hack` causes the segfault to stop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 18:32:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 18:32:43 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.733d15342745840ea64104bf6fada5db@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"30d69f404ba102da94423836f86fbec2fb4adaf9/ghc" 30d69f4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30d69f404ba102da94423836f86fbec2fb4adaf9" ghc-pkg: Consider .conf files when computing package db mtime We can no longer use the mtime of the containing directory since it now contains a lock file in addition to the .cache and .conf files. Fixes #13375. Test Plan: Validate on Windows Reviewers: austin, arybczak Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 18:36:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 18:36:14 -0000 Subject: [GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite In-Reply-To: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> References: <046.d35e33cc232d4f1f3ed5cacd13eb7d85@haskell.org> Message-ID: <061.38919c0444472b2b968b873d744f2ca9@haskell.org> #13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 18:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 18:59:36 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 Message-ID: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Phab:D1259, which teaches the compiler to aggressively float-out string literals during desugaring, regresses compiler allocations on `T1969` by 15% or so at -O0`. = The problem = In the case of `T1969` (compiled with `-O0`) the difference is quite stark: with floating the non-optimizing simplifier pass produces `{terms: 16,893, types: 7,552, coercions: 0, joins: 0/0}`, without it produces `{terms: 12,693, types: 4,552, coercions: 0, joins: 0/0}`. The (minimized) test looks like, {{{#!hs module T1969 where class C a where c :: a -> String d :: a -> String d x = c x e :: a -> String e x = c x data A1 = A1 instance C A1 where c A1 = "A1" }}} == Post-desugar == The reason for the regression is in part due to the fact that we float out the `unpackCString# "An"` expression. That is, after desugaring without floating we get (looking at just the `A1` bindings), {{{#!hs T1969.$dme :: forall a. C a => a -> String T1969.$dme = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM3 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM3 -- same as $dme T1969.$dmd :: forall a. C a => a -> String T1969.$dmd = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM2 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM2 $cc_a1i7 :: A1 -> String $cc_a1i7= \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } Rec { T1969.$fCA3 :: C A3 T1969.$fCA3 = T1969.C:C @ A3 $cc_a1hl $cd_a1hp $ce_a1hy $ce_a1hy :: A3 -> String $ce_a1hy = T1969.$dme @ A3 T1969.$fCA3 $cd_a1hp :: A3 -> String $cd_a1hp = T1969.$dmd @ A3 T1969.$fCA3 end Rec } }}} Whereas with floating we get, {{{#!hs -- same as above T1969.$dme :: forall a. C a => a -> String T1969.$dmd :: forall a. C a => a -> String ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } Rec { T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik $ce_a1ik :: A1 -> String $ce_a1ik = T1969.$dme @ A1 T1969.$fCA1 $cd_a1ib :: A1 -> String $cd_a1ib = T1969.$dmd @ A1 T1969.$fCA1 end Rec } }}} So far things aren't so bad: the only interesting difference is the floated `[Char]`, which we would expect. However, let's then see what happens during simplification. == Post-simplification == Without floating we see, {{{#!hs T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cc_a1i7 $cc_a1i7 $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } }}} Whereas with floating we have, {{{#!hs ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } $cd_a1ib :: A1 -> String $cd_a1ib = \ (x_aM2 :: A1) -> case x_aM2 of { A1 -> ds_d1k4 } $ce_a1ik :: A1 -> String $ce_a1ik = \ (x_aM3 :: A1) -> case x_aM3 of { A1 -> ds_d1k4 } T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik }}} This is quite interesting: without floating we are somehow able to collapse each of the `A1 -> String` bindings into a single binding (despite CSE being disabled due to `-O0`!). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 19:06:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 19:06:56 -0000 Subject: [GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0 In-Reply-To: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> References: <046.fa3606b478de1c5155495c026c34cd49@haskell.org> Message-ID: <061.d3e069df86ffca524ecb4796b0a46d56@haskell.org> #13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Phab:D1259, which teaches the compiler to aggressively float-out string > literals during desugaring, regresses compiler allocations on `T1969` by > 15% or so at -O0`. > > = The problem = > In the case of `T1969` (compiled with `-O0`) the difference is quite > stark: with floating the non-optimizing simplifier pass produces `{terms: > 16,893, types: 7,552, coercions: 0, joins: 0/0}`, without it produces > `{terms: 12,693, types: 4,552, coercions: 0, joins: 0/0}`. > > The (minimized) test looks like, > {{{#!hs > module T1969 where > > class C a where > c :: a -> String > d :: a -> String > d x = c x > e :: a -> String > e x = c x > > data A1 = A1 > instance C A1 where > c A1 = "A1" > }}} > > == Post-desugar == > The reason for the regression is in part due to the fact that we float > out the `unpackCString# "An"` expression. That is, after desugaring > without floating we get (looking at just the `A1` bindings), > {{{#!hs > T1969.$dme :: forall a. C a => a -> String > T1969.$dme = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM3 :: a_aM1) -> > c @ a_aM1 $dC_a1h9 x_aM3 > > -- same as $dme > T1969.$dmd :: forall a. C a => a -> String > T1969.$dmd = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM2 :: a_aM1) -> > c @ a_aM1 $dC_a1h9 x_aM2 > > $cc_a1i7 :: A1 -> String > $cc_a1i7= \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> > GHC.CString.unpackCString# "A1"# } > > Rec { > T1969.$fCA3 :: C A3 > T1969.$fCA3 = T1969.C:C @ A3 $cc_a1hl $cd_a1hp $ce_a1hy > > $ce_a1hy :: A3 -> String > $ce_a1hy = T1969.$dme @ A3 T1969.$fCA3 > > $cd_a1hp :: A3 -> String > $cd_a1hp = T1969.$dmd @ A3 T1969.$fCA3 > end Rec } > }}} > > Whereas with floating we get, > {{{#!hs > -- same as above > T1969.$dme :: forall a. C a => a -> String > T1969.$dmd :: forall a. C a => a -> String > > ds_d1k4 :: [Char] > ds_d1k4 = GHC.CString.unpackCString# "A1"# > > $cc_a1i7 :: A1 -> String > $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } > > Rec { > T1969.$fCA1 :: C A1 > T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik > > $ce_a1ik :: A1 -> String > $ce_a1ik = T1969.$dme @ A1 T1969.$fCA1 > > $cd_a1ib :: A1 -> String > $cd_a1ib = T1969.$dmd @ A1 T1969.$fCA1 > end Rec } > }}} > > So far things aren't so bad: the only interesting difference is the > floated `[Char]`, which we would expect. However, let's then see what > happens during simplification. > > == Post-simplification == > Without floating we see, > {{{#!hs > T1969.$fCA1 :: C A1 > T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cc_a1i7 $cc_a1i7 > > $cc_a1i7 :: A1 -> String > $cc_a1i7 > = \ (ds_d1jJ :: A1) -> > case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } > }}} > > Whereas with floating we have, > {{{#!hs > ds_d1k4 :: [Char] > ds_d1k4 = GHC.CString.unpackCString# "A1"# > > $cc_a1i7 :: A1 -> String > $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } > > $cd_a1ib :: A1 -> String > $cd_a1ib = \ (x_aM2 :: A1) -> case x_aM2 of { A1 -> ds_d1k4 } > > $ce_a1ik :: A1 -> String > $ce_a1ik = \ (x_aM3 :: A1) -> case x_aM3 of { A1 -> ds_d1k4 } > > T1969.$fCA1 :: C A1 > T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik > }}} > > This is quite interesting: without floating we are somehow able to > collapse each of the `A1 -> String` bindings into a single binding > (despite CSE being disabled due to `-O0`!). New description: Phab:D1259, which teaches the compiler to aggressively float-out string literals during desugaring (namely `DsMonad.mkStringExprFSAtTopLevel`), regresses compiler allocations on `T1969` by 15% or so at `-O0`. = The problem = In the case of `T1969` (compiled with `-O0`) the difference is quite stark: with floating the non-optimizing simplifier pass produces `{terms: 16,893, types: 7,552, coercions: 0, joins: 0/0}`, without it produces `{terms: 12,693, types: 4,552, coercions: 0, joins: 0/0}`. The (minimized) test looks like, {{{#!hs module T1969 where class C a where c :: a -> String d :: a -> String d x = c x e :: a -> String e x = c x data A1 = A1 instance C A1 where c A1 = "A1" }}} This reduced program simplifies to 261 terms and 127 types with float-out and 219 terms, 97 types without. == Post-desugar == The reason for the regression is in part due to the fact that we float out the `unpackCString# "An"` expression. That is, after desugaring without floating we get (looking at just the `A1` bindings), {{{#!hs T1969.$dme :: forall a. C a => a -> String T1969.$dme = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM3 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM3 -- same as $dme T1969.$dmd :: forall a. C a => a -> String T1969.$dmd = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM2 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM2 $cc_a1i7 :: A1 -> String $cc_a1i7= \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } Rec { T1969.$fCA3 :: C A3 T1969.$fCA3 = T1969.C:C @ A3 $cc_a1hl $cd_a1hp $ce_a1hy $ce_a1hy :: A3 -> String $ce_a1hy = T1969.$dme @ A3 T1969.$fCA3 $cd_a1hp :: A3 -> String $cd_a1hp = T1969.$dmd @ A3 T1969.$fCA3 end Rec } }}} Whereas with floating we get, {{{#!hs -- same as above T1969.$dme :: forall a. C a => a -> String T1969.$dmd :: forall a. C a => a -> String ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } Rec { T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik $ce_a1ik :: A1 -> String $ce_a1ik = T1969.$dme @ A1 T1969.$fCA1 $cd_a1ib :: A1 -> String $cd_a1ib = T1969.$dmd @ A1 T1969.$fCA1 end Rec } }}} So far things aren't so bad: the only interesting difference is the floated `[Char]`, which we would expect. However, let's then see what happens during simplification. == Post-simplification == Without floating we see, {{{#!hs T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cc_a1i7 $cc_a1i7 $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } }}} Whereas with floating we have, {{{#!hs ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } $cd_a1ib :: A1 -> String $cd_a1ib = \ (x_aM2 :: A1) -> case x_aM2 of { A1 -> ds_d1k4 } $ce_a1ik :: A1 -> String $ce_a1ik = \ (x_aM3 :: A1) -> case x_aM3 of { A1 -> ds_d1k4 } T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik }}} This is quite interesting: without floating we are somehow able to collapse each of the `A1 -> String` bindings into a single binding (despite CSE being disabled due to `-O0`!). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 19:09:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 19:09:11 -0000 Subject: [GHC] #13212: Support abs as a primitive operation on floating point numbers. In-Reply-To: <046.0fa5a9a408d7a4d76cfff2dd4c5e7b6b@haskell.org> References: <046.0fa5a9a408d7a4d76cfff2dd4c5e7b6b@haskell.org> Message-ID: <061.ed24b28a8f3382933c42d7fe63ac3f4b@haskell.org> #13212: Support abs as a primitive operation on floating point numbers. -------------------------------------+------------------------------------- Reporter: dominic | Owner: dominic Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dominic): * status: new => closed * resolution: => fixed Comment: Fixed by 12ccf767af3373e319b75d5d61fe79df4a389e45 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 20:15:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 20:15:37 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 Message-ID: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- 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 accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The docs claim that the definition in section 9.11.10 {{{ data G (a :: k) where GInt :: G Int GMaybe :: G Maybe }}} "requires that `-XTypeInType` be in effect", but this isn't the case. The following compiles with GHC-8.0.2: {{{ {-# LANGUAGE PolyKinds, GADTs #-} data G (a :: k) where GInt :: G Int GMaybe :: G Maybe }}} The example does *not* compile with 7.10.3, so this seems to be a case where `-XPolyKinds` has become more permissive in GHC 8 (as outlined in section 9.11.1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 20:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 20:58:32 -0000 Subject: [GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c In-Reply-To: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> References: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> Message-ID: <059.616bf895fad83de52368d4301c54846e@haskell.org> #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c -------------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3292 Wiki Page: | -------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3292 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 21:25:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 21:25:35 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.6ec1450573819a544b57a94f2a7c6352@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 22:51:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 22:51:25 -0000 Subject: [GHC] #13386: Poor compiler performance with type families In-Reply-To: <049.c62ef75e26f3d606baae71cbfbd84e45@haskell.org> References: <049.c62ef75e26f3d606baae71cbfbd84e45@haskell.org> Message-ID: <064.d46c40caf40e2812dcdadb02a9505ff6@haskell.org> #13386: Poor compiler performance with type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeFamilies Comment: Yes; see #8095. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 23:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 23:19:41 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.b857d201c2655891de8965307b991f4f@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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 Tue Mar 7 23:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 23:21:21 -0000 Subject: [GHC] #13392: ghc --show-options lists flags twice Message-ID: <046.84b1e3fc71312b95fc0d4ae0b3959c8f@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 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: --------------------------------------+--------------------------------- Running `ghc --show-options` with GHC version 8.0.1 returns the flags `-O` and `-W` twice. To check this, execute the following command in your shell: {{{ ghc --show-options | sort | uniq -d }}} At commit `669333d8afaf388a3ce4a56e383b24ea2bdea145` (GHC 8.1.20170304) only `-O` is duplicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 23:41:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 23:41:00 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.044a036250d1c64a58c6119556510b6f@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: Good catch. I suspect fixing this wouldn't be too challenging. If you look at the commitdiff for 6746549772c5cc0ac66c0fce562f297f4d4b80a2 (Add kind equalities to GHC), searching for `badGadtKindCon` will give you the check that used to be in place for catching datatypes that are GADT-like in their kind arguments. Fixing this issue should hopefully be a matter of reinstating that check, but guarded behind a check for the presence of `-XTypeInType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 23:41:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 23:41:33 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.89e18e20f28a38a1c566cf81ecc44103@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer, | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: newcomer => newcomer, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 7 23:48:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Mar 2017 23:48:13 -0000 Subject: [GHC] Trac email verification for user: sheyll Message-ID: <20170307234813.7E6723A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: sheyll Verification Token: JSlhZPyV -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 00:03:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 00:03:55 -0000 Subject: [GHC] #13393: GHC panic: No skolem info Message-ID: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this GHC output: {{{ /home/sven/DEV_LBM/lbm-talk-flow/mediabus-fdk- aac/src/Data/MediaBus/Audio/FdkAac/Encoder.hs:124:8: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: k_ataY[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It happens when I omit a type signature. We do not have the resources right now to create a minimal test case, but I didn't want to ignore the request to file a bug report. This happens in a small project available on github, I commited the specific code and tagged the commit 'ghc-panic' and added a comment in the code. I doubt that is makes sense to paste the code here, so if anyone looks into this, please grab the code from github at: [https://github.com/lindenbaum/mediabus-fdk-aac/blob/ghc- panic/src/Data/MediaBus/Audio/FdkAac/Encoder.hs] Sorry if this bug report is not helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 00:17:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 00:17:52 -0000 Subject: [GHC] #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c In-Reply-To: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> References: <044.b338bc9f9850155f0f527649d3ef9c35@haskell.org> Message-ID: <059.737ac28e2d5833b17d827b9a82aff95b@haskell.org> #13359: GHCi crash in a standard Windows console (cmd.exe) after Control-c -------------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => new * differential: Phab:D3292 => Comment: Accidentally assigned patch here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 00:18:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 00:18:36 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.7ea3c91dbb4074879c6ea607db651cf7@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => patch * differential: => Phab:D3292 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 00:56:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 00:56:20 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs In-Reply-To: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> References: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> Message-ID: <061.d1fdb2a2718fb255fadc1344adaef76a@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Hm, it seems hsc2hs does not propagate column numbers from the original source file. One could add spaces as necessary to push tokens to the correct location: {{{ lONG_CONSTANT_NAME = 42 :: Int32 }}} If the replaced token is longer then it could be worked around as: {{{ lONG_CONSTANT_NAME = someVeryVeryVeryVeryVeryLongConstant {-# LINE 5 "Bug.hsc" #-} :: Int32 }}} But this might be risky because Haskell is indentation sensitive, so perhaps the simpler approach is to teach GHC a more precise `LINE` pragma: {{{ {-# LINE 5 "Bug.hsc" 57 49 #-} lONG_CONSTANT_NAME = someVeryVeryVeryVeryVeryLongConstant :: Int32 }}} The syntax of this new pragma could be something like: {{{ {-# LINE ... #-} }}} This can be used to adjust column numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 01:34:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 01:34:42 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD Message-ID: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `purescript-0.10.7` fails to build with GHC HEAD at the moment due to an apparent regression in the way pattern synonyms and overloaded strings interact. Here is a simplified example: {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE PatternSynonyms #-} module Bug where import Data.ByteString newtype ProperName = ProperName { runProperName :: ByteString -- purescript actually uses the Text type, but this works -- just as well for the purposes of illustrating the bug } newtype ModuleName = ModuleName [ProperName] pattern TypeDataSymbol :: ModuleName pattern TypeDataSymbol = ModuleName [ProperName "Type",ProperName "Data", ProperName "Symbol"] }}} Compiling this with GHC 7.10.3 or 8.0.2 works without issue. In GHC HEAD, if you compile this with optimization enabled, it'll trigger a GHC panic: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 -O1 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170303 for x86_64-unknown-linux): isUnliftedType r_a28T :: TYPE rep_a28S Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1961:10 in ghc:Type }}} The presence of optimization is crucial for reproducing this bug, as compiling it with `-O0` does not trigger the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 02:26:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 02:26:31 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.9e718259229d6f24976a1d53c9f23d74@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 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 nfrisby): Does the following claim hold water and/or illuminate anything? The implication constraint on `implic` can either be simplified (eg `C a` immediately refines `a` and/or has `D a` as a superclass) or it is only satisfiable by a parametric instance of `D`. Suppose that overlapping and incoherent instances are not allowed. Then any non-parametric instance of `D` (eg your `D Int`) would immediately render that implication constraint unsatisfiable. So the concern is just yet another due solely to overlapping/incoherent instances? Replying to [comment:16 goldfire]: > * Inference: We don't. Just like we don't infer higher-rank types (which, of course, are the same as implication constraints). If a user wants this feature, they have to ask for it. > > * Completeness: This is thornier. Here is how I see a problem arising: > > {{{ > class C a > class D a > instance D Int > > needsD :: D a => a -> () > implic :: (forall a. C a => D a) -> () > implic = needsD (5 :: Int) > }}} > > When typechecking `implic`, the local universal dictionary for `D a` will be used to provide a dictionary to `needsD`. This will then generate an unsatisfiable wanted `C Int`. But, of course, we could have just used the global instance `D Int` instead. > > An issue such as this one can't arise today (even with local dictionaries shadowing global ones) because local dictionaries never give rise to new wanteds. If you have a local dictionary, it's good to use. > > Given/Given interactions would be the same. If one implication-Given can be used in an interaction, it would be, giving rise to its antecedent Wanted constraints. > > This does get me a little worried about nondeterminism. But, I conjecture that if this interaction can give rise to nondeterminism, then it would be possible to exhibit the nondeterminism today, using overlapping instances. > > So, it all comes down to specifying completeness against what spec, and I'm saying that we could be complete against a spec where every local constraint shadows every overlapped global one. That is, when `(forall a. C a => D a)` is in scope, `instance D Int` is not. Will this be easy enough to use to make it practicable? There will be some surprises around it, but I think it's all quite easy to digest with a little guidance. (Certainly easier to understand than closed type families!) > > * Impredicativity: This, to me, is just like the story in kind `*`. `c` should be forbidden from unifying with an implication constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 02:40:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 02:40:18 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.75d926c3ec55b3644f8fa6f43ef247d5@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 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 nfrisby): Your `min` discussion was helpful to me, but I think it's mostly unrelated, in retrospect; the `Ord a` dictionary -- again ignoring overlapping/incoherent instances -- could only ever "overlap" with a parametric instance of `Ord`, since `a` is skolem. #9701, on the other hand, seems to demonstrate exactly what you were getting at (#12791 too?). Replying to [comment:14 goldfire]: > I initially put this ticket into my internal notes as "Difficulty: Rocket Science", but I've changed my mind. I think this is actually straightforward to implement. > > GHC already has implication constraints, except that they're effectively all Wanteds. So, all we would need are to be able to make Given implication constraints. But, these should be rather straightforward, because we can view top-level instances as Given implication constraints. We can just adapt the current look-in-Givens algorithm to do some matching, just like the instance-selection algorithm does. When we find an implication-constraint Given that matches a Wanted, we use it to solve the Wanted and then emit new Wanteds for the antecedents of the Given implication. > > I was initially concerned about overlap here -- what if an implication Given's RHS overlaps with a global instance? -- but this was a red herring. Givens have always potentially overlapped with global instances, and very few people are bothered. For example: > > {{{ > min :: Ord a => a -> a -> a > }}} > > If we call `min` at type `Int`, the `Ord` constraint is potentially ambiguous: do we mean the dictionary supplied or the global `Ord Int` dictionary? Of course, we mean the local one, and we don't require `-XIncoherentInstances` to do so. So, worrying about overlap in the context of implication Givens is a red herring. We have a clear rule: local constraints always shadow global ones. That's nice, simple, and unsurprising. > > This also doesn't change the "GHC never backtracks" principle. If a local implication-constraint's RHS matches, it is used, just like if GHC finds a global implication constraint (read, global constrained instance). > > To implement this, GHC would also need to be able to produce the witness for an implication constraint, but this is just like inferring the lambdas for a higher-rank type. I don't see any challenge here. > > Of course, a niggling feeling tells me that this ''has'' to be harder than I'm seeing it. But, really, all I see standing in the way is a bit of plumbing. > > Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 02:49:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 02:49:24 -0000 Subject: [GHC] #8255: GC Less Operation In-Reply-To: <047.2a21a870e5cc4d2c395ab5ed2820f377@haskell.org> References: <047.2a21a870e5cc4d2c395ab5ed2820f377@haskell.org> Message-ID: <062.95aa39dd052efe0ddb68e117a87b0e26@haskell.org> #8255: GC Less Operation -------------------------------------+------------------------------------- Reporter: sirinath | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 7.7 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 mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 02:57:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 02:57:11 -0000 Subject: [GHC] Trac email verification for user: Forec Message-ID: <20170308025712.006123A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: Forec Verification Token: IIngV55n -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 02:57:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 02:57:50 -0000 Subject: [GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals Message-ID: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- I just noticed that compiling `xmlhtml-0.2.3.5` from Hackage takes an extraordinarily long time on GHC HEAD. The slowdown can be attributed to the `Text.XmlHtml.HTML.Meta` module. I've extracted it and tweaked it so that it requires no dependencies to build (I now use `ByteString` instead of `Text`, but the slowdowns for both types were about the same.) On GHC 8.0.2, it takes about 3 seconds to compile the attached module: {{{ $ /usr/bin/time /opt/ghc/8.0.2/bin/ghc -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 3.44user 0.07system 0:03.51elapsed 99%CPU (0avgtext+0avgdata 208480maxresident)k 0inputs+21688outputs (0major+43934minor)pagefaults 0swaps }}} But on GHC HEAD, it takes about 10 seconds: {{{ $ /usr/bin/time ~/Software/ghc2/inplace/bin/ghc-stage2 -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 9.93user 0.11system 0:10.03elapsed 100%CPU (0avgtext+0avgdata 233656maxresident)k 0inputs+21464outputs (0major+54853minor)pagefaults 0swaps }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 02:57:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 02:57:58 -0000 Subject: [GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals In-Reply-To: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> References: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> Message-ID: <065.4a463a079ff3f91c9c686d2857a9a868@haskell.org> #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "TextXmlHtmlHTMLMeta.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 03:06:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 03:06:21 -0000 Subject: [GHC] #13396: thread blocked when running `deepseq` with infinite list Message-ID: <044.37c4fdee2aa4b8d8b9bca5da0b79856f@haskell.org> #13396: thread blocked when running `deepseq` with infinite list -------------------------------------+------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: thread | Operating System: Unknown/Multiple blocked | Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs ghci> :m +Control.Deepseq ghci> let x = [1..] ghci> x `deepseq` () Ctrl^C Interrupted. ghci> ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation 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 Mar 8 03:06:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 03:06:44 -0000 Subject: [GHC] #13396: thread blocked when running `deepseq` with infinite list In-Reply-To: <044.37c4fdee2aa4b8d8b9bca5da0b79856f@haskell.org> References: <044.37c4fdee2aa4b8d8b9bca5da0b79856f@haskell.org> Message-ID: <059.06c71b743f34795353d668f1bb0698ea@haskell.org> #13396: thread blocked when running `deepseq` with infinite list -------------------------------+-------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: thread blocked 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 Forec): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 08:40:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 08:40:54 -0000 Subject: [GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals In-Reply-To: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> References: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> Message-ID: <065.bb627d500f1beb99390b948fca548692@haskell.org> #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's bad! But it's '''so''' egregiously bad that surely it ought not to be hard to find where the time is going! Ben, Reid, David: might one of you look? If we can fix this we may fix other less-egregious cases. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 09:03:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 09:03:56 -0000 Subject: [GHC] #13222: Update formalism for join points In-Reply-To: <049.b34747a00c615a5f34c9610329937813@haskell.org> References: <049.b34747a00c615a5f34c9610329937813@haskell.org> Message-ID: <064.938bc76b8aa57349d0ad93532aef1dd6@haskell.org> #13222: Update formalism for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3296 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukemaurer): * status: new => patch * differential: => D3296 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 09:06:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 09:06:00 -0000 Subject: [GHC] #13222: Update formalism for join points In-Reply-To: <049.b34747a00c615a5f34c9610329937813@haskell.org> References: <049.b34747a00c615a5f34c9610329937813@haskell.org> Message-ID: <064.2874f0162cd31de21b7529b7e34f2fa0@haskell.org> #13222: Update formalism for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3296 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lukemaurer): * differential: D3296 => Phab:D3296 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 09:21:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 09:21:35 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.9bfa9a807cff8bdf236567fced7b7669@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps this is fixed already? See #13297, #13135, #12844. Would it be possible to check? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 09:46:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 09:46:14 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD In-Reply-To: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> References: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> Message-ID: <065.9beda495ebde0aebe7cce7be46047532@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha. Thanks. Easy fix validating now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 09:58:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 09:58:10 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.fb2d7c6e0a7c77e6ac601bd467be6f1b@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | 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 Mar 8 10:48:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 10:48:59 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# Message-ID: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Ever since we started using `Int#` to represent booleans unboxed (see [wiki:PrimBool]) we have had lots of code looking like {{{ case tagToEnum# (a ># b) of False -> e1 True -> e2 }}} It would be better (less code to optimise, more straightforward, more direct) to optimise this to {{{ case a ># b of DEFAULT -> e1 1# -> e2 }}} Happily, we already have a nice spot to do so: the `caseRules` function in `SimplUtils`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 11:04:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 11:04:19 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD In-Reply-To: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> References: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> Message-ID: <065.3d0f807d1806e72402c0a90a2408932c@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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:"8e053700f9357c1b9030c406130062795ae5015c/ghc" 8e05370/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e053700f9357c1b9030c406130062795ae5015c" Join points can be levity-polymorphic It's ok to have a levity-polymorphic join point, thus let j :: r :: TYPE l = blah in ... Usually we don't allow levity-polymorphic binders, but join points are different because they are not first class. I updated the invariants in CoreSyn. This commit fixes Trac #13394. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 11:13:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 11:13:21 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD In-Reply-To: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> References: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> Message-ID: <065.889d0d5c64007dc05b5d3119b68b2273@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13394 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T13394 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 12:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 12:16:34 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.67c8d32ca5d432b6cb143c4f5da9bd0d@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Just a quick update, I've gone through about 4 rewrite of the core parts of this patch. The biggest issue is with how GHC accesses const data. This forces me to essentially write a unix like dynamic loader in the binaries because of how closures and info tables are accessed. Or use bounded imports and forgo the ability to use ASLR with GHC applications, which is a heavy price. Also `dlltool` is very slow, too slow to be usable at the scale required. GHC has managed to bloat up to a size where it has to be split into 3 DLLs (nearing a 4th). The automatic splitting works fine, but the resulting import libraries require `dlltool` to process 3x ~65k symbols. Which it takes half an hour to do and generates huge file sizes. This is because the way import libraries are implemented in binutils is a hack. Microsoft's own `lib.exe` tool does this in seconds and creates a much much smaller file. This means I also have to write a tool to generate import libraries in their short format for use by GHC. I still expect to finish by `8.4.1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 13:15:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 13:15:56 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.ee7b3d14f10daa739df89a1f15f64422@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 have committed these patches to branch `wip/spj-T13397`: {{{ commit 43540c8c6b9e914f302c71213a71ab5c780be2ac Author: Simon Peyton Jones Date: Wed Mar 8 11:05:53 2017 +0000 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 commit e49f3154a5ceb1894414f4635579aeb3aa84054f Author: Simon Peyton Jones Date: Wed Mar 8 10:26:47 2017 +0000 Re-engineer caseRules to add tagToEnum/dataToTag See Note [Scrutinee Constant Folding] in SimplUtils * Add cases for tagToEnum and dataToTag. This is the main new bit. It allows the simplifier to remove the pervasive uses of case tagToEnum (a > b) of False -> e1 True -> e2 and replace it by the simpler case a > b of DEFAULT -> e1 1# -> e2 See Note [caseRules for tagToEnum] and Note [caseRules for dataToTag] in PrelRules. * This required some changes to the API of caseRules, and hence to code in SimplUtils. See Note [Scrutinee Constant Folding] in SimplUtils. * Avoid duplication of work in the (unusual) case of case BIG + 3# of b DEFAULT -> e1 6# -> e2 Previously we got case BIG of DEFAULT -> let b = BIG + 3# in e1 3# -> let b = 6# in e2 Now we get case BIG of b# DEFAULT -> let b = b' + 3# in e1 3# -> let b = 6# in e2 * Avoid duplicated code in caseRules A knock-on refactoring: * Move Note [Word/Int underflow/overflow] to Literal, as documentation to accompany mkMachIntWrap etc; and get rid of PrelRuls.intResult' in favour of mkMachIntWrap }}} It's good stuff generally, so I'm quite keen to keep it. It does indeed eliminate the annoying `tagToEnum#` stuff. I get the `nofib` results below. There are some odd things happening, which is why I have not committed to HEAD. * I did not expect binary sizes to change, but the do wobble around a bit, with a net tiny increase * I did not expect allocations to change. I chased down the change in `knights`: it was due to increased closure sizes. That in turn was due to better CSE, which is a good thing (just made more live variables). So I think I'm ok with that. Allocations sometimes go down too. Net zero. * There are some troubling increases in execution time. Notably, `n-body` really does run slower, repeatably. I think. I have no idea why. I think the C-- code is the same... but perhaps we are somehow generating worse assembly code. {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.0% -0.7% 0.16 0.16 +0.0% ansi +0.1% +0.0% 0.00 0.00 +0.0% atom +0.2% +0.0% -2.1% -2.1% +0.0% awards +0.2% +0.0% 0.00 0.00 +0.0% banner -0.0% +0.0% 0.00 0.00 +0.0% bernouilli +0.4% -0.0% -0.7% -0.9% +0.0% binary-trees +0.5% -0.0% +4.6% +4.7% +0.0% boyer +0.0% +0.0% 0.06 0.06 +0.0% boyer2 -0.0% +0.0% 0.01 0.01 +0.0% bspt +0.0% +0.0% 0.01 0.01 +0.0% cacheprof +0.0% -0.0% +1.6% +2.3% -1.8% calendar +0.0% +0.0% 0.00 0.00 +0.0% cichelli -0.0% +0.0% 0.12 0.12 +0.0% circsim +0.1% -0.0% +0.7% +0.7% +0.0% clausify +0.2% +0.0% 0.05 0.05 +0.0% comp_lab_zift -0.0% +0.0% +0.3% +0.2% +0.0% compress -0.0% +0.0% -0.7% +0.4% +0.0% compress2 +0.3% +0.0% +2.3% +2.4% +0.0% constraints +0.0% +0.0% +3.2% +3.2% +0.0% cryptarithm1 -0.0% +0.0% -9.0% -9.0% +0.0% cryptarithm2 -0.0% +0.0% 0.01 0.01 +0.0% cse -0.0% +0.0% 0.00 0.00 +0.0% digits-of-e1 +0.4% +0.0% +2.9% +2.9% +0.0% digits-of-e2 +0.3% +0.0% -2.1% -2.1% +0.0% eliza -0.0% +0.0% 0.00 0.00 +0.0% event +0.0% +0.0% +0.3% +0.3% +0.0% exp3_8 +0.2% +0.0% +0.7% +0.7% +0.0% expert +0.1% +0.0% 0.00 0.00 +0.0% fannkuch-redux -0.0% -0.0% -1.1% -1.1% +0.0% fasta +0.0% +0.0% +0.5% -0.2% +0.0% fem +0.4% +0.0% 0.04 0.04 +0.0% fft +0.2% -0.4% 0.06 0.06 +0.0% fft2 +0.2% -0.1% 0.08 0.08 +0.0% fibheaps +0.0% +0.0% 0.03 0.03 +0.0% fish -0.0% +0.0% 0.02 0.02 +0.0% fluid +0.2% +0.0% 0.01 0.01 +0.0% fulsom +0.1% +0.0% +0.1% +0.0% +0.0% gamteb +0.2% +0.0% 0.07 0.07 +0.0% gcd +0.3% +0.0% 0.09 0.09 +0.0% gen_regexps -0.0% +0.0% 0.00 0.00 +0.0% genfft -0.1% -0.2% 0.06 0.06 +0.0% gg +0.1% +0.0% 0.02 0.02 +0.0% grep -0.1% +0.0% 0.00 0.00 +0.0% hidden +0.4% +0.0% +2.8% +2.9% +0.0% hpg +0.1% -0.0% -1.9% -2.1% +0.0% ida +0.0% +0.0% 0.10 0.10 +0.0% infer -0.0% +0.0% 0.10 0.10 +0.0% integer +0.5% +0.0% +1.6% +1.6% +0.0% integrate +0.2% +0.0% +4.8% +5.0% +0.0% k-nucleotide +0.1% -0.1% -1.5% -1.6% +0.0% kahan +0.2% +0.0% +1.6% +1.6% +0.0% knights +0.2% +1.3% 0.01 0.01 +0.0% lambda +0.0% +0.0% +6.5% +6.5% +0.0% last-piece -0.1% +0.3% +2.4% +2.5% +0.0% lcss +0.0% +0.0% +2.7% +2.7% +0.0% life +0.1% +0.0% +0.8% +1.0% +0.0% lift -0.0% +0.0% 0.00 0.00 +0.0% listcompr -0.0% +0.0% 0.18 0.18 +0.0% listcopy -0.0% +0.0% 0.19 0.19 +0.0% maillist -0.0% -0.0% 0.08 0.09 -5.3% mandel +0.5% +0.0% 0.13 0.13 +0.0% mandel2 -0.0% +0.0% 0.01 0.01 +0.0% minimax -0.0% +0.0% 0.01 0.01 +0.0% mkhprog -0.0% +0.0% 0.00 0.00 +0.0% multiplier +0.0% +0.0% 0.19 0.19 +0.0% n-body +0.2% +0.0% +14.6% +14.6% +0.0% nucleic2 +0.2% +0.0% 0.11 0.11 +0.0% para -0.0% +0.0% -1.5% -1.5% +0.0% paraffins -0.1% -0.1% 0.19 0.20 +0.0% parser -0.6% +0.0% 0.04 0.04 +0.0% parstof -0.0% +0.0% 0.01 0.01 +0.0% pic -0.3% +1.1% 0.01 0.01 +0.0% pidigits +0.3% +0.0% -0.0% -0.0% +0.0% power +0.2% +0.0% +2.0% +2.2% +0.0% pretty +0.3% +0.0% 0.00 0.00 +0.0% primes +0.0% +0.0% 0.11 0.11 +0.0% primetest +0.4% +0.0% 0.13 0.13 +0.0% prolog +0.2% +0.0% 0.00 0.00 +0.0% puzzle -0.0% +0.0% 0.20 0.20 +0.0% queens +0.0% +0.0% 0.02 0.02 +0.0% reptile -0.1% +0.0% 0.02 0.02 +0.0% reverse-complem -0.0% +0.0% +2.4% +2.4% +0.0% rewrite +0.0% +0.0% 0.03 0.03 +0.0% rfib +0.5% +0.0% 0.03 0.03 +0.0% rsa +0.4% +0.0% 0.03 0.03 +0.0% scc -0.0% +0.0% 0.00 0.00 +0.0% sched +0.0% +0.0% 0.03 0.03 +0.0% scs +0.0% +0.8% +7.6% +7.5% +0.0% simple +0.1% +0.0% +4.9% +5.0% +0.0% solid +0.2% +0.0% 0.19 0.19 +0.0% sorting -0.0% +0.0% 0.00 0.00 +0.0% spectral-norm +0.2% +0.0% +1.5% +1.5% +0.0% sphere +0.0% +0.0% 0.08 0.08 +0.0% symalg +0.4% +0.0% 0.01 0.01 +0.0% tak +0.0% +0.0% 0.02 0.02 +0.0% transform -0.0% +0.0% -4.5% -4.5% +0.0% treejoin -0.0% +0.0% +16.7% +16.6% +0.0% typecheck -0.0% +0.0% -1.4% -1.3% +0.0% veritas -0.1% +0.0% 0.00 0.00 +0.0% wang +0.2% +0.0% 0.17 0.17 +0.0% wave4main +0.0% +0.0% +1.9% +1.7% +0.0% wheel-sieve1 +0.0% +0.0% +1.5% +1.5% +0.0% wheel-sieve2 +0.0% +0.0% +0.6% +0.6% +0.0% x2n1 +0.1% +0.0% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -0.6% -0.7% -9.0% -9.0% -5.3% Max +0.5% +1.3% +16.7% +16.6% +0.0% Geometric Mean +0.1% +0.0% +1.6% +1.6% -0.1% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 13:20:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 13:20:01 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.86776b4118acd9bf7ad4d891f9c072c8@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): PS The improvement in `cryptarithm1` runtime appears to be solid and real too. So there is a win here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 13:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 13:47:17 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD In-Reply-To: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> References: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> Message-ID: <065.1401b206a02d49f5f7e6da85421dcca6@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13394 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => Comment: Thanks, Simon. But you didn't include the original program as the test case! Rather, you included a slightly tweaked program that doesn't have as many list elements in `TypeDataSymbol`. This is crucial, as the original program still fails with a GHC panic even after 8e053700f9357c1b9030c406130062795ae5015c: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 -O1 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170307 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_a28P :: TYPE rep_a28O) rep_a28O Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 14:56:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 14:56:00 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative Message-ID: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11450 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `mediabus-0.3.0.1` currently fails to build on GHC HEAD because of this regression. Here's a simplified program which exemplifies the issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Mediabus where data Nat data Rate data StaticTicks where (:/:) :: Nat -> Rate -> StaticTicks type ticks :/ rate = ticks ':/: rate class HasStaticDuration (s :: k) where type SetStaticDuration s (pt :: StaticTicks) :: k instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) (t' :/ r') = t' :/ r' }}} This compiles fine on GHC 8.0.2, but on GHC HEAD, it gives an odd error: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.1.20170307: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Mediabus ( Bug.hs, interpreted ) Bug.hs:19:8: error: • Polymorphic type indexes of associated type ‘SetStaticDuration’ (i.e. ones independent of the class type variables) must be distinct type variables Expected: SetStaticDuration (t :/ r) Actual: SetStaticDuration (t :/ r) (t' :/ r') where the `' arguments are type variables, distinct from each other and from the instance variables • In the type instance declaration for ‘SetStaticDuration’ In the instance declaration for ‘HasStaticDuration (t :/ r)’ | 19 | type SetStaticDuration (t :/ r) (t' :/ r') = t' :/ r' | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This error message comes from 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450). To fix it, you have to do a tiresome song and dance with auxiliary type families: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Mediabus where data Nat data Rate data StaticTicks where (:/:) :: Nat -> Rate -> StaticTicks type ticks :/ rate = ticks ':/: rate class HasStaticDuration (s :: k) where type SetStaticDuration s (pt :: StaticTicks) :: k instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) pt = SSDTicks pt type family SSDTicks (pt :: StaticTicks) :: StaticTicks where SSDTicks (t' :/ r') = t' :/ r' }}} But after Simon's motivation for this change in https://ghc.haskell.org/trac/ghc/ticket/11450#comment:24, I'm still not convinced that the original program should be rejected. After all, this change was introduced so that associated type families with //multiple// would be rejected. But in the `SetStaticDuration` example above, there's only one equation, and it's a complete pattern match! So I'm failing to see why it should be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 14:56:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 14:56:11 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.9cc1c4c08ed2ece9bfe5d30e7226600c@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sadly, I just tried compiling this on GHC HEAD, and the panic is still present. I need to see if I can minimize this to a reproducible test case. (Moreover, I discovered another bug in the process: #13398) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 15:10:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 15:10:36 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.6e1c635a3d509e7b1c6f132c878a0123@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | 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: #11450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Upon further thought, I'm not even sure why this particular restriction was added in the first place. #11450 was about making the type variables used in a class instance head the same as the variables used in the same positions in the associated type family instances. This business about not allowing multiple associated type family instances feels completely orthogonal to that issue (indeed, I wasn't even aware of its existence until just now, as it seems to have been snuck in without a mention in the GHC 8.2 release notes). Moreover, this additional check is causing code in the wild to fail, and for reasons that I don't comprehend. Simon, what exactly is the problem with allowing code like what is shown in the original program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 16:04:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 16:04:12 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.af8cd42ea5432c4557ff4232d36cfb45@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, here's something with no dependencies which triggers the same panic: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Mediabus ( ) where import Control.Monad.Trans.RWS.Strict (RWST) import Data.Functor.Identity (Identity) import Data.Kind (Type) import Data.Word (Word16) data Rate data Audio (sampleRate :: Rate) (channelLayout :: Type) (encoding :: Type) data EncodeResult = MkEncodeResult { encodeResultLeftOverInput :: !(Maybe [Word16]) } data EncodeFailure data AacEncErrorCode data Aac (aot :: AacCodec) data AacCodec newtype AacEncSt (rate :: Rate) channels (codec :: AacCodec) = MkAacEncSt { _leftOvers :: Maybe [Word16] } -- makeLenses ''AacEncSt type Iso s t a b = forall p f. (Functor f) => (a -> f b) -> s -> (f t) instance (Monad m, Monoid w) => MonadState s (RWST r w s m) where iso :: (s -> a) -> (b -> t) -> Iso s t a b iso sa bt x = fmap bt . x . sa {-# INLINE iso #-} leftOvers :: forall rate_a750 channels_a753 codec_a757 rate_aaYK channels_aaYL codec_aaYM. Iso (AacEncSt rate_a750 channels_a753 codec_a757) (AacEncSt rate_aaYK channels_aaYL codec_aaYM) (Maybe [Word16]) (Maybe [Word16]) leftOvers = (iso (\ (MkAacEncSt x_aaYN) -> x_aaYN)) MkAacEncSt {-# INLINE leftOvers #-} type ASetter s t a b = (a -> Identity b) -> s -> Identity t class Monad m => MonadState s m | m -> s where (.=) :: MonadState s m => ASetter s s a b -> b -> m () l .= b = undefined {-# INLINE (.=) #-} type AacEncT rate channels codec m a = RWST Int () (AacEncSt rate channels codec) m a encodeLinearToAac :: AacEncT rate channels codec IO (Either EncodeFailure (Maybe (Audio rate channels (Aac codec)))) encodeLinearToAac = do mapM putBackLeftOverInputAndReturnOutput undefined undefined where putBackLeftOverInputAndReturnOutput (MkEncodeResult x) = do leftOvers .= x undefined }}} This was actually introduced in GHC 8.0.2, it seems. On GHC 8.0.1, it gives this error: {{{ Bug.hs:63:3: error: • Ambiguous type variable ‘t0’ arising from a use of ‘mapM’ prevents the constraint ‘(Traversable t0)’ from being solved. Probable fix: use a type annotation to specify what ‘t0’ should be. These potential instances exist: instance Traversable (Either a) -- Defined in ‘Data.Traversable’ instance Traversable Identity -- Defined in ‘Data.Functor.Identity’ instance Traversable Maybe -- Defined in ‘Data.Traversable’ ...plus two others ...plus 24 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In a stmt of a 'do' block: mapM putBackLeftOverInputAndReturnOutput undefined In the expression: do { mapM putBackLeftOverInputAndReturnOutput undefined; undefined } In an equation for ‘encodeLinearToAac’: encodeLinearToAac = do { mapM putBackLeftOverInputAndReturnOutput undefined; undefined } where putBackLeftOverInputAndReturnOutput (MkEncodeResult x) = do { leftOvers .= x; .... } }}} But on GHC 8.0.2, it panics: {{{ Bug.hs:63:8: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: k_a2RY[sk] }}} So does GHC HEAD: {{{ Bug.hs:63:8: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170307 for x86_64-unknown-linux): No skolem info: k_a3pM[sk:3] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2627:5 in ghc:TcErrors }}} The presence of `PolyKinds` is crucial to triggering this bug. Without `PolyKinds`, you get the same error message on GHC 8.0.2 and HEAD as you would with 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 16:20:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 16:20:29 -0000 Subject: [GHC] #13341: Lift constraint products In-Reply-To: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> References: <051.6c1d66f7c7969489dc6e3f3c15096212@haskell.org> Message-ID: <066.72669ae563216d484128afae5499c2a9@haskell.org> #13341: Lift constraint products -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I want to get a discussion going, could we lift constraint products > automatically. > > Although not partially applicable, we can consider `(,)` as having kind > > {{{#!hs > (,) :: Constraint -> Constraint -> Constraint > }}} > > I propose also giving it kinds > > {{{#!hs > (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) > > (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> > Constraint) > > -- etc. > }}} > > == Translation > > {{{#!hs > (Eq, Num, Show) > (Monad, Foldable) > (Category, Profunctor) > }}} > > gets turned into something like > > {{{#!hs > class (c a, d a) => (c :&: d) a > instance (c a, d a) => (c :&: d) a > infixl 7 :&: > > Eq:&:Num:&:Show > Monad:&:Foldable > Category:&:Profunctor > }}} > > == Uses > > Very often I need to be able to combine constraints. > > A small modification of [https://hackage.haskell.org/package/free- > functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] > > {{{#!hs > type c :~ d = forall xx. c x :- d xx > > class HasSuperClasses (c :: k -> Constraint) where > type SuperClasses c :: k -> Constraint > type SuperClasses c = c > > superClasses :: c :~ SuperClasses c > containsSelf :: SuperClasses c :~ c > > instance HasSuperClasses Functor where > superClasses :: Functor :~ Functor > superClasses = Sub Dict > > containsSelf :: Functor :~ Functor > containsSelf = Sub Dict > > instance HasSuperClasses Foldable where > superClasses :: Foldable :~ Foldable > superClasses = Sub Dict > > containsSelf :: Foldable :~ Foldable > containsSelf = Sub Dict > }}} > > I want to be able to write > > {{{#!hs > instance HasSuperClasses Traversable where > type Traversable = (Traversable, Functor, Foldable) > > superClasses :: Traversable :~ (Traversable, Functor, Foldable) > superClasses = Sub Dict > > containsSelf :: (Traversable, Functor, Foldable) :~ Traversable > containsSelf = Sub Dict > }}} > > If this doesn't pose any difficulties I'll open a GHC proposal. > > == Etc. == > > With #12369, why not make them all instances of the same data family > (including `(,)` and `Product`) > > {{{#!hs > data family (,) :: k -> k -> k > > -- (,) :: Type -> Type -> Type > data instance (a, b) = (a, b) > > -- Data.Functor.Product.Product :: (k -> Type) -> (k -> Type) -> (k -> > Type) > data instance (f, g) a = f a `Pair` g a > > -- Data.Bifunctor.Product.Product :: (k -> k' -> Type) -> (k -> k' -> > Type) -> (k -> k' -> Type) > data instance (f, g) a b = f a b `Pair2` g a b > }}} > > the type class could be made an instance of this “data” family: > > {{{#!hs > -- (,) :: Constraint -> Constraint -> Constraint > > -- (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) > class (c a, d a) => (c, d) a > instance (c a, d a) => (c, d) a > > -- (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' > -> Constraint) > class (c a b, d a b) => (c, d) a b > instance (c a b, d a b) => (c, d) a b > }}} New description: I want to get a discussion going, could we lift constraint products automatically. Although not partially applicable, we can consider `(,)` as having kind {{{#!hs (,) :: Constraint -> Constraint -> Constraint }}} I propose also giving it kinds {{{#!hs (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) -- etc. }}} == Translation {{{#!hs (Eq, Num, Show) (Monad, Foldable) (Category, Profunctor) }}} gets turned into something like {{{#!hs class (c a, d a) => (c :&: d) a instance (c a, d a) => (c :&: d) a infixl 7 :&: Eq:&:Num:&:Show Monad:&:Foldable Category:&:Profunctor }}} == Uses Very often I need to be able to combine constraints. A small modification of [https://hackage.haskell.org/package/free- functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] {{{#!hs type c :~ d = forall xx. c x :- d xx class HasSuperClasses (c :: k -> Constraint) where type SuperClasses c :: k -> Constraint type SuperClasses c = c superClasses :: c :~ SuperClasses c containsSelf :: SuperClasses c :~ c instance HasSuperClasses Functor where superClasses :: Functor :~ Functor superClasses = Sub Dict containsSelf :: Functor :~ Functor containsSelf = Sub Dict instance HasSuperClasses Foldable where superClasses :: Foldable :~ Foldable superClasses = Sub Dict containsSelf :: Foldable :~ Foldable containsSelf = Sub Dict }}} I want to be able to write {{{#!hs instance HasSuperClasses Traversable where type Traversable = (Traversable, Functor, Foldable) superClasses :: Traversable :~ (Traversable, Functor, Foldable) superClasses = Sub Dict containsSelf :: (Traversable, Functor, Foldable) :~ Traversable containsSelf = Sub Dict }}} If this doesn't pose any difficulties I'll open a GHC proposal. == Etc. == With #12369, why not make them all instances of the same data family (including `(,)` and `Product`) {{{#!hs data family (,) :: k -> k -> k -- (,) :: Type -> Type -> Type data instance (a, b) = (a, b) -- Data.Functor.Product.Product :: (k -> Type) -> (k -> Type) -> (k -> Type) data instance (f, g) a = f a `Pair` g a -- Data.Bifunctor.Product.Product :: (k -> k' -> Type) -> (k -> k' -> Type) -> (k -> k' -> Type) data instance (f, g) a b = f a b `Pair2` g a b }}} the type class could be made an instance of this “data” family: {{{#!hs -- (,) :: Constraint -> Constraint -> Constraint class (c, d) => (c, d) -- from https://github.com/ghc/ghc/blob/master/libraries/ghc- prim/GHC/Classes.hs#L477 -- (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) class (c a, d a) => (c, d) a instance (c a, d a) => (c, d) a -- (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) class (c a b, d a b) => (c, d) a b instance (c a b, d a b) => (c, d) a b }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 16:36:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 16:36:56 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.3c916be57eeb7f0fa1e66449830806e9@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheyll): Wow, what an awesome response, thank you RyanGlScott -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 17:42:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 17:42:15 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.0b0ea8c491ad60119f6a1528933df6d5@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha! I have a fix validating for #13371, and it seems to fix this one too! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 17:52:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 17:52:31 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.4a6dd350af3b8163ea9bfaf59328ddb0@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | 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: #11450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why did you not write (in the original) {{{ instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/ r) pt = pt }}} I suppose you'll say that since `StaticTicks` has only one data constructor, replacing `pt` by `(t' :/ r')` makes no difference. But what about {{{ type family F a :: StaticTicks }}} Now I suppose that `SetStaticDuration (t :/ r) (F Int)` will fail to reduce? Suppose `StaticTicks` had a second data constructor `Foo`. Would you still say that the instance should be accepted? I was just trying to enforce that the definition was complete, nothing deeper. There is nothing fundamentally wrong with a partial function I suppose. But really, what's wrong with just using a variable here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 19:58:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 19:58:41 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.3e1a0a7c78e61cfb7fe706d19f3fe025@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3290 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Yikes. I broke `-split_objs` on macOS in 266a9dc4cd34008f1162eb276032c85ef8371842. Should I revert? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 20:02:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 20:02:48 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.a39340495ff1ff93ff9614058307fdd1@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | 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: #11450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 simonpj]: > Why did you not write (in the original) ... Because I didn't write this code. It's from Hackage. > But really, what's wrong with just using a variable here? Because that trick will only work in very limited circumstances. To better illustrate the point I'm trying to make, imagine you instead had this code: {{{#!hs instance HasStaticDuration (t :/ r) where type SetStaticDuration (t :/r) (t' :/ r') = r' :/ t' }}} This is a perfectly legitimate associated type family instance, and moreover, it //requires// pattern-matching on the second argument to `SetStaticDuration` to define. Yet in GHC HEAD, you cannot do this—you necessarily must jump through hoops to accomplish the same thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 20:09:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 20:09:33 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.08f04ec4a58b3c4756b71de154a9c8c0@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: highest => normal * status: patch => new * differential: Phab:D3290 => * milestone: 8.2.1 => 8.4.1 Comment: Commit 1686f30951292e94bf3076ce8b3eafb0bcbba91d made the mangler remove `.subsections_via_symbols` from LLVM output, implementing option 1 above. So the current status is that the LLVM backend works fine; there just isn't any way to get dead code stripped from modules built by the LLVM backend. `-split-objs` never worked with LLVM anyways, so this is not a regression. So no need to revert the other splitter-related changes. For the most part the LLVM backend is only used for end-user code, rather than for libraries. So there isn't likely to be much dead code to strip anyways. But for targets like iOS on arm/aarch64, LLVM is the only backend option; so I'm leaving this ticket open. Unfortunately the approach using `.alt_entry` did not quite work out, for reasons that are not entirely clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 20:16:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 20:16:23 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.b9a1b443cd0d5fbd78cb874e6991cde0@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Heh, that is a funny coincidence. I even managed to discover that the same commit that caused this regression (c9bcaf3165586ac214fa694e61c55eb45eb131ab) is also responsible for #13371. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 21:11:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 21:11:09 -0000 Subject: [GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals In-Reply-To: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> References: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> Message-ID: <065.4d7a78c493cced16083c7305cd59ed86@haskell.org> #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I took a look but on my systems it doesn't compile in anywhere near 3.5 seconds under GHC 8.0.2. It takes about 15 seconds for me and a recent (but not absolutely up-to-date) HEAD is similar. RyanGlScott are you sure about these numbers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 8 23:08:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Mar 2017 23:08:30 -0000 Subject: [GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals In-Reply-To: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> References: <050.e339b7ab1456e1eded15915476d7bb4c@haskell.org> Message-ID: <065.3e160dd7e1c79bd432acce14a2346c41@haskell.org> #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Ugh, it turns out this was caused by me using a GHC HEAD that was built with the `quick` flavor instead of the `perf` flavor. I had thought that the only difference between the two was that the latter built Haddocks and other non-essentials—that couldn't have been more wrong! After rebuilding GHC HEAD with `perf`, I get this time: {{{ $ /usr/bin/time ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 3.08user 0.07system 0:03.17elapsed 99%CPU (0avgtext+0avgdata 196820maxresident)k 0inputs+21464outputs (0major+41873minor)pagefaults 0swaps }}} Which is even //better// than 8.0.2! So this tale had a happy ending after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 01:54:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 01:54:23 -0000 Subject: [GHC] #13177: Give Data.Functor.* its lifted void and unit In-Reply-To: <051.47ebb92305025f856dac567302c0becb@haskell.org> References: <051.47ebb92305025f856dac567302c0becb@haskell.org> Message-ID: <066.42aa24def8a5548b5e14b0895c9f5f2f@haskell.org> #13177: Give Data.Functor.* its lifted void and unit -------------------------------------+------------------------------------- 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 Iceland_jack): Some [https://gist.github.com/Icelandjack/e77a5f0e2cef21b47a1a707e80bed7c0 notes]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 04:36:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 04:36:38 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism Message-ID: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- The following code fails to compile, but probably should: {{{ {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 class C (a :: forall k . k -> *) instance C (Foo a) -- error on this line }}} with the error {{{ • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ • In the first argument of ‘C’, namely ‘Foo a’ In the instance declaration for ‘C (Foo a)’ }}} Similarly, the following declarations of `Foo` also cause a similar error at the instance declaration: Decl 2: `data Foo :: (* -> *) -> k -> *` Decl 3: `data Foo (a :: * -> *) (b :: k)` However, if I move the `forall` to a point ''after'' the first type parameter (which is where the instance is partially applied) thusly: Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` then GHC happily accepts the instance of `C`. From my (admittedly negligible) knowledge of type theory, the signatures for Decls 1 and 4 (and 2) are identical, since the `forall` can be floated to the front of Decl 4. GHC should accept any of the four versions of `Foo`, since they are all equivalent. As a side note, I was surprised to discover that the syntax for Decl 4 is even allowed. What is the point of allowing a "global"/rank-1 forall anywhere but at the left edge of the signature (other than as a convenient workaround for this bug)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 04:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 04:37:04 -0000 Subject: [GHC] #13399: Location of `forall` matters with kind polymorphism (was: Location of `forall` matters with higher-rank kind polymorphism) In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.cf8c4ac8cf70cd5ad0c3e415b22c68fd@haskell.org> #13399: Location of `forall` matters with kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 10:56:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 10:56:56 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case Message-ID: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case ------------------------------+---------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+---------------------------- First, I start GHCi with a memory card insert in the slot of the computer. GHCi run ok. Second, I stop running GHCi and I remove the memory card. Third, I restart GHCi and a message appears in a window "realgcc.exe there is no disk - insert a disk in drive D:". When I reinsert the memory card, GHCi run again. Realgcc.exe is in the directory c:ghc-8.0.2\mingw\bin. Hope this help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 11:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 11:43:36 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.bcfb4e6c5287c907190c6031d554cf47@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: feature request | Status: new Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Is this addressed after merging Phab:D3280? IIUC, it is ok to use `-optc` to affect all stubs in a module as long as `-x lang` is not given. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 11:45:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 11:45:23 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.5c377164d3beb9baed26237929479154@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: feature request | Status: new Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): Yes, this is solved by D3280, since `addForeignFile` gives the user specific support for languages other than C. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 11:45:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 11:45:44 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.0ff80c1c82341bfcf30ed2163463e3dd@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: feature request | Status: closed Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bitonic): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 11:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 11:47:51 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.dade88aa3a51fe3b90dceb211cfdc3e2@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bitonic Type: feature request | Status: closed Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): Actually, I realized now that the scope of the ticket is a bit wider -- since it's regarding any compilation flag. It would be easy to extend `addForeignFile` to accept other flags, but I don't think is as critical (at least it isn't for my use cases). I'll leave the decision to bgamari. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 11:51:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 11:51:28 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.a4f97495da44c5a04c0d881ed4eacdfc@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bitonic): * owner: bitonic => (none) * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 13:29:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 13:29:53 -0000 Subject: [GHC] #13399: Location of `forall` matters with kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.0edf48b759465abfb85c5124d4e2b4c7@haskell.org> #13399: Location of `forall` matters with kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > The following code fails to compile, but probably should: > > {{{ > {-# LANGUAGE RankNTypes, TypeInType #-} > > import Data.Kind > > data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 > > class C (a :: forall k . k -> *) > > instance C (Foo a) -- error on this line > }}} > > with the error > > {{{ > • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ > • In the first argument of ‘C’, namely ‘Foo a’ > In the instance declaration for ‘C (Foo a)’ > }}} > > Similarly, the following declarations of `Foo` also cause a similar error > at the instance declaration: > > Decl 2: `data Foo :: (* -> *) -> k -> *` > > Decl 3: `data Foo (a :: * -> *) (b :: k)` > > However, if I move the `forall` to a point ''after'' the first type > parameter (which is where the instance is partially applied) thusly: > > Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` > > then GHC happily accepts the instance of `C`. > > From my (admittedly negligible) knowledge of type theory, the signatures > for Decls 1 and 4 (and 2) are identical, since the `forall` can be > floated to the front of Decl 4. GHC should accept any of the four > versions of `Foo`, since they are all equivalent. > > As a side note, I was surprised to discover that the syntax for Decl 4 is > even allowed. What is the point of allowing a "global"/rank-1 forall > anywhere but at the left edge of the signature (other than as a > convenient workaround for this bug)? New description: The following code fails to compile, but probably should: {{{ {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data Foo :: forall k . (* -> *) -> k -> * -- Decl 1 class C (a :: forall k . k -> *) instance C (Foo a) -- error on this line }}} with the error {{{ • Expected kind ‘forall k. k -> *’, but ‘Foo a’ has kind ‘k0 -> *’ • In the first argument of ‘C’, namely ‘Foo a’ In the instance declaration for ‘C (Foo a)’ }}} Similarly, the following declarations of `Foo` also cause a similar error at the instance declaration: Decl 2: `data Foo :: (* -> *) -> k -> *` Decl 3: `data Foo (a :: * -> *) (b :: k)` However, if I move the `forall` to a point ''after'' the first type parameter (which is where the instance is partially applied) thusly: Decl 4: `data Foo :: (* -> *) -> forall k . k -> *` then GHC happily accepts the instance of `C`. From my (admittedly negligible) knowledge of type theory, the signatures for Decls 1 and 4 (and 2) are identical, since the `forall` can be floated to the front of Decl 4. GHC should accept any of the four versions of `Foo`, since they are all equivalent. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 13:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 13:36:19 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism (was: Location of `forall` matters with kind polymorphism) In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.1b3d6569cd57119aa5218d0831e45a1f@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 don't think we have a very consistent story for higher-rank polymorphism at the kind level. The kind of C is {{{ c :: (forall k. k->*) -> Constraint }}} which has higher rank. I'm interested in your use-cases for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 14:00:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 14:00:57 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.26f694eef0974de21fde9c48a6b2eac5@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 crockeea): **Use case:** I'm working on a HOAS for a [http://okmij.org/ftp/tagless-final/ tagless final] DSL. That approach uses GADTs for "interpreters" of various languages (classes). The class `C` in my example comes from the language for lambda abstractions in our depth-indexed language. Namely, {{{ class LambdaD (expr :: forall k . k -> * -> *) where lamD :: (expr da a -> expr db b) -> expr '(da,db) (a -> b) appD :: expr '(da,db) (a -> b) -> expr da a -> expr db b }}} where `expr` is one of the GADT interpreters. We need to remember the depth of the input and output of the function, so we change the ''kind'' of the "depth" to a pair. **Back to this ticket:** However, I just realized you don't actually need higher-rank polymorphism to see this bug. You can do the following in GHCi: {{{ > :set -XTypeInType > :set -XRankNTypes > :set -fprint-explicit-foralls > data Bar :: forall k. (* -> *) -> k -> * > :kind! Bar Bar :: forall k. (* -> *) -> k -> * -- precisely what I wrote, no surprise here > :kind! (Bar Maybe :: forall k. k -> *) :1:2: error: • Expected kind ‘forall k. k -> *’, but ‘Bar Maybe’ has kind ‘k0 -> *’ • In the type ‘(Bar Maybe :: forall k. k -> *)’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 14:16:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 14:16:16 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application Message-ID: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the docs for `-XVisibleTypeApplication`: >When printing types with `-fprint-explicit-foralls` (page 72) enabled, type variables not available for visible type application are printed in braces. Thus, if you write `myLength = length` without a type signature, `myLength`‘s inferred type will be `forall {f} {a}. Foldable f => f a -> Int`. {{{ > :set -XScopedTypeVariables > :set -XTypeApplications > :set -fprint-explicit-foralls > let foo :: forall a. a; foo = undefined (LINE 1) > :t foo foo :: forall {a}. a (LINE 2) > > :t (foo @Bool) (foo @Bool) :: Bool (LINE 3) }}} Type application with `foo` (LINE 1) should be possible, but GHCi claims it is not (LINE 2), then allows it anyway (LINE 3). This looks like a bug with `fprint-explicit-foralls` in detecting which variables are available for type application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 14:39:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 14:39:10 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.4840bd62553ec8141635bb56cf2e6013@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 14:44:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 14:44:29 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.15c0be022fdc186ac5e33a38ae9e9de2@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): * cc: goldfire (added) Comment: This does indeed seem strange. Simon is right that there aren't many examples of higher-rank kinds in the wild from which to draw inspiration (OtToMH, I can only think of [https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c76947b94c/extensibility/Extensible6.hs this example] from A Dependent Haskell Triptych). But I agree that there appears to be some inconsistencies between the ways that higher-rank types and higher-rank kinds are handled. Some other oddities: if you define this: {{{#!hs data Foo :: (* -> *) -> (forall k. k -> *) }}} and type `:i Foo` into GHCi, you get this back: {{{ type role Foo phantom nominal phantom data Foo (a :: * -> *) k (c :: k) }}} This seems to imply that `Foo` has three visible type parameters, which isn't true at all! Moreover, this works: {{{#!hs data Foo :: (* -> *) -> (k -> *) type Goo = Foo }}} But this does not: {{{#!hs data Foo :: (* -> *) -> (forall k. k -> *) type Goo = Foo }}} {{{ • Expecting two more arguments to ‘Foo’ Expected kind ‘k0’, but ‘Foo’ has kind ‘(* -> *) -> forall k. k -> *’ • In the type ‘Foo’ In the type declaration for ‘Goo’ }}} This seems to be exclusive to higher-rank kinds, as the type-level equivalents work just fine: {{{ λ> let foo1 :: (* -> *) -> (k -> *); foo1 = undefined λ> let goo1 = foo1 λ> let foo2 :: (* -> *) -> (forall k. k -> *); foo2 = undefined λ> let goo2 = foo2 }}} goldfire, is this expected behavior? And are these idiosyncrasies documented somewhere? I find the current behavior extremely confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 14:45:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 14:45:16 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.0eef07fbd83c91ca067fb9f99b5968f2@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | 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: #11450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > To better illustrate the point I'm trying to make, imagine you instead had this code: Ah. Excellent point. An easy thing to do is simply to lift the check altogether. So the result would be * The args corresponding to the class parameters must be identical * The other args can be anything at all So we'd allow {{{ class C a where type F a b ... instance C Int where type F Int Bool = Char ... }}} That says nothing about what `F Int Char` might be; and you can only give instances for `F` inside a class `instance`, so you can't extend it later. We could get this simply by omitting the two `check_poly_arg` lines in `TcValidity.checkConsistntFamInst`: {{{ -- Check type args first (more comprehensible) ; checkTc (all check_arg type_shapes) pp_wrong_at_arg ; checkTc (check_poly_args type_shapes) pp_wrong_at_tyvars -- And now kind args ; checkTc (all check_arg kind_shapes) (pp_wrong_at_arg $$ ppSuggestExplicitKinds) ; checkTc (check_poly_args kind_shapes) (pp_wrong_at_tyvars $$ ppSuggestExplicitKinds) }}} Alternatively I suppose we could instead elaborate the check to allow single-constructor data types to be pattern matched as above. (Nestedly, I guess.) Alternatively, we could just make a refutable pattern into a warning. But watch out for `type F Int r r`, which demands equality. I don't know which is best. Whatever the outcome, would you like to push this through, Ryan? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 14:46:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 14:46:19 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.5988219e3e0432b584960318427ff51e@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 15:00:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 15:00:23 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.573a11c69b916b5b8227dac06869b796@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What is happening here is that `:type` is regeneralizing the type of the expression `foo`. In the regeneralized type, `a` is now properly invisible (i.e., not available for type application), which is why `:type foo` will give you `forall {a}. a` regardless of whether you declared foo with `foo = undefined` or `foo :: a; foo = undefined`. If you wish to see the type of `foo` that preserves the visibility of its type parameters, you need to use the `:type +v` GHCi command (which is currently only available in GHC HEAD): {{{ λ> let foo = undefined λ> :type +v foo foo :: forall {a}. a λ> let foo :: a; foo = undefined λ> :type +v foo foo :: forall a. a }}} So I don't think there's a GHC bug here—just slightly misleading documentation at worst. I think including a mention of `:type +v` in the users' guide section on `-XTypeApplications` might dispel this confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 15:10:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 15:10:14 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.40a2b3a2bfaedd588fb1d18dde26fbdb@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ThreeFx Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ThreeFx): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 15:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 15:25:42 -0000 Subject: [GHC] #13368: Derive superclasses automatically if possible In-Reply-To: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> References: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> Message-ID: <066.ea8cefff59301a92752b39255ee5fd5d@haskell.org> #13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- 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: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I figured there would be difficulties (`newtypes` causing trouble again via roles etc.), thanks for taking the time to respond. I'll continue thinking about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 15:26:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 15:26:48 -0000 Subject: [GHC] #13368: Derive superclasses automatically if possible In-Reply-To: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> References: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> Message-ID: <066.e3b7b8673e79d07df06f9879d7908947@haskell.org> #13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 15:35:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 15:35:51 -0000 Subject: [GHC] #13402: GHC .prof tabular output glues columns together Message-ID: <049.af44c1b3b2073af2f730a3aae46f466e@haskell.org> #13402: GHC .prof tabular output glues columns together -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After profiling an application i can see output like this: {{{ mkFareSegment Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150 88315 0.1 0.0 0.2 0.1 }}} Columns are glued together in this particular part: `Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150` It's a work project, so i won't attach the whole .prof file, but it seems that the issue occurs when the fully qualified name is too long. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 15:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 15:54:03 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.cca487a535dd0afaaa1d548929bf839d@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): The docs don't show anything for "regeneralize". What does that mean, and why does GHCi do it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:02:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:02:16 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors Message-ID: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I'll start small: Given that we know how to define various instances for [https://hackage.haskell.org/package/base-4.9.1.0/docs/Data-Functor- Product.html Product] GHC could do it automatically. {{{#!hs data P f g a = f a ::: g a deriving (Functor, Applicative, Alternative) {- instance (Applicative f, Applicative g) => Applicative (P f g) where pure x = pure x ::: pure x (f:::g) <*> (x:::y) = (f <*> x) ::: (g <*> y) -} }}} And for specific constructors as well {{{#!hs data Q a = [a] :*: Maybe a deriving (Functor, Applicative, Alternative) {- instance Applicative Q where pure x = [x] :*: Just x (f:*:g) <*> (x:*:y) = (f <*> x) :*: (g <*> y) -} }}} == Alternative == Use `GeneralizedNewtypeDeriving` {{{#!hs newtype Q a = Q (Product [] Maybe a) deriving (Functor, Applicative, Alternative) pattern (:*:) :: [a] -> Maybe a -> Q a pattern a :*: b = Q (Pair a b) }}} == Future Work == This should work for a combination of various things, using `Const _` deprives us of `Alternative` {{{#!hs newtype U e a = U (([] `Product` Maybe `Product` Const e) a) deriving (Functor, Applicative) }}} using sums where [https://hackage.haskell.org/package/transformers-0.5.4.0/docs/Control- Applicative-Lift.html one summand is identity] gives us `Applicative` / `Alternative` {{{#!hs -- data Lift f a = Pure a | Other (f a) import Control.Applicative.Lift data V a = V ((Lift [] `Product` Maybe) a) deriving (Functor, Applicative, Alternative) }}} I want to be able to write this directly {{{#!hs data U e a = U [a] (Maybe a) (Const e a) deriving (Functor, Applicative) data V a = VL a (Maybe a) | VR [a] (Maybe a) deriving (Functor, Applicative, Alternative) }}} == Future, Future Work == [https://hackage.haskell.org/package/kan-extensions-5.0.1/docs/Data- Functor-Kan-Lan.html left-Kan extension] {{{#!hs data Lan g h a where Lan :: (g b -> a) -> h b -> Lan g h a deriving (Functor, Applicative) }}} [https://hackage.haskell.org/package/kan-extensions-5.0.1/docs/Control- Monad-Codensity.html codensity] {{{#!hs data Endo a = Endo (a -> a) newtype CodEndo a = CE (forall xx. (a -> Endo xx) -> Endo xx) deriving (Functor, Applicative, Monad) }}} and [https://hackage.haskell.org/package/free-4.12.4/docs/Control-Comonad- Cofree.html comonad] {{{#!hs data Rose a = a :< [Rose a] deriving (Functor, Applicative, Monad, Comonad, ...) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:08:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:08:52 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.718976b261a745df5b6bbead08df9893@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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'm sure some derivations will be ambiguous, but some can be determined uniquely surely. Getting instances for free is such a huge strength of Haskell, it would be great to have better support for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:13:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:13:19 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.3dac54d46191c95b9ea924567dad2201@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b087aeba45a7a70a5553ef4c116ee67660423e8/ghc" 7b087ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b087aeba45a7a70a5553ef4c116ee67660423e8" Make raiseIO# produce topRes Make `raiseIO#` produce `topRes` instead of `ExnRes`. `ExnRes` leads to demand analysis being too aggressive, IMO, allowing imprecise exceptions produced by `throw` to replace exceptions thrown by `throwIO` that would like to think of as precise. This fixes that, but is certanly much more conservative than we would ideally like. Let's see how bad it is. Fixes Trac #13380 Reviewers: austin, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3301 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:13:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:13:19 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.d6d8f669e9e42b8776f2647d515b909f@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90009cf62bcebf875e68af625dbdbfc3c2f71717/ghc" 90009cf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90009cf62bcebf875e68af625dbdbfc3c2f71717" llvm backend: Put string constants in .rodata.str.* sections (#13265) The .cstring.* sections don't get merged by the linker (bfd or gold). That's bad, and especially bad in #13265 where it caused the number of sections to exceed what is apparently an internal limit in ld.bfd. Test Plan: I can only test this on Linux, and I am guessing at what the correct behavior is on Mac OS and Windows (and AIX I suppose). Testers on other platforms would be much appreciated, though I understand that the LLVM backend is broken on Mac OS currently for other reasons (#13378). Reviewers: olsner, austin, xnyhps, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3282 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:13:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:13:19 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.9fd0ddf58e9f5c95f50381ed451cc4f0@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3282 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90009cf62bcebf875e68af625dbdbfc3c2f71717/ghc" 90009cf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90009cf62bcebf875e68af625dbdbfc3c2f71717" llvm backend: Put string constants in .rodata.str.* sections (#13265) The .cstring.* sections don't get merged by the linker (bfd or gold). That's bad, and especially bad in #13265 where it caused the number of sections to exceed what is apparently an internal limit in ld.bfd. Test Plan: I can only test this on Linux, and I am guessing at what the correct behavior is on Mac OS and Windows (and AIX I suppose). Testers on other platforms would be much appreciated, though I understand that the LLVM backend is broken on Mac OS currently for other reasons (#13378). Reviewers: olsner, austin, xnyhps, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3282 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:23:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:23:30 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.9100ebd50daec2f9ce132710d5828b70@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | 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): * status: new => closed * resolution: => fixed Comment: This is now fixed, although as acknowledged in the commit message we may be able to do better in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:28:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:28:43 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.248146680c6ee509101e8fb78cea149a@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow. Did we measure the perf impact, if any? What's the nofib change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:39:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:39:49 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.1772bac64deaf7f75104ccdcfc7ca4ca@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:8 simonpj]: > Wow. We said "let's see how bad it is". Did we measure the perf impact, if any? What's the nofib change? It wasn't absolutely horrifying. /da4687f63ffe5a6162e3d7856aa53de048dd0f42 I'm benchmarking a change right now to manually strictify a few library functions that were likely affected; we'll see how that goes. BTW, did you see my note on the insufficiency of the note on the I/O hack in the demand analyzer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 16:41:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 16:41:10 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.2ea9ee8493997f8d536575dcc4726249@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11450 | Differential Rev(s): Phab:D3302 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3302 Comment: I think your first proposal (simply omitting those two checks) would be ideal. I've implemented that in Phab:D3302. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 17:01:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 17:01:31 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.7355ba70d7e68dfbd26e12689c6c3409@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11376, #11975 Comment: What prompted this is chronicled in #11376 (particularly from [https://ghc.haskell.org/trac/ghc/ticket/11376#comment:15 comment:15] onward). It was discovered that when `:type` was used with a visibly applied type, you could get some weird results, like this one: {{{ λ> import GHC.Generics λ> :type datatypeName @('MetaData "Void" "Data.Void" "base" 'False) datatypeName @('MetaData "Void" "Data.Void" "base" 'False) :: Datatype ('MetaData "Void" "Data.Void" "base" 'False) => forall k1 (t :: Meta -> (k1 -> *) -> k1 -> *) (f :: k1 -> *) (a :: k1). t ('MetaData "Void" "Data.Void" "base" 'False) f a -> [Char] }}} Before, `:type` was instantiating constraints lazily, which is why that `Datatype` constraint is still lingering around in the type that `:type` infers above, even though `'MetaData "Void" "Data.Void" "base" 'False` should discharge that constraint. simonpj thought this was ghastly and changed the behavior of `:type` to //deeply// instantiate the inferred type (i.e., solve constraints as much as possible) and re-generalize afterwards. (Note: "generalize" comes from a rule in Hindley–Milner type inference, I believe, where you infer a type of the form `forall a. ...`). After this change, you get this instead: {{{ λ> :type datatypeName @('MetaData "Void" "Data.Void" "base" 'False) datatypeName @('MetaData "Void" "Data.Void" "base" 'False) :: t ('MetaData "Void" "Data.Void" "base" 'False) f a -> [Char] }}} which is certainly nicer to look at. But it comes at a downside: deep instantiation followed by re-generalization can change the visibilities of type parameters, which explains the behavior you reported originally in this ticket. To work around this, goldfire introduced `:type +v` in #11975, which gives you the original lazy instantiation behavior that `:type` used to have. OK, that ended being a much lengthier explanation that I'd hoped for. Hopefully, you understand the context of this a little better. My question to you is now: how should we update the users' guide to explain this wrinkle? I'm a bit reluctant to include a crash-course on HM type inference, but maybe there's an instructive way to give the highlights of this discussion to readers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 17:16:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 17:16:24 -0000 Subject: [GHC] #1106: During install, network's Typeable.h clobbers base's copy In-Reply-To: <042.6b8617b5e225debe6fc7e14d0f8fae6f@haskell.org> References: <042.6b8617b5e225debe6fc7e14d0f8fae6f@haskell.org> Message-ID: <057.280b194e88d75f637a7d1a9507d08dc0@haskell.org> #1106: During install, network's Typeable.h clobbers base's copy -------------------------------------+--------------------------------- Reporter: bos | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: -------------------------------------+--------------------------------- Changes (by Joachim Breitner ): * failure: => None/Unknown Comment: In [changeset:"712c45d035797a392e33bba3f8ec4293af61ecab/ghc" 712c45d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="712c45d035797a392e33bba3f8ec4293af61ecab" integerConstantFolding: no longer broken with -DDEBUG (#1106) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 18:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 18:00:07 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.fb8c4d3db401135318cf2360362c1797@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I **really** appreciate your explanation. I frequently use GHCi to learn about my program, and it's extremely unhelpful when it lies to me (see [http://chat.stackoverflow.com/transcript/message/35984292#35984292 this] for another example.) Therefore it seems like type application visibility information should ''only'' be displayed with lazy constraint instantiation, i.e., when the `+v` option is used. Then there's no convoluted explanation needed, and more importantly, you will always get correct information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 18:41:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 18:41:05 -0000 Subject: [GHC] #13402: GHC .prof tabular output glues columns together In-Reply-To: <049.af44c1b3b2073af2f730a3aae46f466e@haskell.org> References: <049.af44c1b3b2073af2f730a3aae46f466e@haskell.org> Message-ID: <064.11351a288b09c3c6df616230db537249@haskell.org> #13402: GHC .prof tabular output glues columns together -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dredozubov: Old description: > After profiling an application i can see output like this: > > > {{{ > mkFareSegment > Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150 > 88315 0.1 0.0 0.2 0.1 > > }}} > > Columns are glued together in this particular part: > `Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150` > > It's a work project, so i won't attach the whole .prof file, but it seems > that the issue occurs when the fully qualified name is too long. New description: After profiling an application i can see output like this: {{{ mkFareSegment Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150 88315 0.1 0.0 0.2 0.1 }}} Columns are glued together in this particular part: `Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150` It seems that the issue occurs when the fully qualified name is too long. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 18:43:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 18:43:42 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.ea91370fdffc6fd8cec12b8103777dc5@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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 RyanGlScott): This feels extremely //ad hoc// and not nearly formalized enough to where I'd be comfortable with it. One nice thing about `deriving` is that it tends to work with ~90% of the datatypes you'd use regularly, but with this proposal, it feels closer to <50%. I have no idea how you could teach GHC to recognize "product types" in a way that's uniform and comprehensive. What happens when there are more than two fields? What happens when you have arbitrary nestings of types like `data Product f g h a = Product (f (g (f a))) (h (f (g a)))`? What if there are constants like `data Product a = Product Int a`? But I'm even more concerned about what this proposed feature would do on things that //aren't// of the particular form that you've labeled "product types". What happens with: * `newtype Compose f g a = Compose (f (g a))` * `data Proxy a = Proxy` and so on? What would the error messages be like in cases where it wouldn't work? I'm quite skeptical that this could be made workable. -1 from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 19:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 19:14:37 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.182415556953cb48d66512ac9b1271dc@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's not that the information that `:type` gives is wrong, it's just not what you're asking for. `:type foo` gives you the visibility of `foo` as an expression post-typechecking. This can be quite handy when you have, say: {{{ λ> let foo :: a; foo = undefined λ> :type foo @Int foo @Int :: Int λ> :type foo foo :: forall {a}. a λ> let goo = foo λ> :type goo goo :: forall {a}. a λ> :type goo @Int }}} Notice that you can't use VTA with `goo`, since its type (which is the same as `foo`, post-typechecking) doesn't have any visible type variables. This is precisely what `:type foo` warned us about, and I'd hate to cripple a legitimately useful feature for the benefit of a degenerate case. My suggestion would be to include a blurb in the users' guide section that gives an example of asking GHCi for the visibility of a top-level expression (using `:type +v`), and then show the pitfalls of using `:type`. Would you be satisfied with that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 19:32:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 19:32:59 -0000 Subject: [GHC] #13404: Derive instances for classes with associated types Message-ID: <051.fee0f935ad4a4e93c7efcd85362fefec@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- When trying to derive an instance of a class with associated types {{{#!hs import Data.Distributive import Data.Functor.Rep data Pair a = a :# a deriving Functor instance Distributive Pair where distribute :: Functor f => f (Pair a) -> Pair (f a) distribute = distributeRep instance Representable Pair where type Rep Pair = Bool index :: Pair a -> (Bool -> a) index (a :# _) False = a index (_ :# b) True = b newtype PAIR a = PAIR (Pair a) deriving (Functor, Representable) instance Distributive PAIR where distribute = {- distributeRep -} }}} {{{ • Can't make a derived instance of ‘Representable PAIR’ (even with cunning GeneralizedNewtypeDeriving): the class has associated types • In the newtype declaration for ‘PAIR’ }}} But it could create an instance {{{#!hs instance Representable PAIR where type Rep PAIR = Bool index :: forall a. PAIR a -> (Bool -> a) index = coerce (index :: Pair a -> (Bool -> a)) }}} Same with complicated expressions like {{{#!hs infixr 9 · type (·) = Compose newtype P f g h a = P (Product (f·g·f) (h·f·g) a) deriving (Functor, Foldable, Traversable, Applicative, Alternative, Distributive) instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Distributive (P f g h) where distribute = distributeRep instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Representable (P f g h) where type Rep (P f g h) = Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) index :: (P f g h) a -> (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) index = coerce (index @(Product (f·g·f) (h·f·g))) tabulate :: (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) -> (P f g h) a tabulate = coerce (tabulate @(Product (f·g·f) (h·f·g))) }}} Is this too limited to work on general -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 19:33:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 19:33:19 -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.b151954c63bfc0c17f88580434336499@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > When trying to derive an instance of a class with associated types > > {{{#!hs > import Data.Distributive > import Data.Functor.Rep > > data Pair a = a :# a > deriving Functor > > instance Distributive Pair where > distribute :: Functor f => f (Pair a) -> Pair (f a) > distribute = distributeRep > > instance Representable Pair where > type Rep Pair = Bool > > index :: Pair a -> (Bool -> a) > index (a :# _) False = a > index (_ :# b) True = b > > newtype PAIR a = PAIR (Pair a) > deriving (Functor, Representable) > > instance Distributive PAIR where > distribute = {- distributeRep -} > }}} > > {{{ > • Can't make a derived instance of ‘Representable PAIR’ > (even with cunning GeneralizedNewtypeDeriving): > the class has associated types > • In the newtype declaration for ‘PAIR’ > }}} > > But it could create an instance > > {{{#!hs > instance Representable PAIR where > type Rep PAIR = Bool > > index :: forall a. PAIR a -> (Bool -> a) > index = coerce (index :: Pair a -> (Bool -> a)) > }}} > > Same with complicated expressions like > > {{{#!hs > infixr 9 · > type (·) = Compose > > newtype P f g h a = P (Product (f·g·f) (h·f·g) a) > deriving (Functor, Foldable, Traversable, Applicative, Alternative, > Distributive) > > instance (Functor f, Functor g, Functor h, > Representable f, Representable g, Representable h) > => Distributive (P f g h) where > distribute = distributeRep > > instance (Functor f, Functor g, Functor h, > Representable f, Representable g, Representable h) > => Representable (P f g h) where > type Rep (P f g h) = Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep > g)) > > index :: (P f g h) a -> (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, > Rep g)) -> a) > index = coerce (index @(Product (f·g·f) (h·f·g))) > > tabulate :: (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> > a) -> (P f g h) a > tabulate = coerce (tabulate @(Product (f·g·f) (h·f·g))) > }}} > > Is this too limited to work on general New description: When trying to derive an instance of a class with associated types {{{#!hs import Data.Distributive import Data.Functor.Rep data Pair a = a :# a deriving Functor instance Distributive Pair where distribute :: Functor f => f (Pair a) -> Pair (f a) distribute = distributeRep instance Representable Pair where type Rep Pair = Bool index :: Pair a -> (Bool -> a) index (a :# _) False = a index (_ :# b) True = b newtype PAIR a = PAIR (Pair a) deriving (Functor, Representable) instance Distributive PAIR where distribute = {- distributeRep -} }}} {{{ • Can't make a derived instance of ‘Representable PAIR’ (even with cunning GeneralizedNewtypeDeriving): the class has associated types • In the newtype declaration for ‘PAIR’ }}} But it could create an instance {{{#!hs instance Representable PAIR where type Rep PAIR = Bool index :: forall a. PAIR a -> (Bool -> a) index = coerce (index :: Pair a -> (Bool -> a)) }}} Same with complicated expressions like {{{#!hs infixr 9 · type (·) = Compose newtype P f g h a = P (Product (f·g·f) (h·f·g) a) deriving (Functor, Foldable, Traversable, Applicative, Alternative, Distributive) instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Distributive (P f g h) where distribute = distributeRep instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Representable (P f g h) where type Rep (P f g h) = Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) index :: (P f g h) a -> (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) index = coerce (index @(Product (f·g·f) (h·f·g))) tabulate :: (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) -> (P f g h) a tabulate = coerce (tabulate @(Product (f·g·f) (h·f·g))) }}} Is this too limited to work in general -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 19:37:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 19:37:16 -0000 Subject: [GHC] #4083: Generalized newtype deriving fails for newtypes that are type family instances In-Reply-To: <062.6f5b77e0132a6ddd2b908823adf5bf5a@haskell.org> References: <062.6f5b77e0132a6ddd2b908823adf5bf5a@haskell.org> Message-ID: <077.b4b61deeef3d598153cec5890a2a6831@haskell.org> #4083: Generalized newtype deriving fails for newtypes that are type family instances -------------------------------------+------------------------------------- Reporter: RANDY Ruler of | Owner: (none) Zexernet | Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): For type families see #13404 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 19:37:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 19:37:31 -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.0ac8068df3841f8251396dd0f53a43fd@haskell.org> #13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- 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: #4083 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #4083 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 19:44:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 19:44:56 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.709f2d3b415d6745957a156bc44e3222@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): The reason I feel that GHCi is giving me incorrect info is due to the existing documentation that I quoted above. Basically, my understanding is that if `foo :: forall {k} . k` then GHCi should throw an error if I try to write `foo @Int`, and if `foo :: forall k . k`, then GHCi should happily accept `foo @Int`. When I see `foo :: forall {k} . k`, but GHCi also lets me write `foo @Int`, I have no idea what it means by `{k}`. This seems like a contradiction. I get the impression from your comments that there's something more subtle going on here that I don't understand. If you think others might have the same misconception as me, I would encourage you to improve the existing docs as well. In regards to your suggestion, I think it would be good to put a blurb in the Visible Type Application section (9.18 by my count) as well, near the "detail" note that explains the curly braces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 20:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 20:04:39 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.c2f9326b3668e61b7162341fbe182a0c@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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): Thanks for taking the time to respond to my proposals Replying to [comment:2 RyanGlScott]: > This feels extremely //ad hoc// and not nearly formalized enough to where I'd be comfortable with it. At least it gets a reaction :) the proposal was but we can go into the direction of [https://hackage.haskell.org/package/base-4.9.1.0/docs/GHC- Generics.html#t:Rep Generic's Rep] > I have no idea how you could teach GHC to recognize "product types" It's not just for product types, I should have made myself more clear but I didn't want to complicate the proposal. This should work for our entire polynomial arsenal, `Sum`, `Product`, `Identity`, `Const _`, when we get to weirder things like [https://hackage.haskell.org/package/bifunctors-5.4.1/docs/Data-Bifunctor- Biff.html Biff] things start to collide. Maybe it's a matter of picking a comfortable subset. > `data Product f g h a = Product (f (g (f a))) (h (f (g a)))`? That could be encoded as ↓ and we can still derive a whole host of instances {{{#!hs infixr 9 · type (·) = Compose newtype P f g h a = P (Product (f · g · f) (h · f · g) a) deriving (Functor, Foldable, Traversable, Applicative, Alternative, Contravariant) }}} In any case it could be implemented incrementally. > What if there are constants like `data Product a = Product Int a`? They could always be rewritten as (I changed `Int` to `String` to get that `Applicative` instance) {{{#!hs newtype Q a = Q (Product (Const String) Identity a) deriving (Functor, Foldable, Traversable, Applicative) }}} > > * `newtype Compose f g a = Compose (f (g a))` > * `data Proxy a = Proxy` `Compose` and `Proxy` would likely be primitives in what ever subset of types we support. Are there other discussions about something similar? Or is this the first time this is proposed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 20:26:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 20:26:41 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.8690448e98c4276c750d0845b7b443ba@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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 RyanGlScott): Replying to [comment:3 Iceland_jack]: > At least it incites a reaction :) the proposal was but we can go into the direction of [https://hackage.haskell.org/package/base-4.9.1.0/docs /GHC-Generics.html#t:Rep Generic's Rep] Funny enough, I was going recommend exactly `GHC.Generics` as a solution to your problem. It gives you the power to exclude awkward subsets of datatypes (e.g., no `Monad` instances for `Compose`-like things), and it requires no changes to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 20:38:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 20:38:35 -0000 Subject: [GHC] #13366: addCStub doesn't allow control over compiler flags or source file file In-Reply-To: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> References: <046.e4d0ff069ca721205cf186e478fec23b@haskell.org> Message-ID: <061.ddc13326834455bc7b5ca6c61a08fccb@haskell.org> #13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: high | 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:D3280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I think the currently situation is good enough for now. Phab:D3280 was merged in 0fac488cca04a07224926e35be9c45ee2d0e1631. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 23:33:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 23:33:48 -0000 Subject: [GHC] #13405: Reimplement unsafeInterleaveIO using runRW# Message-ID: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> #13405: Reimplement unsafeInterleaveIO using runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.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: -------------------------------------+------------------------------------- Currently, we have {{{#!hs {-# INLINE unsafeInterleaveIO #-} unsafeInterleaveIO :: IO a -> IO a unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) {-# NOINLINE unsafeDupableInterleaveIO #-} unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO ( \ s -> let r = case m s of (# _, res #) -> res in (# s, r #)) }}} This all seems a bit weird from a semantic standpoint, and also seems likely to get in the way of the best idea I have so for for converting precise exceptions to imprecise ones in unsafe functions. === The substantial semantic weirdness === `unsafeDupableInterleaveIO` takes the current state of the world, `s`, and passes it to `m`. But it passes it to `m` at some time when the actual real world has most likely moved on! That is, we pass `m` a moment of the ''past''. Strange indeed. === The exception handling matter === I would like to separate precise exceptions (thrown using `raiseIO#`) from imprecise ones (thrown using `raise#`). In particular, I want to offer an operation that catches only precise exceptions. But `unsafePerformIO` and `unsafeInterleaveIO` and such need to convert precise exceptions into imprecise ones to avoid breaking the more aggressive demand analysis of the hypothetical `catchThrowIO`. === The fix === I believe the fix is pretty simple: rather than holding a piece of the past in our pocket, start a new timeline: {{{#!hs unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO (\ s -> (# s, runRW# (\s2 -> case m s2 of (# _, res #) -> res) #)) }}} This seems to me to get the point across a lot better, and it ''may'' even allow us to remove the `NOINLINE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 23:34:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 23:34:12 -0000 Subject: [GHC] #13405: Reimplement unsafeInterleaveIO using runRW# In-Reply-To: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> References: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> Message-ID: <060.98cb42842323050088fc031e204ba928@haskell.org> #13405: Reimplement unsafeInterleaveIO using runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 23:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 23:47:51 -0000 Subject: [GHC] #13405: Reimplement unsafeInterleaveIO using runRW# In-Reply-To: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> References: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> Message-ID: <060.e94a8eed9495e1e7f400e045a0c78357@haskell.org> #13405: Reimplement unsafeInterleaveIO using runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > Currently, we have > > {{{#!hs > {-# INLINE unsafeInterleaveIO #-} > unsafeInterleaveIO :: IO a -> IO a > unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) > > {-# NOINLINE unsafeDupableInterleaveIO #-} > unsafeDupableInterleaveIO :: IO a -> IO a > unsafeDupableInterleaveIO (IO m) > = IO ( \ s -> let > r = case m s of (# _, res #) -> res > in > (# s, r #)) > }}} > > This all seems a bit weird from a semantic standpoint, and also seems > likely to get in the way of the best idea I have so for for converting > precise exceptions to imprecise ones in unsafe functions. > > === The substantial semantic weirdness === > > `unsafeDupableInterleaveIO` takes the current state of the world, `s`, > and passes it to `m`. But it passes it to `m` at some time when the > actual real world has most likely moved on! That is, we pass `m` a moment > of the ''past''. Strange indeed. > > === The exception handling matter === > > I would like to separate precise exceptions (thrown using `raiseIO#`) > from imprecise ones (thrown using `raise#`). In particular, I want to > offer an operation that catches only precise exceptions. But > `unsafePerformIO` and `unsafeInterleaveIO` and such need to convert > precise exceptions into imprecise ones to avoid breaking the more > aggressive demand analysis of the hypothetical `catchThrowIO`. > > === The fix === > > I believe the fix is pretty simple: rather than holding a piece of the > past in our pocket, start a new timeline: > > {{{#!hs > unsafeDupableInterleaveIO :: IO a -> IO a > unsafeDupableInterleaveIO (IO m) > = IO (\ s -> > (# s, runRW# (\s2 -> case m s2 of (# _, res #) -> res) #)) > }}} > > This seems to me to get the point across a lot better, and it ''may'' > even allow us to remove the `NOINLINE`. New description: Currently, we have {{{#!hs {-# INLINE unsafeInterleaveIO #-} unsafeInterleaveIO :: IO a -> IO a unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) {-# NOINLINE unsafeDupableInterleaveIO #-} unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO ( \ s -> let r = case m s of (# _, res #) -> res in (# s, r #)) }}} This all seems a bit weird from a semantic standpoint, and also seems likely to get in the way of the best idea I have so for for converting precise exceptions to imprecise ones in unsafe functions. === The substantial semantic weirdness === `unsafeDupableInterleaveIO` takes the current state of the world, `s`, and passes it to `m`. But it passes it to `m` at some time when the actual real world has most likely moved on! That is, we pass `m` a moment of the ''past''. Strange indeed. === The exception handling matter === I would like to separate precise exceptions (thrown using `raiseIO#`) from imprecise ones (thrown using `raise#`). In particular, I want to offer an operation that catches only precise exceptions. But `unsafePerformIO` and `unsafeInterleaveIO` and such need to convert precise exceptions into imprecise ones to avoid breaking the more aggressive demand analysis of the hypothetical `catchThrowIO`. The most obvious place to do this seems likely to be `runRW#`, but we need to be sure to use that everywhere we need the shift. === The fix === I believe the fix is pretty simple: rather than holding a piece of the past in our pocket, start a new timeline: {{{#!hs unsafeDupableInterleaveIO :: IO a -> IO a unsafeDupableInterleaveIO (IO m) = IO (\ s -> (# s, runRW# (\s2 -> case m s2 of (# _, res #) -> res) #)) }}} This seems to me to get the point across a lot better, and it ''may'' even allow us to remove the `NOINLINE`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 9 23:49:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Mar 2017 23:49:18 -0000 Subject: [GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors In-Reply-To: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> References: <051.02a8b4ba80e2b52b62ea942f7993f4dd@haskell.org> Message-ID: <066.e3c872e1e966b2da00ddff8f28ddd775@haskell.org> #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- 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 RyanGlScott): Moreover, it wouldn't take much code at all to set up the machinery needed to do this: {{{#!hs {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleContexts #-} module DeriveApplicativeMonad where import GHC.Generics -- Applicative genericPure :: (Generic1 f, Applicative (Rep1 f)) => a -> f a genericPure = to1 . pure genericAp :: (Generic1 f, Applicative (Rep1 f)) => f (a -> b) -> f a -> f b genericAp f x = to1 $ from1 f <*> from1 x -- Monad genericBind :: (Generic1 m, Monad (Rep1 m)) => m a -> (a -> m b) -> m b genericBind m f = to1 $ from1 m >>= from1 . f -- Example data Product f g h a = Product (f (g (f a))) (h (f (g a))) deriving (Functor, Generic1) instance (Applicative f, Applicative g, Applicative h) => Applicative (Product f g h) where pure = genericPure (<*>) = genericAp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 00:02:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 00:02:56 -0000 Subject: [GHC] #13406: IO hack in demand analyzer can miss I/O Message-ID: <045.2a78b8f8fd9843a4b2ea054ce2d97f51@haskell.org> #13406: IO hack in demand analyzer can miss I/O -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- If someone digs into the `IO` type, they could (with good reason, even!) decide that they want to produce something other than an unboxed pair. Here's an example, imitating `StateT st IO a` in a way that's sure to be unboxed well: {{{#!hs newtype IOState st a = IOState { unIOState :: State# RealWorld -> st -> (# State# RealWorld, st, a #) } }}} This won't trip `io_hack_reqd`, so demand analysis won't see it as I/O, and everything will be wrong. Urk. Furthermore, in the future, we may allow newtypes around unlifted types, in which case this stuff gets even messier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 00:34:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 00:34:21 -0000 Subject: [GHC] #13378: ghc-stage2 broken for quick-llvm In-Reply-To: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> References: <047.6398a672bf9fd46b39701222a0eefc74@haskell.org> Message-ID: <062.941d2104a6675d2fb4943f52893cffc4@haskell.org> #13378: ghc-stage2 broken for quick-llvm -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): As Reid said, in https://phabricator.haskell.org/D3287 we mangled away the `.subsections_via_symbols`. (8.2) https://phabricator.haskell.org/D3290 should drop the requirement for the mangling step, by marking everything .no_dead_strip. (8.4). Finally once https://reviews.llvm.org/D30770, lands in llvm (5), we might be able to drop all this hackery completely. Unless we run into issues with out symbol aliasing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 01:58:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 01:58:27 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.48dd9b5c1317497f8b23c4cd0149fc1f@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with Ryan's explanations. `:type expr` gives you the type that would be assigned to `x` if you say `let x = expr`. `:type +v expr` gives you the type of `expr`. One challenge here is that `foo` ''does'' have type `forall {k}. k`. It also has type `forall k. k`. It also has type `Int`. One challenge in a type system like Haskell's is that an expression has many types. All this said, I do agree with @crockeea's suggestions to clarify the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 02:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 02:02:23 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.063c6d46eb94ed3b8651f28f96dda51b@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): One more point to make about GHCi's lies: when GHCi doesn't lie, [https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html outrage ensues]. That debate shows that beginners (and, indeed, most Haskellers doing routine Haskelling) can't handle the truth. My point here is that lying is not always undesired behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 02:30:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 02:30:31 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.ae867e321d1e82567f7376df81c47fe0@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): This is all expected behavior, for a sufficiently nuanced expectation. This behavior may be undocumented however, which would be a bug. The problem all boils down to this: '''there are no type-level lambdas.''' When GHC transforms the term-level `f :: forall a. Int -> a -> a` to have type `Int -> forall a. a -> a`, it does this by generating the Core `\(n :: Int) @(a :: *) -> f a n`, which indeed works with `f` of the given type and is an expression of the desired type. Note that there is a lambda there. This is impossible at the type level. Thus: type-level `forall`s don't "float". The output from `:i` in comment:5 is an unrelated (but quite legitimate) bug. The `Foo`/`Goo` example comes from a nice rule around higher-rank types/kinds: '''GHC never infers a higher-rank type''' (or kind). So, the first (non-higher-rank) example with `Foo`/`Goo` succeeds. The second fails, because GHC won't infer a higher-rank kind for `Goo`. If you make a complete user-specified kind signature by putting a top-level kind signature on the right-hand side of the `Goo` declaration, GHC will accept, as it no longer needs to infer a higher-rank kind. At the term level, GHC makes an exception to the never-infer-higher-rank rule: when a term-level definition is by only one equation, and there is no type signature, GHC computes the (potentially higher-rank) type of the RHS and uses it as the type of the LHS. So, it's really the term level that's behaving strangely by accepting `goo2`, not the type level. Looking at this all, it seems sensible to propagate this exception to `type` declarations, which are required to obey the one-equation rule used at the term level. Admittedly, the lack of "floating" makes higher-rank kinds unwieldy. I do have a second use-case though: {{{ data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a class HTestEquality (t :: forall k. k -> Type) where hTestEquality :: t a -> t b -> Maybe (a :~~: b) data TypeRep (a :: k) where -- or, this could be the new proper Data.Reflection.TypeRep TInt :: TypeRep Int TMaybe :: TypeRep Maybe TApp :: TypeRep a -> TypeRep b -> TypeRep (a b) instance HTestEquality TypeRep where hTestEquality TInt TInt = Just HRefl hTestEquality TMaybe TMaybe = Just HRefl hTestEquality (TApp a1 b1) (TApp a2 b2) = do HRefl <- hTestEquality a1 a2 HRefl <- hTestEquality b1 b2 return HRefl hTestEquality _ _ = Nothing }}} The need for this came up while experimenting with (prototypes of) the new `TypeRep`. See also [https://github.com/goldfirere/dependent- db/blob/master/Basics.hs#L134 this related example], necessary to power the dependently typed database example I used in my job talk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 02:49:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 02:49:57 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.8ac71163f6c1f975dac26aa94539f9e5@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Phab:3310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:3310 Comment: I've submitted Phab:D3310, which attempts to spruce up the documentation pertaining to this section of the users' guide. crockeea, goldfire, do you mind giving it a read and seeing if it makes sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:07:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:07:50 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.abcf16eba6546af3752e821911a8d03f@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:07:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:07:57 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.bc715ee112491ddac4b87cf0bd8b67cf@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer, | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't think this is quite so easy. The old check needed to tell the difference between types and kinds. We can't do that anymore! It is a shame that this happens though. If no one gets there first, I'll fix this in my `TypeInType` bug sweep this summer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:10:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:10:41 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.9a0a37d234f70a22981399c5f38bec93@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: newcomer, | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 goldfire]: > I don't think this is quite so easy. The old check needed to tell the difference between types and kinds. We can't do that anymore! Ah, good point. I'll remove the "newcomer" label so that we don't accidentally lead a new GHC contributor down a rabbit hole they can't climb back out of (something which has happened to me more times than I care to admit). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:17:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:17:27 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.a6c72001319d151c1577e5206561d79a@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: newcomer, TypeInType => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:22:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:22:26 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.58bab789b17f25ec4f1ad6d377653d8f@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): Thanks Richard, that's a tremendously helpful explanation. So to recap, there are three bugs: * crockeea was unable to figure out that this is expected behavior. We should document this behavior of higher-rank kinds. * There is a bug in how higher-rank kinds are pretty-printed (comment:5) * Type synonyms don't obey the "one-equation-rule" (as defined in comment:6) Should we open separate tickets for the last two? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:23:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:23:55 -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.8d339ab8945b7fbfad7d64a6996e5640@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 jberryman): Still looking into this slowly when I have time. It looks like this is a regression between ghc-7.10 and 8.0.1 at least. Here e.g. `# 50 lines` etc refers to 50 lines of {{{ f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> f bs >> }}} With ghc 7.10 this looks slow but linear: {{{ jberryman /tmp/again » time ghc-7.10.3 -fforce-recomp -O2 Main.hs # 25 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc-7.10.3 -fforce-recomp -O2 Main.hs 0.90s user 0.09s system 97% cpu 1.018 total jberryman /tmp/again » time ghc-7.10.3 -fforce-recomp -O2 Main.hs # 50 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc-7.10.3 -fforce-recomp -O2 Main.hs 1.59s user 0.13s system 98% cpu 1.744 total jberryman /tmp/again » time ghc-7.10.3 -fforce-recomp -O2 Main.hs # 100 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc-7.10.3 -fforce-recomp -O2 Main.hs 3.87s user 0.25s system 99% cpu 4.146 total }}} And in 8.0 we have a regression and what looks like worse asymptotics: {{{ jberryman /tmp/again » time ghc -fforce-recomp -O2 Main.hs # 25 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc -fforce-recomp -O2 Main.hs 2.41s user 0.15s system 99% cpu 2.583 total jberryman /tmp/again » time ghc -fforce-recomp -O2 Main.hs # 50 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc -fforce-recomp -O2 Main.hs 7.36s user 0.21s system 99% cpu 7.586 total jberryman /tmp/again » time ghc -fforce-recomp -O2 Main.hs # 100 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc -fforce-recomp -O2 Main.hs 27.99s user 0.45s system 99% cpu 28.463 total jberryman /tmp/again » time ghc -fforce-recomp -O2 Main.hs # 200 lines [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... ghc -fforce-recomp -O2 Main.hs 122.58s user 6.40s system 84% cpu 2:33.50 total }}} Also attached profiles using the ghc library via https://gist.github.com/nominolo/d18efaabf3e074d03969 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:24:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:24:34 -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.393d6ebd6cf37e715f5d554ac8799435@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 jberryman): * Attachment "ghc-wrap.hy.7.10.pdf" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:24:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:24:48 -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.0a2ab4e68fa17445aae439adfdb2ae52@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 jberryman): * Attachment "ghc-wrap.h.7.10.pdf" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:25:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:25:03 -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.d9f57375748be83ba706eb408a9f61a0@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 jberryman): * Attachment "ghc-wrap.hy.8.0.pdf" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 03:25:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 03:25: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.49f7620f4f91c3402f4dd8e2925a7571@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 jberryman): * Attachment "ghc-wrap.h.8.0.pdf" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 04:12:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 04:12:10 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule In-Reply-To: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> References: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> Message-ID: <060.aec2ad6c151846c84578723992acb1c7@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): To be clear, the `opt_univ fell into a hole` bit is a red herring here. The real problem is that the type-checker doesn't reject the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 04:13:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 04:13:48 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.a7890f83197068957a77fb7e7f01b7d8@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 suppose you're implying that this ticket become the first bullet. Then, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 07:23:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 07:23:03 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e73ff44dba8f2d84d698f0650dc5f16c@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): I'd really like to see some documents on how `UnliftedFFITypes` interact with GC and an `unsafe` FFI call. According to my understanding, passing `ByteArray#` is safe here because GC can't happen during an `unsafe` call. Am i right on this? Or perhaps RTS do some thing else to prevent GC move the `ByteArray#` during FFI when `UnliftedFFITypes` enable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:07:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:07:06 -0000 Subject: [GHC] #13357: Check demand signatures for catchRetry# and catchSTM# In-Reply-To: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> References: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> Message-ID: <060.8a44a9656145b968697c625cf15f76f8@haskell.org> #13357: Check demand signatures for catchRetry# and catchSTM# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | 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): Phab:D3263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:07:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:07:26 -0000 Subject: [GHC] #13348: Consider making throw and throwIO strict In-Reply-To: <045.a5abd3b4410092f9c7aec0b840de925c@haskell.org> References: <045.a5abd3b4410092f9c7aec0b840de925c@haskell.org> Message-ID: <060.6f60cb9f18edd4bcb3107bbd13be57b6@haskell.org> #13348: Consider making throw and throwIO strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: wontfix | 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 simonpj): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:08:18 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.f3f5ad08ba6946f9936ec1abb4f56e48@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Exceptions 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:D1973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:09:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:09:17 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.5dd466db3621f341427eef9278060573@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Exceptions 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: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:09:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:09:49 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.c6f5cb62b1e691b1467bd0403d7822a2@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): OK: please put the nfib results here. And check that we still get the improvements reported in #11222 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:10:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:10:27 -0000 Subject: [GHC] #13384: Windows build thinks sqrt (-1) == -1 In-Reply-To: <046.609524b4d023b0557873a020ac7b7847@haskell.org> References: <046.609524b4d023b0557873a020ac7b7847@haskell.org> Message-ID: <061.fa3036cf939a2f89094ba75d9c278697@haskell.org> #13384: Windows build thinks sqrt (-1) == -1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This should be resolved in 06c8ce449f7c89eeafe4f9a6e8c545272327f528. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:13:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:13:02 -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.cd9cdd56cabec6be658b65a8154bcf80@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by angerman): Replying to [comment:9 dobenour]: > I think that we should run loop unswitching early in the pipeline, to remove redundant heap/stack checks. > > How can we track aliasing information better? > > LLVM supports dereferencable annotations. Those might be able to help. The Data.Bitcode stuff I wrote doesn't need the aliasing anymore. However another option would be to teach cmm lable types or not take of from cmm, but stg. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:16:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:16:20 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.ea0c9b72eb6dfd7b658a4d2c68b6e14d@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D3315 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:19:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:19:28 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.a26ff4ab25d9649eb2143dfea30f75ec@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.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 simonpj): * priority: normal => high * status: closed => new * resolution: fixed => Comment: Re-opening to ensure that we do check those perf numbers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:20:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:20:45 -0000 Subject: [GHC] #13407: Fix printing of higher-rank kinds Message-ID: <047.e0e70f9dcf452b0789ae502f43b96326@haskell.org> #13407: Fix printing of higher-rank kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Witness this GHCi session: {{{ rae:09:18:37 ~/ghc/ghc> ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType -XRankNTypes Prelude> import Data.Kind Prelude Data.Kind> data Foo :: (* -> *) -> (forall k. k -> *) Prelude Data.Kind> :info Foo type role Foo phantom nominal phantom data Foo (a :: * -> *) k (c :: k) -- Defined at :3:1 }}} The output from `:info` is terrible, treating `k` as a visible parameter when it isn't. This is spun off from #13399 but is not tightly coupled to that ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:27:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:27:28 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms Message-ID: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In terms, a definition comprising one non-recursive equation may have a higher-rank type inferred. For example: {{{#!hs f :: (forall a. a -> a -> a) -> Int f z = z 0 1 g = f }}} `g` gets an inferred type equal to `f`'s. However, this fails at the type level: {{{#!hs type F (z :: forall a. a -> a -> a) = z 0 1 type G = F }}} If anything is strange here, it's that the term-level definition is accepted. GHC should not be in the business of inferring higher-rank types. But there is an exception for definitions comprising one non- recursive equation. This ticket proposes expanding this behavior to the type level, allowing `G` to be accepted. This is spun off from #13399, but is not tightly coupled to that ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:28:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:28:09 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs In-Reply-To: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> References: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> Message-ID: <061.c8b4a8bdfa58f76136614d411934ba2c@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): WIP differentials: - https://phabricator.haskell.org/D3313 (ghc) - https://phabricator.haskell.org/D3314 (hsc2hs) Note: the new pragma will be just `{-# COLUMN 12345 #-}`, because it’s simpler for both ghc and hsc2hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:37:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:37:20 -0000 Subject: [GHC] #13409: Data types with higher-rank kinds are pretty-printed strangely Message-ID: <050.defb28fdc2d005f76d18a35e2f589a7a@haskell.org> #13409: Data types with higher-rank kinds are pretty-printed strangely -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13399 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First observed in https://ghc.haskell.org/trac/ghc/ticket/13399#comment:5. If you define this: {{{#!hs data Foo :: (* -> *) -> (forall k. k -> *) }}} and type `:i Foo` into GHCi, you get this back: {{{ type role Foo phantom nominal phantom data Foo (a :: * -> *) k (c :: k) }}} This seems to imply that Foo has three visible type parameters, which isn't true at all! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:41:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:41:12 -0000 Subject: [GHC] #13409: Data types with higher-rank kinds are pretty-printed strangely In-Reply-To: <050.defb28fdc2d005f76d18a35e2f589a7a@haskell.org> References: <050.defb28fdc2d005f76d18a35e2f589a7a@haskell.org> Message-ID: <065.336e738af1d2d01025a4bd9421b2945b@haskell.org> #13409: Data types with higher-rank kinds are pretty-printed strangely -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: I beat you to it: #13407. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 14:41:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 14:41:42 -0000 Subject: [GHC] #13399: Location of `forall` matters with higher-rank kind polymorphism In-Reply-To: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> References: <047.7cefe164bc115abcb9ab6b549f09b5d0@haskell.org> Message-ID: <062.949101cf4d69454f2ed22bba107a9cfb@haskell.org> #13399: Location of `forall` matters with higher-rank kind polymorphism -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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): Bullets 2 and 3 spun off as #13407 and #13408, respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:05:47 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.d04092e2b83101d8e47a327121e1e4f0@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"900cfdc2700ad9e8c7a12dd25bb0396e5e7651df/ghc" 900cfdc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="900cfdc2700ad9e8c7a12dd25bb0396e5e7651df" Do not generate a data-con wrapper for !Int# See Note [Data con wrappers and unlifted types] in MkId. We were being totally stupid! See Trac #1600 comment:66 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:05:47 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.e5771aebd383c4acab03da7765ca86c7@haskell.org> #13371: instance selection too eager -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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 Simon Peyton Jones ): In [changeset:"7e96526ac2ef5987ecb03217d3d616b6281c1441/ghc" 7e96526/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e96526ac2ef5987ecb03217d3d616b6281c1441" Fix TcSimplify.decideQuantification for kind variables TcSimplify.decideQuantification was doing the Wrong Thing when "growing" the type variables to quantify over. We were trying to do this on a tyvar set where we'd split off the dependent type varaibles; and we just got it wrong. A kind variable wasn't being generalised properly, with confusing knock on consequences. All this led to Trac #13371 and Trac #13393. This commit tidies it all up: * The type TcDepVars is renamed as CandidateQTvs; and splitDepVarsOfType to candidateQTyVarsOfType * The code in TcSimplify.decideQuantification is simpler. It no longer does the tricky "grow" stuff over TcDepVars. Instead it use ordinary VarSets (thereby eliminating the nasty growThetaTyVarsDSet) and uses that to filter the result of candidateQTyVarsOfType. * I documented that candidateQTyVarsOfType returns the type variables in a good order in which to quantify, and rewrote it to use an accumulator pattern, so that we would predicatably get left-to-right ordering. In doing all this I also made UniqDFM behave a little more nicely: * When inserting an element that is there already, keep the old tag, while still overwriting with the new value. * This means that when doing udfmToList we get back elements in the order they were originally inserted, rather than in reverse order. It's not a big deal, but in a subsequent commit I use it to improve the order of type variables in inferred types. All this led to a lot of error message wibbles: - changing the order of quantified variables - changing the order in which instances are listed in GHCi - changing the tidying of variables in typechecker erors There's a submodule update for 'array' because one of its tests has an error-message change. I may not have associated all of them with the correct commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:05:47 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD In-Reply-To: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> References: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> Message-ID: <065.a14c98d42e6aeb3933e4f55b798447fc@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13394 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"bc0f3abd0914808e33f84229818ab90842611bdd/ghc" bc0f3ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc0f3abd0914808e33f84229818ab90842611bdd" Deal with JoinIds before void types Trac #13394, comment:4 showed up another place where we were testing for the representation of of a type; and it turned out to be a JoinId which can be rep-polymorphic. Just putting the test in the right places solves this easily. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:05:47 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.f31e5c762035508e30f350a0e01e92f8@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7e96526ac2ef5987ecb03217d3d616b6281c1441/ghc" 7e96526/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e96526ac2ef5987ecb03217d3d616b6281c1441" Fix TcSimplify.decideQuantification for kind variables TcSimplify.decideQuantification was doing the Wrong Thing when "growing" the type variables to quantify over. We were trying to do this on a tyvar set where we'd split off the dependent type varaibles; and we just got it wrong. A kind variable wasn't being generalised properly, with confusing knock on consequences. All this led to Trac #13371 and Trac #13393. This commit tidies it all up: * The type TcDepVars is renamed as CandidateQTvs; and splitDepVarsOfType to candidateQTyVarsOfType * The code in TcSimplify.decideQuantification is simpler. It no longer does the tricky "grow" stuff over TcDepVars. Instead it use ordinary VarSets (thereby eliminating the nasty growThetaTyVarsDSet) and uses that to filter the result of candidateQTyVarsOfType. * I documented that candidateQTyVarsOfType returns the type variables in a good order in which to quantify, and rewrote it to use an accumulator pattern, so that we would predicatably get left-to-right ordering. In doing all this I also made UniqDFM behave a little more nicely: * When inserting an element that is there already, keep the old tag, while still overwriting with the new value. * This means that when doing udfmToList we get back elements in the order they were originally inserted, rather than in reverse order. It's not a big deal, but in a subsequent commit I use it to improve the order of type variables in inferred types. All this led to a lot of error message wibbles: - changing the order of quantified variables - changing the order in which instances are listed in GHCi - changing the tidying of variables in typechecker erors There's a submodule update for 'array' because one of its tests has an error-message change. I may not have associated all of them with the correct commit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:05:47 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule In-Reply-To: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> References: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> Message-ID: <060.4fd8d35e86e96a6d3adc252c3f9b525f@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- Reporter: dfeuer | 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: 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:"af6ed4a62c77e57f544243aa72bba51a1cff6808/ghc" af6ed4a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af6ed4a62c77e57f544243aa72bba51a1cff6808" Fix constraint simplification in rules Trac #13381 showed that we were losing track of a wanted constraint when simplifying the LHS constraints for a RULE. This patch fixes it, makes the code a bit simpler, and better documented. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:12:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:12:33 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.fec4cb0afa862ce42e10ee3494d4d644@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Akio, I've fixed that wrapper issue. What's next on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:14:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:14:33 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.93e7969644522cc25355279ad26f5279@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: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T13371 * resolution: => fixed Comment: This is a bit of a big commit, but I think it'd be worth doing for 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:14:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:14:51 -0000 Subject: [GHC] #13371: instance selection too eager In-Reply-To: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> References: <045.4ad04d7a530dab42c2fc6f29221baea7@haskell.org> Message-ID: <060.cd64e909d216f1e2e84466a20befa7f2@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 simonpj): See also #13393 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:15:18 -0000 Subject: [GHC] #13393: GHC panic: No skolem info In-Reply-To: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> References: <045.78845bd72a6aa0f6dc8152982d89b3ba@haskell.org> Message-ID: <060.d9a228d5edc3350a88ec0c184f210052@haskell.org> #13393: GHC panic: No skolem info -------------------------------------+------------------------------------- Reporter: sheyll | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13393 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T13393 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:16:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:16:23 -0000 Subject: [GHC] #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD In-Reply-To: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> References: <050.ed25b2794b5079e532ea5ebc5d466375@haskell.org> Message-ID: <065.e7eb77b25b1913f438f800209ecc17ac@haskell.org> #13394: PatternSynonyms/OverloadedStrings regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13394, T13394a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: polykinds/T13394 => polykinds/T13394, T13394a * status: new => closed * resolution: => fixed Comment: OK, ''now'' it should be fixed. There was a second bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 16:17:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 16:17:31 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule In-Reply-To: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> References: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> Message-ID: <060.98864662aed7fb33845714380a8a8a24@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- 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: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13381 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T13381 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:13:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:13:49 -0000 Subject: [GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database In-Reply-To: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> References: <046.83c0d91965a3a2a3d9807a87e489ab59@haskell.org> Message-ID: <061.7cb6e56e2386cb984f1cb15f8b283e77@haskell.org> #13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3259 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was merged in 5f7b45a51f3736ad5a5046ba2fe4155446a2c467. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:14:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:14:40 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.36bfe9ddc36dfff10ccff3d4b4416742@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Goldfire, is there still a chance that this will happen for 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:18:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:18:00 -0000 Subject: [GHC] #13357: Check demand signatures for catchRetry# and catchSTM# In-Reply-To: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> References: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> Message-ID: <060.0bd9653fc228abd976948c97ce2aef20@haskell.org> #13357: Check demand signatures for catchRetry# and catchSTM# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was resolved for `catchSTM#` in 6a94b8bba999ce111a8195ab398291dce5bcef2d. dfeuer, have you confirmed that `catchRetry#` is alright? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:18:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:18:35 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.b55d7e8824153b42c08d73fdba8a9069@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:19:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:19:40 -0000 Subject: [GHC] #13068: GHC should not allow modules to define instances of abstract type classes In-Reply-To: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> References: <045.3152b3fbdb7e7af8870062f8f1c3da2e@haskell.org> Message-ID: <060.59cefda79908a22957ea2face4a460ce@haskell.org> #13068: GHC should not allow modules to define instances of abstract type classes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3254 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Old description: > hs-boot files permit a type class to be given "abstractly", in which case > any implementation of the type class is permissible. But it does not > reject instances defined for such a class. > > {{{ > -- A.hs-boot > module A where > class C a > > -- B.hs > module B where > import {-# SOURCE #-} A > instance C Int where > > -- A.hs > module A where > import B > class C a where > f :: a > > -- Main.hs > import A > main = print (f :: Int) > }}} > > I get this when I build with `--make`: > > {{{ > ezyang at sabre:~$ ghc-head --make C.hs -fforce-recomp > [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) > [2 of 4] Compiling B ( B.hs, B.o ) > [3 of 4] Compiling A ( A.hs, A.o ) > [4 of 4] Compiling Main ( C.hs, C.o ) > Linking C ... > ./B.o:(.data+0x0): undefined reference to `A_CZCC_con_info' > collect2: error: ld returned 1 exit status > }}} New description: hs-boot files permit a type class to be given "abstractly", in which case any implementation of the type class is permissible. But it does not reject instances defined for such a class. {{{#!hs -- A.hs-boot module A where class C a -- B.hs module B where import {-# SOURCE #-} A instance C Int where -- A.hs module A where import B class C a where f :: a -- Main.hs import A main = print (f :: Int) }}} I get this when I build with `--make`: {{{ ezyang at sabre:~$ ghc-head --make C.hs -fforce-recomp [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling Main ( C.hs, C.o ) Linking C ... ./B.o:(.data+0x0): undefined reference to `A_CZCC_con_info' collect2: error: ld returned 1 exit status }}} -- Comment: This was resolved in bba004f2a0642d3bb8c8876543aaa1a48a2f9a43. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:20:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:20:42 -0000 Subject: [GHC] #13357: Check demand signatures for catchRetry# and catchSTM# In-Reply-To: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> References: <045.79df75dc0a793c7c7426d38d34e05263@haskell.org> Message-ID: <060.275b82057817767ade84777f4ab6ff42@haskell.org> #13357: Check demand signatures for catchRetry# and catchSTM# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | 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): Phab:D3263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: closed => new * resolution: fixed => Comment: No, I left `catchRetry#` alone, and can't vouch for it. Let me consider it a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:25:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:25:21 -0000 Subject: [GHC] #12910: Mirror mingw signature files In-Reply-To: <046.919b607002a73f8f107ad4fda8036ab2@haskell.org> References: <046.919b607002a73f8f107ad4fda8036ab2@haskell.org> Message-ID: <061.594d3fab7b3280e396f912ae5efe5cec@haskell.org> #12910: Mirror mingw signature files ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: None | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This was resolved in part in 7b80168bc11ba1fa3ef7ebfcdf3b4d67f467b0dc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:26:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:26:54 -0000 Subject: [GHC] #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" In-Reply-To: <044.77633c3b8790ee4127144b398901f764@haskell.org> References: <044.77633c3b8790ee4127144b398901f764@haskell.org> Message-ID: <059.6bcda56123250bcd75d4317bc29fc717@haskell.org> #13265: perf-llvm build fails with "Too many sections: 123418 (>= 65280)" -------------------------------------+------------------------------------- Reporter: erikd | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is resolved by 90009cf62bcebf875e68af625dbdbfc3c2f71717. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:27:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:27:19 -0000 Subject: [GHC] #13160: Simplify CoreFV.FVAnn In-Reply-To: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> References: <046.adfdf9ef3c9e1e83c86a19261b8e013d@haskell.org> Message-ID: <061.2cb12de6156714d4ca53100e6eaf9a3f@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:27:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:27:52 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.1a3123a88ea8c095a9e30fb113485bdf@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: This won't happen for 8.2 and given that GCC 6 is quickly becoming the norm, perhaps never at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:28:30 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.4c65c52482c1e3a7eaf7d700a9f5ffed@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dalaing Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:34:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:34:26 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.a601d6a2944fa850f6558dd53dc5d989@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: Hmm, this is an interesting ticket which we should really have a closer look at. Sadly, though, this won't happen for 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 17:46:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 17:46:04 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.94b4987e21f24fa1a967caa937b56bbc@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => ezyang Comment: ezyang, are you aware of this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 21:07:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 21:07:09 -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.872008afb74b5b4f4708893dc5d036c9@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 ak3n): I decided to check it. {{{ ⋊> ghc on master ⨯ cat bug.hs main = print "hello" ⋊> ghc on master ⨯ ./inplace/bin/ghc-stage2 -dynamic bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... ⋊> ghc on master ⨯ ./inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170310: http://www.haskell.org/ghc/ :? for help Prelude> :l bug Ok, modules loaded: Main (bug.o). Prelude Main> main : missing -B option *** Exception: ExitFailure 1 Prelude Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 10 21:55:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Mar 2017 21:55:26 -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.6e1d03587980dc97893295b9e938e67c@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): The error message that you're getting is different than the one I got although the test case is the same. Not sure if we should reopen this bug or file a new one. I don't have access to a system built from head so I can't try to duplicate what you found. Thanks for testing and bringing this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 04:20:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 04:20:20 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule Message-ID: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- 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 | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `hybrid-vectors-0.2.1` currently fails to build with GHC HEAD. I've attached a minimized repro file with no dependencies (it's 410 lines long, since I had to copy-paste a lot of code from `vector` in order to reproduce this). The attached file builds on GHC 7.10.3 and 8.0.2, but fails on GHC HEAD with this panic: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 -O2 -fforce-recomp Bug.hs [1 of 1] Compiling Data.Vector.Hybrid.Internal ( Bug.hs, Bug.o ) Bug.hs:389:10: warning: [-Wmissing-methods] • No explicit implementation for ‘gmbasicOverlaps’, ‘gmbasicInitialize’, and ‘gmbasicUnsafeRead’ • In the instance declaration for ‘GMVector (MVector u v) (a, b)’ | 389 | instance (GMVector u a, GMVector v b) => GMVector (MVector u v) (a, b) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:407:10: warning: [-Wmissing-methods] • No explicit implementation for ‘gbasicUnsafeFreeze’, ‘gbasicUnsafeThaw’, ‘gbasicLength’, ‘gbasicUnsafeSlice’, and ‘gbasicUnsafeIndexM’ • In the instance declaration for ‘GVector (Vector u v) (a, b)’ | 407 | instance (GVector u a, GVector v b) => GVector (Vector u v) (a, b) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170310 for x86_64-unknown-linux): Template variable unbound in rewrite rule Variable: sc_s8FV Rule "SC:$j0" Rule bndrs: [sc_s8FV, sc_s8FW, sc_s8FX, sg_s8FY, sc_s8FU] LHS args: [sc_s8FU, (MV @ (GMutable u_a4oM) @ (GMutable v_a4oO) @ (PrimState (ST RealWorld)) @ (a_a4oN, b_a4oP) @ a_a4oN @ b_a4oP @~ (<(a_a4oN, b_a4oP)>_N :: ((a_a4oN, b_a4oP) :: *) ~# ((a_a4oN, b_a4oP) :: *)) sc_s8FW sc_s8FX) `cast` (sg_s8FY :: (MVector (GMutable u_a4oM) (GMutable v_a4oO) (PrimState (ST RealWorld)) (a_a4oN, b_a4oP) :: *) ~R# (GMutable (Vector u_a4oM v_a4oO) (PrimState (ST RealWorld)) c_a4oQ :: *))] Actual args: [sc_s8FS, wild_X3x `cast` (Sub (Sym (D:R:GMutableVector[0] _N _N)) _N (Sym cobox_a4Gz) :: (MVector (GMutable u_a4oM) (GMutable v_a4oO) (PrimState (ST RealWorld)) (a_a4oN, b_a4oP) :: *) ~R# (GMutable (Vector u_a4oM v_a4oO) (PrimState (ST RealWorld)) c_a4oQ :: *))] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/specialise/Rules.hs:579:19 in ghc:Rules }}} Some important things to note: * `-O2` is required to trigger this bug; using `-O1` or below works fine. * The problematic code is the `Read (Vector u v c)` instance at the very bottom. In particular, commenting out the last line `readPrec = greadPrec` makes the panic go away. * Moreover, there's a particular `INLINE` pragma in the `GMVector (MVector u v) (a, b)` instance that is critical to triggering the panic (it's on line 394; I've added a comment `Removing this INLINE pragma makes it compile` above it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 04:20:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 04:20:28 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.a3e80b87779dadc15c98a22ae2495b92@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- 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 crash or panic | 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 Mar 11 04:21:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 04:21:30 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.4fe3b7c9cf3734ab85ce69a7c43bedcf@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- 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 crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > `hybrid-vectors-0.2.1` currently fails to build with GHC HEAD. I've > attached a minimized repro file with no dependencies (it's 410 lines > long, since I had to copy-paste a lot of code from `vector` in order to > reproduce this). The attached file builds on GHC 7.10.3 and 8.0.2, but > fails on GHC HEAD with this panic: > > {{{ > $ ~/Software/ghc2/inplace/bin/ghc-stage2 -O2 -fforce-recomp Bug.hs > [1 of 1] Compiling Data.Vector.Hybrid.Internal ( Bug.hs, Bug.o ) > > Bug.hs:389:10: warning: [-Wmissing-methods] > • No explicit implementation for > ‘gmbasicOverlaps’, ‘gmbasicInitialize’, and ‘gmbasicUnsafeRead’ > • In the instance declaration for ‘GMVector (MVector u v) (a, b)’ > | > 389 | instance (GMVector u a, GMVector v b) => GMVector (MVector u v) (a, > b) where > | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Bug.hs:407:10: warning: [-Wmissing-methods] > • No explicit implementation for > ‘gbasicUnsafeFreeze’, ‘gbasicUnsafeThaw’, ‘gbasicLength’, > ‘gbasicUnsafeSlice’, and ‘gbasicUnsafeIndexM’ > • In the instance declaration for ‘GVector (Vector u v) (a, b)’ > | > 407 | instance (GVector u a, GVector v b) => GVector (Vector u v) (a, b) > where > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.3.20170310 for x86_64-unknown-linux): > Template variable unbound in rewrite rule > Variable: sc_s8FV > Rule "SC:$j0" > Rule bndrs: [sc_s8FV, sc_s8FW, sc_s8FX, sg_s8FY, sc_s8FU] > LHS args: [sc_s8FU, > (MV > @ (GMutable u_a4oM) > @ (GMutable v_a4oO) > @ (PrimState (ST RealWorld)) > @ (a_a4oN, b_a4oP) > @ a_a4oN > @ b_a4oP > @~ (<(a_a4oN, b_a4oP)>_N > :: ((a_a4oN, b_a4oP) :: *) ~# ((a_a4oN, b_a4oP) :: > *)) > sc_s8FW > sc_s8FX) > `cast` (sg_s8FY > :: (MVector > (GMutable u_a4oM) > (GMutable v_a4oO) > (PrimState (ST RealWorld)) > (a_a4oN, b_a4oP) :: *) > ~R# > (GMutable > (Vector u_a4oM v_a4oO) (PrimState (ST > RealWorld)) c_a4oQ :: *))] > Actual args: [sc_s8FS, > wild_X3x > `cast` (Sub > (Sym (D:R:GMutableVector[0] _N > _N)) (ST > RealWorld)>_N (Sym > cobox_a4Gz) > :: (MVector > (GMutable u_a4oM) > (GMutable v_a4oO) > (PrimState (ST RealWorld)) > (a_a4oN, b_a4oP) :: *) > ~R# > (GMutable > (Vector u_a4oM v_a4oO) (PrimState (ST > RealWorld)) c_a4oQ :: *))] > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1191:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in > ghc:Outputable > pprPanic, called at compiler/specialise/Rules.hs:579:19 in > ghc:Rules > }}} > > Some important things to note: > > * `-O2` is required to trigger this bug; using `-O1` or below works fine. > * The problematic code is the `Read (Vector u v c)` instance at the very > bottom. In particular, commenting out the last line `readPrec = > greadPrec` makes the panic go away. > * Moreover, there's a particular `INLINE` pragma in the `GMVector > (MVector u v) (a, b)` instance that is critical to triggering the panic > (it's on line 394; I've added a comment `Removing this INLINE pragma > makes it compile` above it). New description: `hybrid-vectors-0.2.1` currently fails to build with GHC HEAD. I've attached a minimized repro file with no dependencies (it's 410 lines long, since I had to copy-paste a lot of code from `vector` in order to reproduce this). The attached file builds on GHC 7.10.3 and 8.0.2, but fails on GHC HEAD with this panic: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 -O2 -fforce-recomp Bug.hs [1 of 1] Compiling Data.Vector.Hybrid.Internal ( Bug.hs, Bug.o ) Bug.hs:389:10: warning: [-Wmissing-methods] • No explicit implementation for ‘gmbasicOverlaps’, ‘gmbasicInitialize’, and ‘gmbasicUnsafeRead’ • In the instance declaration for ‘GMVector (MVector u v) (a, b)’ | 389 | instance (GMVector u a, GMVector v b) => GMVector (MVector u v) (a, b) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:407:10: warning: [-Wmissing-methods] • No explicit implementation for ‘gbasicUnsafeFreeze’, ‘gbasicUnsafeThaw’, ‘gbasicLength’, ‘gbasicUnsafeSlice’, and ‘gbasicUnsafeIndexM’ • In the instance declaration for ‘GVector (Vector u v) (a, b)’ | 407 | instance (GVector u a, GVector v b) => GVector (Vector u v) (a, b) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170310 for x86_64-unknown-linux): Template variable unbound in rewrite rule Variable: sc_s8FV Rule "SC:$j0" Rule bndrs: [sc_s8FV, sc_s8FW, sc_s8FX, sg_s8FY, sc_s8FU] LHS args: [sc_s8FU, (MV @ (GMutable u_a4oM) @ (GMutable v_a4oO) @ (PrimState (ST RealWorld)) @ (a_a4oN, b_a4oP) @ a_a4oN @ b_a4oP @~ (<(a_a4oN, b_a4oP)>_N :: ((a_a4oN, b_a4oP) :: *) ~# ((a_a4oN, b_a4oP) :: *)) sc_s8FW sc_s8FX) `cast` (sg_s8FY :: (MVector (GMutable u_a4oM) (GMutable v_a4oO) (PrimState (ST RealWorld)) (a_a4oN, b_a4oP) :: *) ~R# (GMutable (Vector u_a4oM v_a4oO) (PrimState (ST RealWorld)) c_a4oQ :: *))] Actual args: [sc_s8FS, wild_X3x `cast` (Sub (Sym (D:R:GMutableVector[0] _N _N)) _N (Sym cobox_a4Gz) :: (MVector (GMutable u_a4oM) (GMutable v_a4oO) (PrimState (ST RealWorld)) (a_a4oN, b_a4oP) :: *) ~R# (GMutable (Vector u_a4oM v_a4oO) (PrimState (ST RealWorld)) c_a4oQ :: *))] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/specialise/Rules.hs:579:19 in ghc:Rules }}} Some important things to note: * `-O2` is required to trigger this bug; using `-O1` or below works fine. * The problematic code is the `Read (Vector u v c)` instance at the very bottom. In particular, commenting out the last line `readPrec = greadPrec` makes the panic go away. * Moreover, there's a particular `INLINE` pragma in the `GMVector (MVector u v) (a, b)` instance that is critical to triggering the panic (it's on line 395; I've added a comment `Removing this INLINE pragma makes it compile` above it). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 09:21:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 09:21:26 -0000 Subject: [GHC] #13411: GCC driver fails on Windows 10 15019+ Message-ID: <044.319927771157cb149232cac95f75e05c@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.2 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): | Wiki Page: -------------------------------------+------------------------------------- Our GCC driver seems to be failing with a compatibility error on Windows 10 Insider builds 15019+. Leaving error code 0xc0000142. This driver has been unchanged since Windows XP and may just need some old APIs replaced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 09:21:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 09:21:42 -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.92be2826cdc474c4ac3fde751f481e4a@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.2 Resolution: | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 10:51:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 10:51:22 -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.df1b7aa8a4443696881b614a90bb31dd@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Driver | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * priority: normal => highest * status: new => patch * differential: => Phab:D3319 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 16:17:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 16:17:49 -0000 Subject: [GHC] #13412: Centralize the definition for GHC's libdir on Windows Message-ID: <045.8936c4a00edd436367292bcef5136be7@haskell.org> #13412: Centralize the definition for GHC's libdir on Windows ----------------------------------------+---------------------------- Reporter: Elieux | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: None | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The location of GHC libraries on Windows is currently something like `$bindir/../lib` (because the whole distribution can be put anywhere on the filesystem, there are no absolute paths), but this information is hard-coded in multiple places instead of being defined in one place. To be clear, I mean only the relative path (`../lib`); the base still needs to be determined at runtime. I assume that tools that can rely on `ghc --info` (or equivalent) already do that. If there are any that don't, they should be fixed regardless. The build system, ghc, ghc-cabal, ghc-pkg, hsc2hs, haddock... should all be able to get the relative path from `configure`'s output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 16:19:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 16:19:20 -0000 Subject: [GHC] #13412: Centralize the definition for GHC's libdir on Windows In-Reply-To: <045.8936c4a00edd436367292bcef5136be7@haskell.org> References: <045.8936c4a00edd436367292bcef5136be7@haskell.org> Message-ID: <060.7da3374773b815d0edd3270a7f67ab12@haskell.org> #13412: Centralize the definition for GHC's libdir on Windows ----------------------------+---------------------------------------- Reporter: Elieux | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: None | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+---------------------------------------- Comment (by Elieux): Some of the hard-coded places can be seen here: https://github.com/elieux /MINGW-packages/commit/2b70b3985c94fde31d9086c85ffc5297f89f4e47 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 17:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 17:12:32 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.9e1a1693a4a8c25fb0836d06b4dc77ee@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => JoinPoints Comment: Commit 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points) introduced this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 19:47:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 19:47:18 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.db583efcd5df6402bd1d64ed3f995338@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ThreeFx Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"7b095b991879b29b26fce9e9d4accd3ba9366dc0/ghc" 7b095b99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b095b991879b29b26fce9e9d4accd3ba9366dc0" Emit Core lint warnings on stderr, fix #13342 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 19:47:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 19:47:44 -0000 Subject: [GHC] #13342: Core Lint warnings are emitted on stdout rather than stderr In-Reply-To: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> References: <049.b0836f8044e0e439fdf4a93b5619fbc6@haskell.org> Message-ID: <064.0127703d2e61b5717b909564a29008d0@haskell.org> #13342: Core Lint warnings are emitted on stdout rather than stderr -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ThreeFx Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 20:12:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 20:12:28 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders Message-ID: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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: -------------------------------------+------------------------------------- `repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this issue. Trying to build it leads to several `collectNBinders` panics is various modules. You can reproduce this by compiling this module: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} module Data.Repa.Eval.Generic.Seq.Chunked where import GHC.Exts (Int#, (+#), (*#), (>=#)) ------------------------------------------------------------------------------- -- | Fill a block in a rank-2 array, sequentially. -- -- * Blockwise filling can be more cache-efficient than linear filling for -- rank-2 arrays. -- -- * The block is filled in row major order from top to bottom. -- fillBlock2 :: (Int# -> a -> IO ()) -- ^ Update function to write into result buffer. -> (Int# -> Int# -> a) -- ^ Function to get the value at an (x, y) index. -> Int# -- ^ Width of the whole array. -> Int# -- ^ x0 lower left corner of block to fill. -> Int# -- ^ y0 -> Int# -- ^ w0 width of block to fill -> Int# -- ^ h0 height of block to fill -> IO () fillBlock2 write getElem !imageWidth !x0 !y0 !w0 h0 = do fillBlock y0 ix0 where !x1 = x0 +# w0 !y1 = y0 +# h0 !ix0 = x0 +# (y0 *# imageWidth) {-# INLINE fillBlock #-} fillBlock !y !ix | 1# <- y >=# y1 = return () | otherwise = do fillLine1 x0 ix fillBlock (y +# 1#) (ix +# imageWidth) where {-# INLINE fillLine1 #-} fillLine1 !x !ix' | 1# <- x >=# x1 = return () | otherwise = do write ix' (getElem x y) fillLine1 (x +# 1#) (ix' +# 1#) {-# INLINE [0] fillBlock2 #-} }}} This compiles on GHC 8.0.2, but on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs [1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170201 for x86_64-unknown-linux): collectNBinders 2 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1179:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in ghc:CoreSyn }}} Interestingly, compiling this triggers the panic at any optimization level, but loading the module into GHCi does not cause it to panic. This regression was introduced in 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 20:50:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 20:50:39 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.9b95a3ea6ef3c904cf61a1b579c181c3@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | polykinds/T13267 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"740ecda32116abe84b6d7d4786b3e2ad9c8ba2a4/ghc" 740ecda/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="740ecda32116abe84b6d7d4786b3e2ad9c8ba2a4" Observe #13267 in release notes I noticed some code in the wild that broke due to the validity checking introduced in #13267, so we should be proactive and warn about it in the 8.2 release notes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 20:52:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 20:52:10 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.7d307c668bcfbc5fb448442c5e9732a0@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | polykinds/T13267 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge * milestone: => 8.2.1 Comment: It would be nice to merge 740ecda32116abe84b6d7d4786b3e2ad9c8ba2a4 into 8.2, which notes this change in the release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 11 21:59:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Mar 2017 21:59:09 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.dcd4b653cf1865943fe60dcd4fc70370@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Nolan): I faced with a problem. There's a test BinaryLiterals0 which breaks after my patch. Problem is that before the patch expressions like `(,) -0b0` were valid because `-0` was single lexeme. Patch changed this behavior for zeroes and now `-` is distinct lexeme if followed by zero literal. I see 3 of ways of dealing with that fail. 1) Remove this test. Which doesn't look like a good idea for me though. 2) Change lexer such that `-0` is single lexeme but `-0.0` is two distinct ones. The test should pass. But think of this. `id -0.0` is now legal code but after such change it will fail. So I think this is not good solution as well. 3) To come up with another way of solving this issue that will not break those tests. 4) Consider this is not bug but a feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 04:01:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 04:01:22 -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.dbcdf952e9caf5ea2c985be6985b770f@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 angerman): * owner: thoughtpolice => angerman Comment: Ok. Let's do this. I will deviate a bit from the plan in the proposal though. The rough idea is: - replace opt+llc with clang. This does imply that we loose the mangler, and probably won't be able to do `-split-obj` at all. - build a release llvm-clang with necessary ghc changes, and call this `ghc-clang`, until we all ghc relevant patches are upstream in llvm. - provide binary distributions for said `ghc-clang` for at least all tire1 platforms. Other platform will have to build clang from source. This should hopefully allow us to drop quite a bit of code from the llvm backend. It might re-introduce some new bugs. We do have quite a few hacks here and there to work around bugs in the llvm toolchain, for which we do not necessarily know if they are still present in the llvm toolchain we currently support. This should allow us to pin the llvm backend to a certain (potentially customized) clang version. This should be an interim solution only though. Hopefully we'll have all the necessary changes in llvm upstreamed by the time llvm5 (~6mo from now) or llvm6 (~12mo from now), will be released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 09:16:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 09:16:55 -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.edf74b36f5a807f75e4aa8da70d7fa54@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.4.1 => 8.2.1 Comment: Picked wrong milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 10:22:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 10:22: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.8de60fb39726697562ca305ee184f591@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 lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 12:08:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 12:08:58 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.5af39720dbd67e3ea26a7d0bc75d527d@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case ----------------------------+------------------------------ Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+------------------------------ Comment (by Phyx-): Hi, Are you sure that message didn't come from a console that was `cd'ed` into a folder on the removable drive? What were you doing with the drive? I don't quite understand what the memory card has to do with he bug report. Were you trying to open files on it before? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 14:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 14:00:27 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.d309d95b10ca43c8728d5181e095a079@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case ----------------------------+------------------------------ Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+------------------------------ Comment (by vanto): Hi, Have you checked the sequences I wrote in order the first time?\\ I did it again by doing this:\\ 1 - I start the computer in MS-DOS mode without failure with the memory card install in drive D.\\ 2 - I run GHCi; it is ok.\\ 3 - I stop GHCi.\\ 4 - I remove the memory card.\\ 5 - I restart GHCi. GHCi start and stops suddendly when a window appears on the screen. We read the error message in this window.\\ 6 - I insert the memory card and click on the button cancel or continue or restart and GHCi works again.\\ or, 1 - I start the computer in MS-DOS mode without failure without memory card.\\ 2 - I run GHCi; it is ok.\\ 3 - I stop GHCi.\\ 4 - I insert the memory card in drive D\\ 5 - I run GHCi; it is ok.\\ 6 - I stop GHCi.\\ 7 - I remove the memory card.\\ 8 - I restart GHCi. GHCi start and stop suddendly when a window appears on the screen. We read the error message in this window.\\ 9 - I insert the memory card and click on the button cancel or continue or restart and GHCi works again.\\ Please, apply the check list.\\ I don't know what to say more.\\ Hope this help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 15:38:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 15:38:32 -0000 Subject: [GHC] #13414: shebang + literate haskell causes line numbering skew Message-ID: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> #13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed on doctest's Setup.lhs file. Minimal example: {{{#!hs #!/usr/bin/env runhaskell > main = return () }}} {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -Wall Setup [1 of 1] Compiling Main ( Setup.lhs, Setup.o ) Setup.lhs:1:3: warning: [-Wmissing-signatures] Top-level binding with no type signature: main :: IO () | 1 | #!/usr/bin/env runhaskell | ^^^^ }}} Notice how it points 4 characters a line before '''main'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 16:02:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 16:02:22 -0000 Subject: [GHC] #13414: shebang + literate haskell causes line numbering skew In-Reply-To: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> References: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> Message-ID: <060.b30c7e739f0e86769f0fbce7f7aa90f1@haskell.org> #13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 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 RyanGlScott): * cc: Rufflewind (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From matthew at wellquite.org Sun Mar 12 16:16:09 2017 From: matthew at wellquite.org (matthew) Date: Sun, 12 Mar 2017 18:16:09 +0200 Subject: =?utf-8?B?UmU6IHRoYXQgaXMgc28gZ3JlYXQh?= Message-ID: <1033747468.20170312191609@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: Greetings, Look what I've just found on the web! It's so amazing, check it out http://truth.sindyslade.com/9796 Warm regards, matthew [...] Content analysis details: (6.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [113.194.133.139 listed in zen.spamhaus.org] 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL 1.2 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: sindyslade.com] 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=113.194.133.139;r=mail.haskell.org] 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4656] 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: Re: that is so great! Date: Sun, 12 Mar 2017 18:16:09 +0200 Size: 4008 URL: From ghc-devs at haskell.org Sun Mar 12 19:06:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 19:06:39 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.43505d947d854d0bf42cd25acf5ca70e@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): Hi! I'd like to try my hand at this but was hoping someone could give me some guidance. From my looking so far, it would appear that the current error message is from somewhere in the typechecker (smallerMsg) while the warning we want to show up is in the Lexer. I would have expected the warning in the lexer to show up first though since presumably the lexer runs before the typechecker. Could anyone give me a pointer to where I should look to understand what the issue is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 20:23:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 20:23:32 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards Message-ID: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #13324 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While exploring a fix for #13324, I was blocked pretty quickly by this limitation: instance declarations don't properly recognize named wildcards. Here is an example to demonstrate: {{{#!hs {-# LANGUAGE NamedWildCards #-} module Bug where instance _x => Show (Maybe a) }}} {{{ Bug.hs:4:10: error: • Illegal constraint: _x (Use ConstraintKinds to permit this) • In the context: _x While checking an instance declaration In the instance declaration for ‘Show (Maybe a)’ | 4 | instance _x => Show (Maybe a) | ^^^^^^^^^^^^^^^^^^^^ }}} GHC doesn't recognize that `_x` is just a type variable, not a named wildcard. I believe fixing this is just a matter of changing the ASTs for instance declarations to use `LHsSigWcType` instead of `LHsSigType`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 20:41:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 20:41:21 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.9da523d5bc81992f19d207598281c6a2@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3332 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 22:28:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 22:28:44 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates In-Reply-To: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> References: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> Message-ID: <061.bb0ab2cd18215e0baff34fabb837fba4@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => (none) * status: closed => new * resolution: fixed => Comment: Actually no, this isn't fixed. I believe the issue here may be that Harbormaster reuses trees and fails to `git submodule sync` before attempting to `submodule update`. I have not looked into this very deeply, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 22:29:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 22:29:15 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates In-Reply-To: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> References: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> Message-ID: <061.419b821ec5ab4c96ffc5cc5bbbd98ebd@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 12 23:17:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Mar 2017 23:17:31 -0000 Subject: [GHC] #13414: shebang + literate haskell causes line numbering skew In-Reply-To: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> References: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> Message-ID: <060.5bafb4c20717e44c90bb0b0d350a64c1@haskell.org> #13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 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 Rufflewind): https://phabricator.haskell.org/D3333 should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 00:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 00:42:25 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.42ca21c8feeac02e232954a7e6ef3f8f@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 ThreeFx): Replying to [comment:2 richardfung]: > Hi! I'd like to try my hand at this but was hoping someone could give me some guidance. > > From my looking so far, it would appear that the current error message is from somewhere in the typechecker (smallerMsg) while the warning we want to show up is in the Lexer. > > I would have expected the warning in the lexer to show up first though since presumably the lexer runs before the typechecker. Could anyone give me a pointer to where I should look to understand what the issue is? You're correct that the lexer runs before the type checker - after all, you need to know what to typecheck. I suspect that `{-# LANUGAGE UndecidableInstances #-}` is not parsed as pragma but as nested comment. In order to verify this I would look at the lexer and see if this is actually the case. If it isn't, definitely check what this actually gets lexed as - too bad there is no `-ddump-lexed` option. If it is, I'd probably consider adding a lexing warning for unrecognized pragma keywords (`LANGUAGE`, `OPTIONS_GHC`, ...). Maybe this could also be extended to all pragmas, not only file headers. Anyway this may be completely wrong - it's just my opinion on where to start. Happy hacking! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 00:43:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 00:43:10 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.a81816786970811c1895cb098a2ca43e@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: | -------------------------------------+------------------------------------- Changes (by ThreeFx): * cc: ThreeFx (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 05:57:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 05:57:13 -0000 Subject: [GHC] #13416: Unsolved Constraints (initTc) Message-ID: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> #13416: Unsolved Constraints (initTc) -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: constraint | 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: -------------------------------------+------------------------------------- Another bug here: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] nub_a1U2 :: t_a1U1[tau:1] (CHoleCan: nub)} I've attached the relevant code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 05:57:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 05:57:46 -0000 Subject: [GHC] #13416: Unsolved Constraints (initTc) In-Reply-To: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> References: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> Message-ID: <067.efe57db1bafd8218e1aa384416072878@haskell.org> #13416: Unsolved Constraints (initTc) -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: constraint 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 sgschlesinger): * Attachment "Maths.hs" added. Maths.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 08:15:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 08:15:09 -0000 Subject: [GHC] #13414: shebang + literate haskell causes line numbering skew In-Reply-To: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> References: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> Message-ID: <060.8354f339b0684d58459cb3b2c1bb174d@haskell.org> #13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 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): Phab:D3333 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D3333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 08:56:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 08:56:41 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e0ccb2dcb339f58f77066da4f0c1ad1b@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @winter it's always wrong to pass an unpinned `ByteArray#` to a foreign call, regardless of whether the call is annotated as `safe` or `unsafe`, because GHC is free to implement an `unsafe` call as a `safe` call. Indeed we do this in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 10:07:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 10:07:39 -0000 Subject: [GHC] #13416: Unsolved Constraints (initTc) In-Reply-To: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> References: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> Message-ID: <067.934978a9d5df60615ed5690128dc8a9d@haskell.org> #13416: Unsolved Constraints (initTc) -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: constraint Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): with 8.0.1, the message is {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Downloads/Maths.hs, interpreted ) Downloads/Maths.hs:33:22: error: Variable not in scope: nub :: [Integer] -> [Integer] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 13:31:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 13:31:29 -0000 Subject: [GHC] #13416: Unsolved Constraints (initTc) In-Reply-To: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> References: <052.9a3b85dbf4b78c0640f22112ece8b7f5@haskell.org> Message-ID: <067.9af1da567a8fd87a3350f3d0b5e4c3b5@haskell.org> #13416: Unsolved Constraints (initTc) -------------------------------------+------------------------------------- Reporter: sgschlesinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: constraint Operating System: Linux | 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 bug report. This is a duplicate of #13106, which has been fixed in GHC HEAD (and will be shipped with GHC 8.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 13:54:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 13:54:19 -0000 Subject: [GHC] #13298: Compact API design improvements In-Reply-To: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> References: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> Message-ID: <060.e02e9497326d008e7da4a368144b9ad8@haskell.org> #13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Has this been resolved yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 14:15:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 14:15:22 -0000 Subject: [GHC] Trac email verification for user: ralf Message-ID: <20170313141522.C743C3A583@ghc.haskell.org> Please visit the following URL to confirm your email address. Verification URL: Username: ralf Verification Token: H6OSjo6d -- GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 14:19:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 14:19:31 -0000 Subject: [GHC] #13417: piResultTys1 Message-ID: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Error provoked by attached H98 program (which is generated by a program); compiles fine without optimizations; compilation with -O2 crashes: $ ghc --make -O2 FactorialSequ.lhs [1 of 1] Compiling FactorialSequ ( FactorialSequ.lhs, FactorialSequ.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): piResultTys1 Sequ7 t_a2zl [a_a2zm] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 14:21:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 14:21:38 -0000 Subject: [GHC] #13418: IndexError: pop from empty list Message-ID: <043.6a7d3c036ffaf65828210982a9855ffa@haskell.org> #13418: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: ralf | 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/13417/`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {u'action': u'new', 'path': u'13417/', 'realm': u'ticket'} }}} User agent: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36` ==== 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 "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 613, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 273, in dispatch iterable=chrome.use_chunked_encoding) File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1159, 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 "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1426, 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 "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1415, 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 Mon Mar 13 15:00:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 15:00:19 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.696639ec460d137077fcd1331a0d2557@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12980 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I can create a GHC proposal for this but I need a sanity check first > > {{{#!hs > import Prelude hiding (Num (..)) > import qualified Prelude as P > import GHC.Prim > import GHC.Types > > class Num (a :: TYPE k) where > (+) :: a -> a -> a > (-) :: a -> a -> a > (*) :: a -> a -> a > negate :: a -> a > abs :: a -> a > signum :: a -> a > > fromInteger :: Integer -> a > > instance Num Int# where > (+) :: Int# -> Int# -> Int# > (+) = (+#) > > (-) :: Int# -> Int# -> Int# > (-) = (-#) > > (*) :: Int# -> Int# -> Int# > (*) = (*#) > > negate :: Int# -> Int# > negate = negateInt# > > ... > > fromInteger :: Integer -> Int# > fromInteger (fromInteger @PtrRepLifted @Int -> I# int) = int > > instance Num Double# where > (+) :: Double# -> Double# -> Double# > (+) = (+##) > > (-) :: Double# -> Double# -> Double# > (-) = (-##) > > (*) :: Double# -> Double# -> Double# > (*) = (*##) > > negate :: Double# -> Double# > negate = negateDouble# > > ... > > fromInteger :: Integer -> Double# > fromInteger (fromInteger @PtrRepLifted @Double -> D# dbl) = dbl > }}} > > Note how the `fromInteger` views aren't qualified? That's because we can > branch on the kind and all of a sudden, all instances of old `Num` are > instances of our `Num` > > {{{#!hs > instance P.Num a => Num (a :: Type) where > (+) = (P.+) @a > (-) = (P.-) @a > (*) = (P.*) @a > negate = P.negate @a > abs = P.abs @a > signum = P.signum @a > fromInteger = P.fromInteger @a > }}} > > ---- > > Same with `Show` etc. etc. > > {{{#!hs > class Show (a :: TYPE k) where > show :: (a :: TYPE k) -> String > > instance P.Show a => Show (a :: Type) where > show :: (a :: Type) -> String > show = P.show @a > > instance Show (Int# :: TYPE IntRep) where > show :: Int# -> String > show int = show @PtrRepLifted @Int (I# int) > > instance Show (Double# :: TYPE DoubleRep) where > show :: Double# -> String > show dbl = show @PtrRepLifted @Double (D# dbl) > }}} > > {{{#!hs > class Functor (f :: Type -> TYPE rep) where > fmap :: (a -> b) -> (f a -> f b) > > instance Functor ((# , #) a) where > fmap :: (b -> b') -> ((# a, b #) -> (# a, b' #)) > fmap f (# a, b #) = (# a, f b #) > > class Applicative (f :: Type -> TYPE rep) where > pure :: a -> f a > (<*>) :: f (a -> b) -> (f a -> f b) > > instance Monoid m => Applicative ((# , #) m) where > pure :: a -> (# m, a #) > pure a = (# mempty, a #) > > (<*>) :: (# m, a -> b #) -> ((# m, a #) -> (# m, b #)) > (# m1, f #) <*> (# m2, x #) = (# m1 <> m2, f x #) > > class Foldable (f :: Type -> TYPE rep) where > fold :: Monoid m => f m -> m > > instance Foldable ((# , #) xx) where > fold :: Monoid m => (# xx, m #) -> m > fold (# _, m #) = m > }}} > > halp where does this end > > ---- > > What effects would this have? They are even printed the same by default > > {{{#!hs > Prelude.Num :: * -> Constraint > Main.Num :: * -> Constraint > > -- >>> :set -fprint-explicit-runtime-reps > Prelude.Num :: * -> Constraint > Main.Num :: TYPE k -> Constraint > > -- >>> :set -fprint-explicit-foralls > Prelude.Num :: * -> Constraint > Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint > }}} New description: **See ghc-proposal**: [https://github.com/ghc-proposals/ghc- proposals/pull/30 Levity-Polymorphic Type Classes] ---- I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: TYPE k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger @PtrRepLifted @Int -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger @PtrRepLifted @Double -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) @a (-) = (P.-) @a (*) = (P.*) @a negate = P.negate @a abs = P.abs @a signum = P.signum @a fromInteger = P.fromInteger @a }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show @a instance Show (Int# :: TYPE IntRep) where show :: Int# -> String show int = show @PtrRepLifted @Int (I# int) instance Show (Double# :: TYPE DoubleRep) where show :: Double# -> String show dbl = show @PtrRepLifted @Double (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b' #)) fmap f (# a, b #) = (# a, f b #) class Applicative (f :: Type -> TYPE rep) where pure :: a -> f a (<*>) :: f (a -> b) -> (f a -> f b) instance Monoid m => Applicative ((# , #) m) where pure :: a -> (# m, a #) pure a = (# mempty, a #) (<*>) :: (# m, a -> b #) -> ((# m, a #) -> (# m, b #)) (# m1, f #) <*> (# m2, x #) = (# m1 <> m2, f x #) class Foldable (f :: Type -> TYPE rep) where fold :: Monoid m => f m -> m instance Foldable ((# , #) xx) where fold :: Monoid m => (# xx, m #) -> m fold (# _, m #) = m }}} halp where does this end ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint -- >>> :set -fprint-explicit-foralls Prelude.Num :: * -> Constraint Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 15:40:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 15:40:31 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.5243a5363fa3f23a53364f03cef7114d@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What program is this? I don't see an attachment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 15:53:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 15:53:30 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.0b61e03eaff3ab1056502c817d11d0ef@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Wow, that's news to me! Does that apply to `foreign import prim` as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 15:56:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 15:56:06 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.8127836ebd50d561cefef61ef345bdad@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ralf): I know, the reason is simple: Trac crashed when I tried to do attach the file, asking me to file a bug report ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 15:58:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 15:58:04 -0000 Subject: [GHC] #13332: Report unrecognized pragmas earlier In-Reply-To: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> References: <047.1ddd23213b071d45cfe4a0a6e4a35385@haskell.org> Message-ID: <062.1f635c447351d5f071cd16ee23f462cb@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 rwbarton): According to the ticket description, GHC does generate a warning about the unknown pragma `LANUGAGE`; but only when there isn't an error in the module. I think there is some logic somewhere for not displaying warnings when there are also errors to report, on the grounds that the errors are more important (and may be the cause of the warnings). However, here clearly the warning about `LANUGAGE` is the cause of the consequent errors. We should probably have some notion of "important warnings" that get displayed even when there are errors to report as well. I think this may have been discussed on another ticket as well, which had a similar sort of issue; but I can't find it at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 16:19:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 16:19:33 -0000 Subject: [GHC] #13211: NegativeLiterals -0.0 :: Double In-Reply-To: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> References: <047.ef8488ec1090cf70c44b32e366985dfa@haskell.org> Message-ID: <062.1702d237fac04600a456d34a7a3c6ec3@haskell.org> #13211: NegativeLiterals -0.0 :: Double -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Nolan Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I see. I guess we could continue to parse `-0b0` and `-0.0` as single lexemes, but record that they have the form of negative zero. Then convert them to `negate (fromInteger 0)` or `negate (fromRational 0)` during desugaring. However when I took a quick look earlier that didn't look particularly convenient to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 16:30:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 16:30:06 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.30510781f5af956fc20f0a974ffcf97a@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): No, it doesn't apply to `foreign import prim`. Think of `foreign import prim` as declaring a primop: in principle we could implement all our primops using `foreign import prim` (except that we want to optimise by generating code directly for some of them). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 16:39:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 16:39:09 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.e5f40f3993a246e8f4a91398e9bcc007@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I didn't see #13418. In lieu of Trac, can you post the code somewhere else? Perhaps inline in a comment, or through a site like gist.github.com? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 18:07:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 18:07:14 -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.f751cab3d30823282988737e9e910924@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 bgamari): Replying to [comment:11 angerman]: > Ok. Let's do this. I will deviate a bit from the plan in the proposal though. The rough idea is: > > - replace opt+llc with clang. This does imply that we loose the mangler, and probably won't be able to do `-split-obj` at all. I won't lose much sleep over losing split objects. Frankly, I look forward to the day when we can drop it entirely. However, it seems like the the mangler/AVX situation may be a bit trickier. > - build a release llvm-clang with necessary ghc changes, and call this `ghc-clang`, until we all ghc relevant patches are upstream in llvm. > - provide binary distributions for said `ghc-clang` for at least all tire1 platforms. Other platform will have to build clang from source. > As we discussed on IRC, I really would like to avoid coming to rely on our own LLVM builds if possible. Let's instead try to just get the patches we need upstream if at all possible. Then we can just piggy-back on the upstream LLVM binary distributions. > This should hopefully allow us to drop quite a bit of code from the llvm backend. It might re-introduce some new bugs. We do have quite a few hacks here and there to work around bugs in the llvm toolchain, for which we do not necessarily know if they are still present in the llvm toolchain we currently support. > Can you list these? I tried to think of what this refers to but I can't think of anything off the top of my head. > This should allow us to pin the llvm backend to a certain (potentially customized) clang version. This should be an interim solution only though. Hopefully we'll have all the necessary changes in llvm upstreamed by the time llvm5 (~6mo from now) or llvm6 (~12mo from now), will be released. Right. I see no real reason why it should take longer than six months to get our changes upstream. Thanks for picking this up, angerman! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 18:22:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 18:22:23 -0000 Subject: [GHC] #13419: Testing. Message-ID: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> #13419: Testing. -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This is only a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 18:29:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 18:29:27 -0000 Subject: [GHC] #13419: Testing. In-Reply-To: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> References: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> Message-ID: <061.001590b6916feb7cd3d4c0cfba8042c8@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 18:30:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 18:30:26 -0000 Subject: [GHC] #13419: Testing. In-Reply-To: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> References: <046.f0436982b0eca5a9e13e758f813229f3@haskell.org> Message-ID: <061.567827e35c66351f161c9e34ad5d9f59@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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 20:36:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 20:36:25 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.6ef1b41a22e83b2769ddd74098df37d2@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case ----------------------------+------------------------------ Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+------------------------------ Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Sorry, I've tried reproducing this and I can plug and remove the memory card but GHCi keeps working fine. I don't understand why GHCi would be using the card at all. In all likeliness this error is coming from a different process. GHC as a whole never produces errors using messageboxes, so this error does not originate from it. It is also a standard Windows error produced by explorer. So I will close the ticket as invalid. However if you can show the error does somehow come from GHCi then please re-open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 20:43:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 20:43:07 -0000 Subject: [GHC] #13298: Compact API design improvements In-Reply-To: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> References: <045.8bb98f92aac95f55a8274169903d2a71@haskell.org> Message-ID: <060.aa7458bef7b47b112bd037c46018b583@haskell.org> #13298: Compact API design improvements -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Yeah; even if it isn't, we can ship changes to the compact library (now not in GHC) as necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 20:52:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 20:52:27 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.eb63b365e49c6c223a08e124bb4f4f3a@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Generics 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:D3337 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3337 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 21:06:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 21:06:28 -0000 Subject: [GHC] #13414: shebang + literate haskell causes line numbering skew In-Reply-To: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> References: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> Message-ID: <060.d30afb905746c8a957d55d576a091d9b@haskell.org> #13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 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): Phab:D3333 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c77b767098be53087e0b06ba23d613dd7c3bcf8e/ghc" c77b767/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c77b767098be53087e0b06ba23d613dd7c3bcf8e" unlit: replace the SHEBANG with an empty line This corrects the line numbers for literate code after a shebang. Fixes #13414. Test Plan: validate Reviewers: austin, bgamari, trofi Reviewed By: bgamari, trofi Subscribers: trofi, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3333 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 21:25:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 21:25:00 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.92d097a512b9a274929ce6a97dd2d032@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I hate to say so, but I doubt it. Fixing this requires making some substantive changes to the flattener (specifically, changing "flattened types have flattened kinds" to "flattening does not change a type's kind"). Making this change in the presence of tycons with kind polymorphism will require some delicate work. It will all add up to more time than I have, I'm afraid. Merging the far simpler D3315 and D3316 patches seems to be hard enough these days. (Though I've finally figured out that my compilation server is acting unreliably, taking up more of my time than I have to offer. Will continue to work locally to get those patches in.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 21:41:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 21:41:04 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs In-Reply-To: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> References: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> Message-ID: <061.b8bc1b3dadfca9a24ab58ec1786d0ba9@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge Comment: Merged to `master` in e61b4a4169da17cd7b77f9dc09e3627eff1ff559. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 21:41:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 21:41:42 -0000 Subject: [GHC] #13326: Implement `-ferror-limit` for GHC In-Reply-To: <047.99e5f0e5b0cd996428b6bbf87ebc89d6@haskell.org> References: <047.99e5f0e5b0cd996428b6bbf87ebc89d6@haskell.org> Message-ID: <062.04b756dd90bb8babeb5dc1cf219697b8@haskell.org> #13326: Implement `-ferror-limit` for GHC -------------------------------------+------------------------------------- Reporter: coopercm | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.1 Comment: Merged in 70274b4f8003fde0fa3e4094a10dfae880579786. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 21:44:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 21:44:42 -0000 Subject: [GHC] #13414: shebang + literate haskell causes line numbering skew In-Reply-To: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> References: <045.afbf5aa0d0b557af7e0f0b55fd5e06b1@haskell.org> Message-ID: <060.2c8ac1d9f38ecd5f052bc7162c449b43@haskell.org> #13414: shebang + literate haskell causes line numbering skew -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: | Differential Rev(s): Phab:D3333 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` as bd3c648dc22e7e268c6390db822a704dc61b14b7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 21:45:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 21:45:07 -0000 Subject: [GHC] #13326: Implement `-ferror-limit` for GHC In-Reply-To: <047.99e5f0e5b0cd996428b6bbf87ebc89d6@haskell.org> References: <047.99e5f0e5b0cd996428b6bbf87ebc89d6@haskell.org> Message-ID: <062.2931381b1dd4f77bbbfd94f37399562b@haskell.org> #13326: Implement `-ferror-limit` for GHC -------------------------------------+------------------------------------- Reporter: coopercm | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 6e4c238274bdd2aea38f833ef32ac028843468c6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 22:28:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 22:28:59 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.1be795406952d195de86387af9f9dfb1@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes please! We need that code :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 23:33:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 23:33:59 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.51c45f46da37f8e3a61b2639d1c33b7d@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: lukemauer (added) Comment: Luke, do you think you could look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 23:45:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 23:45:21 -0000 Subject: [GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels In-Reply-To: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> References: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> Message-ID: <064.3b8e193a7a1b9564ffcc5c2190921eb2@haskell.org> #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"08e73ccf4c75a7d7a8b8167d2ccf8bc505fe1130/ghc" 08e73cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08e73ccf4c75a7d7a8b8167d2ccf8bc505fe1130" Fix #13382: Put join ceiling underneath lambdas Test Plan: No new test (bug is latent) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3285 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 13 23:49:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Mar 2017 23:49:52 -0000 Subject: [GHC] #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels In-Reply-To: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> References: <049.e44a39657ffc0862c20522b1948cd4a1@haskell.org> Message-ID: <064.bd793ef81290b38638373e91620bb38b@haskell.org> #13382: Join ceilings incorrectly getting placed outside value lambdas by SetLevels -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: closed Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` as 7ace4f0c377d0dd851283eefa8f473322d67afed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 00:35:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 00:35:16 -0000 Subject: [GHC] #13420: Bizarre pretty-printing of closed type families in GHCi Message-ID: <050.a32cc0d5ed53957b2700ec4bfc9a9b56@haskell.org> #13420: Bizarre pretty-printing of closed type families in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family F a where F [Int] = Bool F [a] = Double F (a b) = Char }}} into GHCi 8.0.1, 8.0.2, or HEAD, and run `:i F`. You'll see this: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs 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 ) Ok, modules loaded: Bug. λ> :i F type family F a :: * where F [Int] = Bool [a] F [a] = Double [b, (a :: * -> *)] F (a b) = Char -- Defined at Bug.hs:4:1 }}} Compare this with GHCi 7.10.3, where the pretty-printing is far more sane: {{{ $ /opt/ghc/7.10.3/bin/ghci Bug.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. λ> :i F type family F a :: * where F [Int] = Bool F [a] = Double F (a b) = Char -- Defined at Bug.hs:4:1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 00:36:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 00:36:47 -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.e04c5d1806844d1606801f397c4a6fe1@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 angerman): Replying to [comment:12 bgamari]: > Replying to [comment:11 angerman]: > > Ok. Let's do this. I will deviate a bit from the plan in the proposal though. The rough idea is: > > > > - replace opt+llc with clang. This does imply that we loose the mangler, and probably won't be able to do `-split-obj` at all. > > I won't lose much sleep over losing split objects. Frankly, I look forward to the day when we can drop it entirely. However, it seems like the the mangler/AVX situation may be a bit trickier. > As I've just said on irc, I wonder, assuming we did the obj-splitting at the cmm level, wouldn't we get split-obj for free in ncg and llvm? Yet, as [dobenour] mentioned, this would likely prevent inlining in the llvm backend. > > - build a release llvm-clang with necessary ghc changes, and call this `ghc-clang`, until we all ghc relevant patches are upstream in llvm. > > - provide binary distributions for said `ghc-clang` for at least all tire1 platforms. Other platform will have to build clang from source. > > > As we discussed on IRC, I really would like to avoid coming to rely on our own LLVM builds if possible. Let's instead try to just get the patches we need upstream if at all possible. Then we can just piggy-back on the upstream LLVM binary distributions. Yes this would be ideal. I'm just not convinced (with our track record), that we won't find some llvm fix we need just in time so it doesn't make it into llvm5. > > > This should hopefully allow us to drop quite a bit of code from the llvm backend. It might re-introduce some new bugs. We do have quite a few hacks here and there to work around bugs in the llvm toolchain, for which we do not necessarily know if they are still present in the llvm toolchain we currently support. > > > Can you list these? I tried to think of what this refers to but I can't think of anything off the top of my head. There are some of comments in the opt and llc phases, referring to bugs (e.g. macOS doesn't properly do -O3). Now dropping opt and llc and going just via clang, we do loose some control over the specific optimization flags we can pass, but in return get a stable unified interface. > > > This should allow us to pin the llvm backend to a certain (potentially customized) clang version. This should be an interim solution only though. Hopefully we'll have all the necessary changes in llvm upstreamed by the time llvm5 (~6mo from now) or llvm6 (~12mo from now), will be released. > > Right. I see no real reason why it should take longer than six months to get our changes upstream. On a final note: actually building a custom (static) clang to distribute seems rather simple. I've a makefile or ~10 lines that I believe would also work on linux and bsds; windows would need to be figured out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 01:09:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 01:09:13 -0000 Subject: [GHC] #13421: Confusing error when using BangPatterns without pragma Message-ID: <046.ba32e490f0ee514079b5d661a649f51f@haskell.org> #13421: Confusing error when using BangPatterns without pragma -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- If you have something like this {{{ putTagType :: TagType -> Put putTagType !x = putWord8 $! fromIntegral $! fromEnum x {-# INLINE putTagType #-} }}} and forget to put the pragma for BangPatterns you get this: {{{ /Users/kvanb/git/mineserver/mineserver- nbt/src/Mineserver/NBT/TagType.hs:40:1: error: The type signature for ‘putTagType’ lacks an accompanying binding /Users/kvanb/git/mineserver/mineserver- nbt/src/Mineserver/NBT/TagType.hs:42:12: error: The INLINE pragma for ‘putTagType’ lacks an accompanying binding Warning: File listed in mineserver-nbt/mineserver-nbt.cabal file does not exist: README.md }}} which leaves you very confused thinking you made a typo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 01:10:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 01:10:07 -0000 Subject: [GHC] #13421: Confusing error when using BangPatterns without pragma In-Reply-To: <046.ba32e490f0ee514079b5d661a649f51f@haskell.org> References: <046.ba32e490f0ee514079b5d661a649f51f@haskell.org> Message-ID: <061.0b347987c1234502a080dee6efe2e67e@haskell.org> #13421: Confusing error when using BangPatterns without pragma -------------------------------------+------------------------------------- Reporter: schyler | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by schyler): Would be nice if it said something like "Perhaps you meant to use -XBangPatterns?" like it does for all the type-level errors where you forget to use the pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 01:23:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 01:23:04 -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.1478b4b176a00556a2b218e198818b6a@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 angerman): Regarding `-split-obj`, #11445 makes me believe we can drop that altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 02:44:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 02:44:27 -0000 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@haskell.org> References: <047.8a8413861ff44b299752f57fbbb1dfd5@haskell.org> Message-ID: <062.f0ee715303435b9af521ff7f86fabf09@haskell.org> #3207: readMutVar# is inlined/duplicated -------------------------------------+------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | codeGen/should_run/3207 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This was closed by commit 8a3ed3364fbc74b1f1b87b049737da2b251f92df, which made a slew of "I/O-like" primops `has-side-effects`, even though they were "read-only". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 02:53:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 02:53:07 -0000 Subject: [GHC] #13422: INLINE CONLIKE sometimes fails to inline Message-ID: <045.24512f73acb84c676c1a559d500d9bab@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 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: -------------------------------------+------------------------------------- I got surprisingly poor results from the `cheapBuild` experiment (see #7206), so I decided to try a simple example. {{{#!hs foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} The idea is that we want `nums` to inline into `s` and `p`; the lost sharing is unimportant. Unfortunately, this didn't fuse. I got {{{ -- RHS size: {terms: 44, types: 31, coercions: 0, joins: 2/3} $wfoo :: Int# -> Int# $wfoo = \ (ww_s2HT :: Int#) -> let { nums_s2Gq :: [Int] nums_s2Gq = eftInt 1# ww_s2HT } in joinrec { $wgo_s2HP :: [Int] -> Int# -> Int# $wgo_s2HP (w_s2HJ :: [Int]) (ww1_s2HN :: Int#) = case w_s2HJ of { [] -> joinrec { $wgo1_s2HI :: [Int] -> Int# -> Int# $wgo1_s2HI (w1_s2HC :: [Int]) (ww2_s2HG :: Int#) = case w1_s2HC of { [] -> +# ww1_s2HN ww2_s2HG; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2Gf -> jump $wgo1_s2HI ys_a2Fa (*# ww2_s2HG y1_a2Gf) } }; } in jump $wgo1_s2HI nums_s2Gq 1#; : y_a2F9 ys_a2Fa -> case y_a2F9 of { I# y1_a2EX -> jump $wgo_s2HP ys_a2Fa (+# ww1_s2HN y1_a2EX) } }; } in jump $wgo_s2HP nums_s2Gq 0# -- RHS size: {terms: 10, types: 4, coercions: 0, joins: 0/0} foo :: Int -> Int foo = \ (w_s2HQ :: Int) -> case w_s2HQ of { I# ww1_s2HT -> case $wfoo ww1_s2HT of ww2_s2HX { __DEFAULT -> I# ww2_s2HX } } }}} I verified that `cheapBuild` actually appeared (in `-dverbose-core2core`), but it didn't fuse, and ultimately inlined. Interestingly, forcing the argument manually fixed the problem: {{{#!hs foo :: Int -> Int foo !n = s + p where nums = [1..n] s = sum nums p = product nums }}} produces {{{#!hs $wfoo :: Int# -> Int# $wfoo = \ (ww_s2Ia :: Int#) -> case tagToEnum# (># 1# ww_s2Ia) of { False -> joinrec { $wgo_s2I6 :: Int# -> Int# -> Int# $wgo_s2I6 (w_s2I0 :: Int#) (ww1_s2I4 :: Int#) = case tagToEnum# (==# w_s2I0 ww_s2Ia) of { False -> jump $wgo_s2I6 (+# w_s2I0 1#) (+# ww1_s2I4 w_s2I0); True -> let { x_X2Fz :: Int# x_X2Fz = +# ww1_s2I4 w_s2I0 } in joinrec { $wgo1_s2HY :: Int# -> Int# -> Int# $wgo1_s2HY (w1_s2HS :: Int#) (ww2_s2HW :: Int#) = case tagToEnum# (==# w1_s2HS ww_s2Ia) of { False -> jump $wgo1_s2HY (+# w1_s2HS 1#) (*# ww2_s2HW w1_s2HS); True -> +# x_X2Fz (*# ww2_s2HW w1_s2HS) }; } in jump $wgo1_s2HY 1# 1# }; } in jump $wgo_s2I6 1# 0#; True -> 1# } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 03:09:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 03:09:33 -0000 Subject: [GHC] #13423: Exception to I/O hack in demand analyzer too broad Message-ID: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> #13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- The I/O hack in the demand analyzer triggers only for expressions that are not direct applications of primops (see `io_hack_reqd` in `stranal/DmdAnal.hs`). This seems rather arbitrary, and can produce surprising results. Consider {{{#!hs fish :: Int -> IORef Int -> IORef Int -> IO () fish n ref next = do writeIORef ref n writeIORef next n x <- getLine case readMaybe x of Just True -> fish (n + 1) ref next _ -> pure () }}} If `next` is bottom, I would expect this to write `n` to `ref` and then throw an exception. But we actually get something else. First, the demand signature for `fish` ends up being `Str=`, which seems wrong. Then, as a result, worker/wrapper produces a wrapper that immediately unboxes both `IORef`s, so this is operationally wrong. Why do I think this is wrong? The story Haskell users are told, over and over, is that evaluation is driven only by execution; that we never force anything unless we need its value to determine the next `IO` action. That principle is violated here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 03:35:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 03:35:11 -0000 Subject: [GHC] #13424: readMutVar# is marked can_fail Message-ID: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> #13424: readMutVar# is marked can_fail -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- `readMutVar#` can only fail if its argument is not a valid pointer. As far as I know, we never check whether a pointer is valid; we ensure it's valid by construction. So I think we should set `can_fail = False`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 04:30:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 04:30:35 -0000 Subject: [GHC] #13424: readMutVar# is marked can_fail In-Reply-To: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> References: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> Message-ID: <060.1fa86050a181d05ddab31b3800cdc1ce@haskell.org> #13424: readMutVar# is marked can_fail -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch 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): Phab:D3340 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3340 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 08:40:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 08:40:07 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.2cc802bb097239539d84041a464edc45@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by dredozubov): I can reproduce this problem on a project i have right now. I don't think i'll be able to contribute any extra test cases, it's quite big. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 09:24:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 09:24:56 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 Message-ID: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | 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: -------------------------------------+------------------------------------- The following code shows inconsistent results when compiled with -O1: {{{#!hs import Data.Bits ((.&.)) flags :: Int -> [Int] flags x = filter (\y -> x .&. y > 0) [1, 128, 129, 255] main :: IO () main = do putStrLn $ show $ flags $ 255 -- These lines should display putStrLn (show (flags 255)) -- the same value, right? -- It appears that this is related to something that started -- with GHC 7.10, but was also changed in GHC 8.0, as we can -- see from the following tests: -- -- Stack snapshot lts-0.7 (GHC 7.8.3), with -O2 -- [1,128,129,255] -- [1,128,129,255] -- -- Stack snapshot lts-2.22 (GHC 7.8.4) with -O2 -- [1,128,129,255] -- [1,128,129,255] -- -- Stack snapshot lts-3.22 (GHC 7.10.2) with -O2 -- [1] -- [1] -- -- Stack snapshot lts-6.30 (GHC 7.10.3) with -O2 -- [1] -- [1] -- -- Stack snapshot lts-7.20 (GHC 8.0.1) with -O2 -- [1] -- [1,128,129,255] -- -- Stack snapshot lts-8.5 (GHC 8.0.2) with -O2 -- [1] -- [1,128,129,255] -- -- In GHC 8.0.2, compiling with any of the following... -- -O0 -- -O2 -fno-cmm-sink -- -O2 -fno-enable-rewrite-rules -- -- ...we get the expected results: -- [1,128,129,255] -- [1,128,129,255] -- -- Using only -O1, we get the abnormal behavior again: -- [1] -- [1,128,129,255] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 10:47:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 10:47:13 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.4eaad424773189bfc3429ff9493f846c@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case ----------------------------+------------------------------ Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+------------------------------ Changes (by vanto): * status: closed => new * resolution: invalid => Comment: Hi,\\ If the issue is not GHC, the issue comes from the package Haskell platform for Windows.\\ Seemingly the issue comes from realgcc.exe, and realgcc is part of mingw in ghc-8.0.2 directory.\\ In your computer GHCi works fine and it is not broken by that instead of mine.\\ What computer do you prefer to work with GHCi?\\ Give me your e-mail and I send to you a screenshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 11:34:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 11:34:52 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.b8be25b1ff7bd0275a0ec74911f87864@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ralf): > {-# LANGUAGE NPlusKPatterns #-} > module FactorialSequ > where > import Data.List > data Sequ1 a > = D10 (Sequ2 (a, a)) > | D11 a (Sequ2 (a, a)) > | E1 > deriving (Show) > data Sequ2 a > = D20 (Sequ3 (a, a, a)) > | D21 a (Sequ3 (a, a, a)) > | D22 a a (Sequ3 (a, a, a)) > | E2 > deriving (Show) > data Sequ3 a > = D30 (Sequ4 (a, a, a, a)) > | D31 a (Sequ4 (a, a, a, a)) > | D32 a a (Sequ4 (a, a, a, a)) > | D33 a a a (Sequ4 (a, a, a, a)) > | E3 > deriving (Show) > data Sequ4 a > = D40 (Sequ5 (a, a, a, a, a)) > | D41 a (Sequ5 (a, a, a, a, a)) > | D42 a a (Sequ5 (a, a, a, a, a)) > | D43 a a a (Sequ5 (a, a, a, a, a)) > | D44 a a a a (Sequ5 (a, a, a, a, a)) > | E4 > deriving (Show) > data Sequ5 a > = D50 (Sequ6 (a, a, a, a, a, a)) > | D51 a (Sequ6 (a, a, a, a, a, a)) > | D52 a a (Sequ6 (a, a, a, a, a, a)) > | D53 a a a (Sequ6 (a, a, a, a, a, a)) > | D54 a a a a (Sequ6 (a, a, a, a, a, a)) > | D55 a a a a a (Sequ6 (a, a, a, a, a, a)) > | E5 > deriving (Show) > data Sequ6 a > = D60 (Sequ7 (a, a, a, a, a, a, a)) > | D61 a (Sequ7 (a, a, a, a, a, a, a)) > | D62 a a (Sequ7 (a, a, a, a, a, a, a)) > | D63 a a a (Sequ7 (a, a, a, a, a, a, a)) > | D64 a a a a (Sequ7 (a, a, a, a, a, a, a)) > | D65 a a a a a (Sequ7 (a, a, a, a, a, a, a)) > | D66 a a a a a a (Sequ7 (a, a, a, a, a, a, a)) > | E6 > deriving (Show) > data Sequ7 a = E7 > deriving (Show) > ix2 (a0, a1) 0 = a0 > ix2 (a0, a1) 1 = a1 > > ix3 (a0, a1, a2) 0 = a0 > ix3 (a0, a1, a2) 1 = a1 > ix3 (a0, a1, a2) 2 = a2 > ix4 (a0, a1, a2, a3) 0 = a0 > ix4 (a0, a1, a2, a3) 1 = a1 > ix4 (a0, a1, a2, a3) 2 = a2 > ix4 (a0, a1, a2, a3) 3 = a3 > ix5 (a0, a1, a2, a3, a4) 0 = a0 > ix5 (a0, a1, a2, a3, a4) 1 = a1 > ix5 (a0, a1, a2, a3, a4) 2 = a2 > ix5 (a0, a1, a2, a3, a4) 3 = a3 > ix5 (a0, a1, a2, a3, a4) 4 = a4 > ix6 (a0, a1, a2, a3, a4, a5) 0 = a0 > ix6 (a0, a1, a2, a3, a4, a5) 1 = a1 > ix6 (a0, a1, a2, a3, a4, a5) 2 = a2 > ix6 (a0, a1, a2, a3, a4, a5) 3 = a3 > ix6 (a0, a1, a2, a3, a4, a5) 4 = a4 > ix6 (a0, a1, a2, a3, a4, a5) 5 = a5 > ix7 (a0, a1, a2, a3, a4, a5, a6) 0 = a0 > ix7 (a0, a1, a2, a3, a4, a5, a6) 1 = a1 > ix7 (a0, a1, a2, a3, a4, a5, a6) 2 = a2 > ix7 (a0, a1, a2, a3, a4, a5, a6) 3 = a3 > ix7 (a0, a1, a2, a3, a4, a5, a6) 4 = a4 > ix7 (a0, a1, a2, a3, a4, a5, a6) 5 = a5 > ix7 (a0, a1, a2, a3, a4, a5, a6) 6 = a6 > cons1 a0 (D10 s) = D11 a0 s > cons1 a0 (D11 a1 s) = D10 (cons2 (a0, a1) s) > cons1 a0 (E1) = D11 a0 E2 > cons2 a0 (D20 s) = D21 a0 s > cons2 a0 (D21 a1 s) = D22 a0 a1 s > cons2 a0 (D22 a1 a2 s) = D20 (cons3 (a0, a1, a2) s) > cons2 a0 (E2) = D21 a0 E3 > cons3 a0 (D30 s) = D31 a0 s > cons3 a0 (D31 a1 s) = D32 a0 a1 s > cons3 a0 (D32 a1 a2 s) = D33 a0 a1 a2 s > cons3 a0 (D33 a1 a2 a3 s) = D30 (cons4 (a0, a1, a2, a3) s) > cons3 a0 (E3) = D31 a0 E4 > cons4 a0 (D40 s) = D41 a0 s > cons4 a0 (D41 a1 s) = D42 a0 a1 s > cons4 a0 (D42 a1 a2 s) = D43 a0 a1 a2 s > cons4 a0 (D43 a1 a2 a3 s) = D44 a0 a1 a2 a3 s > cons4 a0 (D44 a1 a2 a3 a4 s) = D40 (cons5 (a0, a1, a2, a3, a4) s) > cons4 a0 (E4) = D41 a0 E5 > cons5 a0 (D50 s) = D51 a0 s > cons5 a0 (D51 a1 s) = D52 a0 a1 s > cons5 a0 (D52 a1 a2 s) = D53 a0 a1 a2 s > cons5 a0 (D53 a1 a2 a3 s) = D54 a0 a1 a2 a3 s > cons5 a0 (D54 a1 a2 a3 a4 s) = D55 a0 a1 a2 a3 a4 s > cons5 a0 (D55 a1 a2 a3 a4 a5 s) = D50 (cons6 (a0, a1, a2, a3, a4, a5) s) > cons5 a0 (E5) = D51 a0 E6 > cons6 a0 (D60 s) = D61 a0 s > cons6 a0 (D61 a1 s) = D62 a0 a1 s > cons6 a0 (D62 a1 a2 s) = D63 a0 a1 a2 s > cons6 a0 (D63 a1 a2 a3 s) = D64 a0 a1 a2 a3 s > cons6 a0 (D64 a1 a2 a3 a4 s) = D65 a0 a1 a2 a3 a4 s > cons6 a0 (D65 a1 a2 a3 a4 a5 s) = D66 a0 a1 a2 a3 a4 a5 s > cons6 a0 (D66 a1 a2 a3 a4 a5 a6 s) = D60 (cons7 (a0, a1, a2, a3, a4, a5, a6) s) > cons6 a0 (E6) = D61 a0 E7 > cons7 a0 E7 = E7 > lookup1 n (D10 s) = lookup2 (n `div` 2) s `ix2` (n `mod` 2) > lookup1 0 (D11 a0 s) = a0 > lookup1 (n + 1) (D11 a0 s) = lookup2 (n `div` 2) s `ix2` (n `mod` 2) > lookup1 n (E1) = error "out of bounds" > lookup2 n (D20 s) = lookup3 (n `div` 3) s `ix3` (n `mod` 3) > lookup2 0 (D21 a0 s) = a0 > lookup2 (n + 1) (D21 a0 s) = lookup3 (n `div` 3) s `ix3` (n `mod` 3) > lookup2 0 (D22 a0 a1 s) = a0 > lookup2 1 (D22 a0 a1 s) = a1 > lookup2 (n + 2) (D22 a0 a1 s) = lookup3 (n `div` 3) s `ix3` (n `mod` 3) > lookup2 n (E2) = error "out of bounds" > lookup3 n (D30 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) > lookup3 0 (D31 a0 s) = a0 > lookup3 (n + 1) (D31 a0 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) > lookup3 0 (D32 a0 a1 s) = a0 > lookup3 1 (D32 a0 a1 s) = a1 > lookup3 (n + 2) (D32 a0 a1 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) > lookup3 0 (D33 a0 a1 a2 s) = a0 > lookup3 1 (D33 a0 a1 a2 s) = a1 > lookup3 2 (D33 a0 a1 a2 s) = a2 > lookup3 (n + 3) (D33 a0 a1 a2 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) > lookup3 n (E3) = error "out of bounds" > lookup4 n (D40 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) > lookup4 0 (D41 a0 s) = a0 > lookup4 (n + 1) (D41 a0 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) > lookup4 0 (D42 a0 a1 s) = a0 > lookup4 1 (D42 a0 a1 s) = a1 > lookup4 (n + 2) (D42 a0 a1 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) > lookup4 0 (D43 a0 a1 a2 s) = a0 > lookup4 1 (D43 a0 a1 a2 s) = a1 > lookup4 2 (D43 a0 a1 a2 s) = a2 > lookup4 (n + 3) (D43 a0 a1 a2 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) > lookup4 0 (D44 a0 a1 a2 a3 s) = a0 > lookup4 1 (D44 a0 a1 a2 a3 s) = a1 > lookup4 2 (D44 a0 a1 a2 a3 s) = a2 > lookup4 3 (D44 a0 a1 a2 a3 s) = a3 > lookup4 (n + 4) (D44 a0 a1 a2 a3 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) > lookup5 n (D50 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) > lookup5 0 (D51 a0 s) = a0 > lookup5 (n + 1) (D51 a0 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) > lookup5 0 (D52 a0 a1 s) = a0 > lookup5 1 (D52 a0 a1 s) = a1 > lookup5 (n + 2) (D52 a0 a1 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) > lookup5 0 (D53 a0 a1 a2 s) = a0 > lookup5 1 (D53 a0 a1 a2 s) = a1 > lookup5 2 (D53 a0 a1 a2 s) = a2 > lookup5 (n + 3) (D53 a0 a1 a2 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) > lookup5 0 (D54 a0 a1 a2 a3 s) = a0 > lookup5 1 (D54 a0 a1 a2 a3 s) = a1 > lookup5 2 (D54 a0 a1 a2 a3 s) = a2 > lookup5 3 (D54 a0 a1 a2 a3 s) = a3 > lookup5 (n + 4) (D54 a0 a1 a2 a3 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) > lookup5 0 (D55 a0 a1 a2 a3 a4 s) = a0 > lookup5 1 (D55 a0 a1 a2 a3 a4 s) = a1 > lookup5 2 (D55 a0 a1 a2 a3 a4 s) = a2 > lookup5 3 (D55 a0 a1 a2 a3 a4 s) = a3 > lookup5 4 (D55 a0 a1 a2 a3 a4 s) = a4 > lookup5 (n + 5) (D55 a0 a1 a2 a3 a4 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) > lookup6 n (D60 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup6 0 (D61 a0 s) = a0 > lookup6 (n + 1) (D61 a0 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup6 0 (D62 a0 a1 s) = a0 > lookup6 1 (D62 a0 a1 s) = a1 > lookup6 (n + 2) (D62 a0 a1 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup6 0 (D63 a0 a1 a2 s) = a0 > lookup6 1 (D63 a0 a1 a2 s) = a1 > lookup6 2 (D63 a0 a1 a2 s) = a2 > lookup6 (n + 3) (D63 a0 a1 a2 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup6 0 (D64 a0 a1 a2 a3 s) = a0 > lookup6 1 (D64 a0 a1 a2 a3 s) = a1 > lookup6 2 (D64 a0 a1 a2 a3 s) = a2 > lookup6 3 (D64 a0 a1 a2 a3 s) = a3 > lookup6 (n + 4) (D64 a0 a1 a2 a3 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup6 0 (D65 a0 a1 a2 a3 a4 s) = a0 > lookup6 1 (D65 a0 a1 a2 a3 a4 s) = a1 > lookup6 2 (D65 a0 a1 a2 a3 a4 s) = a2 > lookup6 3 (D65 a0 a1 a2 a3 a4 s) = a3 > lookup6 4 (D65 a0 a1 a2 a3 a4 s) = a4 > lookup6 (n + 5) (D65 a0 a1 a2 a3 a4 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup6 0 (D66 a0 a1 a2 a3 a4 a5 s) = a0 > lookup6 1 (D66 a0 a1 a2 a3 a4 a5 s) = a1 > lookup6 2 (D66 a0 a1 a2 a3 a4 a5 s) = a2 > lookup6 3 (D66 a0 a1 a2 a3 a4 a5 s) = a3 > lookup6 4 (D66 a0 a1 a2 a3 a4 a5 s) = a4 > lookup6 5 (D66 a0 a1 a2 a3 a4 a5 s) = a5 > lookup6 (n + 6) (D66 a0 a1 a2 a3 a4 a5 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) > lookup7 n s = error "out of bounds" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 11:35:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 11:35:29 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.c35d2d7e39e6b18a59c839410f914110@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ralf): no idea how to turn the formatting off; hope that works for you -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 11:41:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 11:41:01 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.95f4510cdf58c63020bb7e34bf743a09@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): {{{#!hs {-# LANGUAGE NPlusKPatterns #-} module FactorialSequ where import Data.List data Sequ1 a = D10 (Sequ2 (a, a)) | D11 a (Sequ2 (a, a)) | E1 deriving (Show) data Sequ2 a = D20 (Sequ3 (a, a, a)) | D21 a (Sequ3 (a, a, a)) | D22 a a (Sequ3 (a, a, a)) | E2 deriving (Show) data Sequ3 a = D30 (Sequ4 (a, a, a, a)) | D31 a (Sequ4 (a, a, a, a)) | D32 a a (Sequ4 (a, a, a, a)) | D33 a a a (Sequ4 (a, a, a, a)) | E3 deriving (Show) data Sequ4 a = D40 (Sequ5 (a, a, a, a, a)) | D41 a (Sequ5 (a, a, a, a, a)) | D42 a a (Sequ5 (a, a, a, a, a)) | D43 a a a (Sequ5 (a, a, a, a, a)) | D44 a a a a (Sequ5 (a, a, a, a, a)) | E4 deriving (Show) data Sequ5 a = D50 (Sequ6 (a, a, a, a, a, a)) | D51 a (Sequ6 (a, a, a, a, a, a)) | D52 a a (Sequ6 (a, a, a, a, a, a)) | D53 a a a (Sequ6 (a, a, a, a, a, a)) | D54 a a a a (Sequ6 (a, a, a, a, a, a)) | D55 a a a a a (Sequ6 (a, a, a, a, a, a)) | E5 deriving (Show) data Sequ6 a = D60 (Sequ7 (a, a, a, a, a, a, a)) | D61 a (Sequ7 (a, a, a, a, a, a, a)) | D62 a a (Sequ7 (a, a, a, a, a, a, a)) | D63 a a a (Sequ7 (a, a, a, a, a, a, a)) | D64 a a a a (Sequ7 (a, a, a, a, a, a, a)) | D65 a a a a a (Sequ7 (a, a, a, a, a, a, a)) | D66 a a a a a a (Sequ7 (a, a, a, a, a, a, a)) | E6 deriving (Show) data Sequ7 a = E7 deriving (Show) ix2 (a0, a1) 0 = a0 ix2 (a0, a1) 1 = a1 ix3 (a0, a1, a2) 0 = a0 ix3 (a0, a1, a2) 1 = a1 ix3 (a0, a1, a2) 2 = a2 ix4 (a0, a1, a2, a3) 0 = a0 ix4 (a0, a1, a2, a3) 1 = a1 ix4 (a0, a1, a2, a3) 2 = a2 ix4 (a0, a1, a2, a3) 3 = a3 ix5 (a0, a1, a2, a3, a4) 0 = a0 ix5 (a0, a1, a2, a3, a4) 1 = a1 ix5 (a0, a1, a2, a3, a4) 2 = a2 ix5 (a0, a1, a2, a3, a4) 3 = a3 ix5 (a0, a1, a2, a3, a4) 4 = a4 ix6 (a0, a1, a2, a3, a4, a5) 0 = a0 ix6 (a0, a1, a2, a3, a4, a5) 1 = a1 ix6 (a0, a1, a2, a3, a4, a5) 2 = a2 ix6 (a0, a1, a2, a3, a4, a5) 3 = a3 ix6 (a0, a1, a2, a3, a4, a5) 4 = a4 ix6 (a0, a1, a2, a3, a4, a5) 5 = a5 ix7 (a0, a1, a2, a3, a4, a5, a6) 0 = a0 ix7 (a0, a1, a2, a3, a4, a5, a6) 1 = a1 ix7 (a0, a1, a2, a3, a4, a5, a6) 2 = a2 ix7 (a0, a1, a2, a3, a4, a5, a6) 3 = a3 ix7 (a0, a1, a2, a3, a4, a5, a6) 4 = a4 ix7 (a0, a1, a2, a3, a4, a5, a6) 5 = a5 ix7 (a0, a1, a2, a3, a4, a5, a6) 6 = a6 cons1 a0 (D10 s) = D11 a0 s cons1 a0 (D11 a1 s) = D10 (cons2 (a0, a1) s) cons1 a0 (E1) = D11 a0 E2 cons2 a0 (D20 s) = D21 a0 s cons2 a0 (D21 a1 s) = D22 a0 a1 s cons2 a0 (D22 a1 a2 s) = D20 (cons3 (a0, a1, a2) s) cons2 a0 (E2) = D21 a0 E3 cons3 a0 (D30 s) = D31 a0 s cons3 a0 (D31 a1 s) = D32 a0 a1 s cons3 a0 (D32 a1 a2 s) = D33 a0 a1 a2 s cons3 a0 (D33 a1 a2 a3 s) = D30 (cons4 (a0, a1, a2, a3) s) cons3 a0 (E3) = D31 a0 E4 cons4 a0 (D40 s) = D41 a0 s cons4 a0 (D41 a1 s) = D42 a0 a1 s cons4 a0 (D42 a1 a2 s) = D43 a0 a1 a2 s cons4 a0 (D43 a1 a2 a3 s) = D44 a0 a1 a2 a3 s cons4 a0 (D44 a1 a2 a3 a4 s) = D40 (cons5 (a0, a1, a2, a3, a4) s) cons4 a0 (E4) = D41 a0 E5 cons5 a0 (D50 s) = D51 a0 s cons5 a0 (D51 a1 s) = D52 a0 a1 s cons5 a0 (D52 a1 a2 s) = D53 a0 a1 a2 s cons5 a0 (D53 a1 a2 a3 s) = D54 a0 a1 a2 a3 s cons5 a0 (D54 a1 a2 a3 a4 s) = D55 a0 a1 a2 a3 a4 s cons5 a0 (D55 a1 a2 a3 a4 a5 s) = D50 (cons6 (a0, a1, a2, a3, a4, a5) s) cons5 a0 (E5) = D51 a0 E6 cons6 a0 (D60 s) = D61 a0 s cons6 a0 (D61 a1 s) = D62 a0 a1 s cons6 a0 (D62 a1 a2 s) = D63 a0 a1 a2 s cons6 a0 (D63 a1 a2 a3 s) = D64 a0 a1 a2 a3 s cons6 a0 (D64 a1 a2 a3 a4 s) = D65 a0 a1 a2 a3 a4 s cons6 a0 (D65 a1 a2 a3 a4 a5 s) = D66 a0 a1 a2 a3 a4 a5 s cons6 a0 (D66 a1 a2 a3 a4 a5 a6 s) = D60 (cons7 (a0, a1, a2, a3, a4, a5, a6) s) cons6 a0 (E6) = D61 a0 E7 cons7 a0 E7 = E7 lookup1 n (D10 s) = lookup2 (n `div` 2) s `ix2` (n `mod` 2) lookup1 0 (D11 a0 s) = a0 lookup1 (n + 1) (D11 a0 s) = lookup2 (n `div` 2) s `ix2` (n `mod` 2) lookup1 n (E1) = error "out of bounds" lookup2 n (D20 s) = lookup3 (n `div` 3) s `ix3` (n `mod` 3) lookup2 0 (D21 a0 s) = a0 lookup2 (n + 1) (D21 a0 s) = lookup3 (n `div` 3) s `ix3` (n `mod` 3) lookup2 0 (D22 a0 a1 s) = a0 lookup2 1 (D22 a0 a1 s) = a1 lookup2 (n + 2) (D22 a0 a1 s) = lookup3 (n `div` 3) s `ix3` (n `mod` 3) lookup2 n (E2) = error "out of bounds" lookup3 n (D30 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) lookup3 0 (D31 a0 s) = a0 lookup3 (n + 1) (D31 a0 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) lookup3 0 (D32 a0 a1 s) = a0 lookup3 1 (D32 a0 a1 s) = a1 lookup3 (n + 2) (D32 a0 a1 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) lookup3 0 (D33 a0 a1 a2 s) = a0 lookup3 1 (D33 a0 a1 a2 s) = a1 lookup3 2 (D33 a0 a1 a2 s) = a2 lookup3 (n + 3) (D33 a0 a1 a2 s) = lookup4 (n `div` 4) s `ix4` (n `mod` 4) lookup3 n (E3) = error "out of bounds" lookup4 n (D40 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) lookup4 0 (D41 a0 s) = a0 lookup4 (n + 1) (D41 a0 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) lookup4 0 (D42 a0 a1 s) = a0 lookup4 1 (D42 a0 a1 s) = a1 lookup4 (n + 2) (D42 a0 a1 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) lookup4 0 (D43 a0 a1 a2 s) = a0 lookup4 1 (D43 a0 a1 a2 s) = a1 lookup4 2 (D43 a0 a1 a2 s) = a2 lookup4 (n + 3) (D43 a0 a1 a2 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) lookup4 0 (D44 a0 a1 a2 a3 s) = a0 lookup4 1 (D44 a0 a1 a2 a3 s) = a1 lookup4 2 (D44 a0 a1 a2 a3 s) = a2 lookup4 3 (D44 a0 a1 a2 a3 s) = a3 lookup4 (n + 4) (D44 a0 a1 a2 a3 s) = lookup5 (n `div` 5) s `ix5` (n `mod` 5) lookup5 n (D50 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) lookup5 0 (D51 a0 s) = a0 lookup5 (n + 1) (D51 a0 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) lookup5 0 (D52 a0 a1 s) = a0 lookup5 1 (D52 a0 a1 s) = a1 lookup5 (n + 2) (D52 a0 a1 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) lookup5 0 (D53 a0 a1 a2 s) = a0 lookup5 1 (D53 a0 a1 a2 s) = a1 lookup5 2 (D53 a0 a1 a2 s) = a2 lookup5 (n + 3) (D53 a0 a1 a2 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) lookup5 0 (D54 a0 a1 a2 a3 s) = a0 lookup5 1 (D54 a0 a1 a2 a3 s) = a1 lookup5 2 (D54 a0 a1 a2 a3 s) = a2 lookup5 3 (D54 a0 a1 a2 a3 s) = a3 lookup5 (n + 4) (D54 a0 a1 a2 a3 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) lookup5 0 (D55 a0 a1 a2 a3 a4 s) = a0 lookup5 1 (D55 a0 a1 a2 a3 a4 s) = a1 lookup5 2 (D55 a0 a1 a2 a3 a4 s) = a2 lookup5 3 (D55 a0 a1 a2 a3 a4 s) = a3 lookup5 4 (D55 a0 a1 a2 a3 a4 s) = a4 lookup5 (n + 5) (D55 a0 a1 a2 a3 a4 s) = lookup6 (n `div` 6) s `ix6` (n `mod` 6) lookup6 n (D60 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup6 0 (D61 a0 s) = a0 lookup6 (n + 1) (D61 a0 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup6 0 (D62 a0 a1 s) = a0 lookup6 1 (D62 a0 a1 s) = a1 lookup6 (n + 2) (D62 a0 a1 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup6 0 (D63 a0 a1 a2 s) = a0 lookup6 1 (D63 a0 a1 a2 s) = a1 lookup6 2 (D63 a0 a1 a2 s) = a2 lookup6 (n + 3) (D63 a0 a1 a2 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup6 0 (D64 a0 a1 a2 a3 s) = a0 lookup6 1 (D64 a0 a1 a2 a3 s) = a1 lookup6 2 (D64 a0 a1 a2 a3 s) = a2 lookup6 3 (D64 a0 a1 a2 a3 s) = a3 lookup6 (n + 4) (D64 a0 a1 a2 a3 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup6 0 (D65 a0 a1 a2 a3 a4 s) = a0 lookup6 1 (D65 a0 a1 a2 a3 a4 s) = a1 lookup6 2 (D65 a0 a1 a2 a3 a4 s) = a2 lookup6 3 (D65 a0 a1 a2 a3 a4 s) = a3 lookup6 4 (D65 a0 a1 a2 a3 a4 s) = a4 lookup6 (n + 5) (D65 a0 a1 a2 a3 a4 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup6 0 (D66 a0 a1 a2 a3 a4 a5 s) = a0 lookup6 1 (D66 a0 a1 a2 a3 a4 a5 s) = a1 lookup6 2 (D66 a0 a1 a2 a3 a4 a5 s) = a2 lookup6 3 (D66 a0 a1 a2 a3 a4 a5 s) = a3 lookup6 4 (D66 a0 a1 a2 a3 a4 a5 s) = a4 lookup6 5 (D66 a0 a1 a2 a3 a4 a5 s) = a5 lookup6 (n + 6) (D66 a0 a1 a2 a3 a4 a5 s) = lookup7 (n `div` 7) s `ix7` (n `mod` 7) lookup7 n s = error "out of bounds" }}} It panics at -O2 with 8.0.2 but doesn't panic with HEAD. Does anyone know which ticket fixed this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 13:48:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 13:48:37 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.eb5d062ac27c11986feaa11d1856741c@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a simpler test case {{{ data T a = E7 cons7 :: T a -> T b cons7 E7 = E7 }}} Amazingly, this crashes 8.0.2, because of this egregious bug in `SimplUtils.mkCase1`: {{{ check_eq (Var v) (DataAlt con) [] = v == dataConWorkId con -- Optimisation only ... check_eq rhs (DataAlt con) args = cheapEqExpr' tickishFloatable rhs $ mkConApp con (arg_tys ++ varsToCoreExprs args) }}} The first of these equations ("optimisation only") is only equivalent to the second if `arg_tys` is empty, which it isn't in this case. This bug has been there since I introduced it in Nov 2011: {{{ commit 02ac2974ce8e537372bff8d9e0a6efb461ed2c59 Author: Simon Peyton Jones Date: Wed Nov 16 10:37:47 2011 +0000 Fix CaseIdentity optimisaion In fixing one bug I'd introduced another; case x of { T -> T; F -> F } wasn't getting optmised! Trivial to fix. }}} It's just rather hard to trigger. Unrelated changes in HEAD mean that it no longer shows up. But I'll fix it anyway! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 13:55:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 13:55:40 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.aea415fac89a8750e524fcc233465e00@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | 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: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"82b40598ea7a9c00abdeae37bc47896f880fbbdc/ghc" 82b4059/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="82b40598ea7a9c00abdeae37bc47896f880fbbdc" Fix CaseIdentity optimisation AGAIN In this commit commit 02ac2974ce8e537372bff8d9e0a6efb461ed2c59 Author: Simon Peyton Jones Date: Wed Nov 16 10:37:47 2011 +0000 Fix CaseIdentity optimisaion In fixing one bug I'd introduced another; case x of { T -> T; F -> F } wasn't getting optmised! Trivial to fix. I introduced yet another! This line of code in SimplUtils.mkCase1 check_eq (Var v) (DataAlt con) [] = v == dataConWorkId con -- Optimisation only is patently false when arg_tys is non-empty. Astonishing that it has not shown up before now. Easily fixed though. This was all shown up by Trac #13417, which is now fixed. Merge to 8.0, 8.2. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 13:58:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 13:58:02 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.8dd64347bec02262060926ab4c0503fc@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Thanks for a test case. Amazing bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:12:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:12:41 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.e841618fc92dfcc1d88d64337c5d5dc9@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.3 Old description: > Error provoked by attached H98 program (which is generated by a program); > compiles fine without optimizations; compilation with -O2 crashes: > > $ ghc --make -O2 FactorialSequ.lhs > [1 of 1] Compiling FactorialSequ ( FactorialSequ.lhs, FactorialSequ.o > ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > piResultTys1 > Sequ7 t_a2zl > [a_a2zm] New description: Error provoked by attached H98 program (which is generated by a program); compiles fine without optimizations; compilation with -O2 crashes: {{{ $ ghc --make -O2 FactorialSequ.lhs [1 of 1] Compiling FactorialSequ ( FactorialSequ.lhs, FactorialSequ.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): piResultTys1 Sequ7 t_a2zl [a_a2zm] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:31:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:31:24 -0000 Subject: [GHC] #13417: piResultTys1 In-Reply-To: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> References: <043.b01baee2855e1a031ae4c68420114cdf@haskell.org> Message-ID: <058.8f7db5aa2cafe4b1df9954d2e5225cc9@haskell.org> #13417: piResultTys1 -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as d2d13a4f6750e30389552974bd7465712d522735, `ghc-8.2` as dfd8f29eced6c2750b68bfa5d076306d0688eb09. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:32:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:32:15 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 Message-ID: <042.588059ee1290b666bd7f0947c071e1ff@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 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 notice that buildbots were having a hard-time building GHC 8.2 snapshots... so I investigated... One thing that jumped at me was the memory usage while compiling DynFlags which is the worst memory-offender with 4777MiB of resident size: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.2.0.201 70313 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen - icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompi ler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -pa ckage-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id fil epath-1.4.1.1 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc- boot-8.2.0.20170313 -package-id ghc-boot-th-8.2.0.20170313 -package-id ghci-8.2.0.20170 313 -package-id hoopl-3.10.2.2 -package-id unix-2.7.2.1 -package-id terminfo-0.4.0.2 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-t iming -O2 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/main/DynFlags.hs -o compiler/stage2/build/DynFlags.o -dyno compiler/stage2/build/DynFlags.dyn_o }}} {{{ <> }}} Then I did two clean full builds of the `ghc-8.0` and `ghc-8.2` branch, and collected the -Rghc-timings output into simple 3-columns .csv files; Here's are the respective top-12 entries for GHC 8.0 and GHC 8.2 respectively: {{{#!bash $ sort -t, -k2n build.80.csv | tail -n12 "inplace/bin/ghc-stage1",560,compiler/stage2/build/TcRnDriver.o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcRnDriver.p_o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcSplice.o "inplace/bin/ghc-stage1",847,compiler/stage2/build/OptCoercion.p_o "/opt/ghc/bin/ghc",979,compiler/stage1/build/OptCoercion.o "/opt/ghc/bin/ghc",1036,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1040,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1119,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",1123,compiler/stage2/build/DynFlags.o "inplace/bin/ghc-stage1",1178,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1233,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1282,compiler/stage2/build/X86/CodeGen.p_o }}} {{{#!bash $ sort -t, -k2n build.82.csv | tail -n12 "inplace/bin/ghc-stage1",891,compiler/stage2/build/CmmParse.p_o "/opt/ghc/bin/ghc",1053,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1058,compiler/stage1/build/OptCoercion.o "inplace/bin/ghc-stage1",1284,compiler/stage2/build/HsExpr.p_o "inplace/bin/ghc-stage1",1313,compiler/stage2/build/HsExpr.o "/opt/ghc/bin/ghc",1394,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1495,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1605,compiler/stage2/build/X86/CodeGen.p_o "inplace/bin/ghc-stage1",1620,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1733,compiler/stage2/build/OptCoercion.p_o "inplace/bin/ghc-stage1",3989,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",4777,compiler/stage2/build/DynFlags.o }}} What's apparent from this data: - GHC stage0 (which was GHC 8.0.2) is able to build DynFlags.o for GHC 8.0 and GHC 8.2 w/ roughtly the same amount of max resident memory, i.e. 1 GiB - **GHC 8.2 stage1 however needs 4 times the amount of memory more than GHC 8.0 to build the same `DynFlags.hs` module!** -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:39:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:39:00 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.2294e58cc40e948cb0749e3434e3d566@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:43:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:43:08 -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.cad77a68974cac5521cdafe7ceeb35a2@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * Attachment "ghc82-stage0-verbose-output.log" added. Compiling GHC 8.2's stage1 DynFlags.hs w/ stage0 (GHC 8.0.2) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:43:36 -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.b689ad0994b9b8db611bf0c30fafd00d@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * Attachment "ghc82-stage1-verbose-output.log" added. Compiling GHC 8.2's stage2 DynFlags.hs w/ stage1 (GHC 8.2) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 14:44:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 14:44:54 -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.d77c07d38b470def9482fbd85824a0ea@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is bad! Let's find out why. Something that egregious MUST have low-handing fruit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:15:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:15:19 -0000 Subject: [GHC] #13405: Reimplement unsafeInterleaveIO using runRW# In-Reply-To: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> References: <045.f6b9cdd877a1a491a0ab77ac7f5f61ab@haskell.org> Message-ID: <060.b5e5475b98eb37495b4772614ff0bd58@haskell.org> #13405: Reimplement unsafeInterleaveIO using runRW# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 dfeuer): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:16:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:16: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.a1b3aef3bab077a75bd97827959e9b1d@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I have similar numbers from after the join points commit (Feb 1) and they do not show this large regression. So my educated guess is that the new Typeable stuff is responsible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:23:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:23:12 -0000 Subject: [GHC] #13423: Exception to I/O hack in demand analyzer too broad In-Reply-To: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> References: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> Message-ID: <060.a274192ebcfe03c9f926db29e89a28d8@haskell.org> #13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- 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 rwbarton): Is this really wrong in this case though? In a single-threaded context there is no observable difference between writing an `IORef` and then diverging, and diverging immediately; and in a multi-threaded context the ordering of `writeIORef` with respect to anything else is not guaranteed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:31:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:31:35 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.99a7caf8dcb37c42588e593c1bd0857e@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Phab:3310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b335f506f1d3a766de849e015f6732ae130247a4/ghc" b335f50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b335f506f1d3a766de849e015f6732ae130247a4" Further document :type +v's role in analyzing -XTypeApplications in GHCi Summary: The section on `-XTypeApplications` in the users' guide isn't terribly clear on how to view the visibility of a function type signature's type variables in GHCi properly (i.e., using the `:type +v` GHCi command). This adds some more exposition that demonstrates how to use `:type +v` (and why you don't want to use `:type`). Fixes #13401. Test Plan: Eyeball it Reviewers: bgamari, austin, goldfire, crockeea Reviewed By: goldfire, crockeea Subscribers: rwbarton, thomie, crockeea Differential Revision: https://phabricator.haskell.org/D3310 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:31:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:31:35 -0000 Subject: [GHC] #11450: Associated types at wrong type in instance In-Reply-To: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> References: <046.09703aba3da5589c5c125eb008ef88e8@haskell.org> Message-ID: <061.53e10b522f1b4a0f1f22d7a560569eb9@haskell.org> #11450: Associated types at wrong type in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: indexed- invalid program | types/should_fail/T11450 Blocked By: | Blocking: Related Tickets: #11449, #11451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"67345ccf51538acf2b6452c738ba641b119f5a5e/ghc" 67345cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67345ccf51538acf2b6452c738ba641b119f5a5e" Allow associated types to pattern-match in non-class-bound variables Summary: After 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450), if you have a class with an associated type: ``` class C a where type T a b ``` And you try to create an instance of `C` like this: ``` instance C Int where type T Int Char = Bool ``` Then it is rejected, since you're trying to instantiate the variable ``b`` with something other than a type variable. But this restriction proves quite onerous in practice, as it prevents you from doing things like this: ``` class C a where type T a (b :: Identity c) :: c instance C Int where type T Int ('Identity x) = x ``` You have to resort to an auxiliary type family in order to define this now, which becomes extremely tiring. This lifts this restriction and fixes #13398, in which it was discovered that adding this restriction broke code in the wild. Test Plan: ./validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3302 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:31:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:31:35 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.f2039b646024fa31e81d4514423b97e5@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11450 | Differential Rev(s): Phab:D3302 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"67345ccf51538acf2b6452c738ba641b119f5a5e/ghc" 67345cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67345ccf51538acf2b6452c738ba641b119f5a5e" Allow associated types to pattern-match in non-class-bound variables Summary: After 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450), if you have a class with an associated type: ``` class C a where type T a b ``` And you try to create an instance of `C` like this: ``` instance C Int where type T Int Char = Bool ``` Then it is rejected, since you're trying to instantiate the variable ``b`` with something other than a type variable. But this restriction proves quite onerous in practice, as it prevents you from doing things like this: ``` class C a where type T a (b :: Identity c) :: c instance C Int where type T Int ('Identity x) = x ``` You have to resort to an auxiliary type family in order to define this now, which becomes extremely tiring. This lifts this restriction and fixes #13398, in which it was discovered that adding this restriction broke code in the wild. Test Plan: ./validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3302 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:39:33 -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.e37f34ee55a0ecc3db71f4d02fe1746a@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Ben suggested that reverting 2effe18ab51d66474724d38b20e49cc1b8738f60 could have an interesting effect... however it appears to have things worse :-) {{{ <> }}} I'll attach `--verbose` output as well -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:41:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:41:06 -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.835bc55285131afa1071173082e10c36@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * Attachment "ghc82-stage1-verbose-output.revert.log" added. Compiling GHC 8.2's stage2 DynFlags.hs w/ stage1 (GHC 8.2) & 2effe18ab reverted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:48:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:48:20 -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.50be8ce68fafdaa0320b53ed028ca08c@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * Attachment "ghc82-stage1-verbose-output.O1.log" added. Compiling GHC 8.2's stage2 DynFlags.hs w/ stage1 (GHC 8.2) (at -O1 instead of -O2; 2effe is NOT reverted here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:55:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:55:22 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.cd76ec389484b51dc72bfe48600a06e1@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Phab:3310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 15:56:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 15:56:15 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.2f2e94dfd5a49c9e99086052c84a7155@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13398a, | indexed- | types/should_compile/T13398b Blocked By: | Blocking: Related Tickets: #11450 | Differential Rev(s): Phab:D3302 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => indexed-types/should_compile/T13398a, indexed- types/should_compile/T13398b * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 16:40:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 16:40:49 -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.1fbe07279e65b6967a926f3421ee0517@haskell.org> #13420: Bizarre pretty-printing of closed type families in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: It looks like 6746549772c5cc0ac66c0fce562f297f4d4b80a2 (Kind equalities) is the culprit. In particular, before that commit, you had to enable `-fprint-explicit- foralls` in order to see something like this. In GHCi 7.10.3: {{{ GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( ../Bug.hs, interpreted ) Ok, modules loaded: Bug. λ> :set -fprint-explicit-foralls λ> :i F type family F a :: * where F [Int] = Bool forall a. F [a] = Double forall (a :: * -> *) b. F (a b) = Char -- Defined at ../Bug.hs:4:1 }}} But in GHC 8.0.1 and later, `-fprint-explicit-foralls` has no effect on the output. This part of the commit is responsible: {{{#!diff diff --git a/compiler/iface/IfaceSyn.hs b/compiler/iface/IfaceSyn.hs index 307a448..247566c 100644 (file) --- a/compiler/iface/IfaceSyn.hs +++ b/compiler/iface/IfaceSyn.hs @@ -511,14 +511,20 @@ pprAxBranch :: SDoc -> IfaceAxBranch -> SDoc -- be a branch for an imported TyCon, so it would be an ExtName -- So it's easier to take an SDoc here pprAxBranch pp_tc (IfaceAxBranch { ifaxbTyVars = tvs - , ifaxbLHS = pat_tys - , ifaxbRHS = rhs - , ifaxbIncomps = incomps }) - = hang (pprUserIfaceForAll tvs) - 2 (hang pp_lhs 2 (equals <+> ppr rhs)) + , ifaxbCoVars = cvs + , ifaxbLHS = pat_tys + , ifaxbRHS = rhs + , ifaxbIncomps = incomps }) + = hang ppr_binders 2 (hang pp_lhs 2 (equals <+> ppr rhs)) $+$ nest 2 maybe_incomps where + ppr_binders + | null tvs && null cvs = empty + | null cvs = brackets (pprWithCommas pprIfaceTvBndr tvs) + | otherwise + = brackets (pprWithCommas pprIfaceTvBndr tvs <> semi <+> + pprWithCommas pprIfaceIdBndr cvs) pp_lhs = hang pp_tc 2 (pprParendIfaceTcArgs pat_tys) maybe_incomps = ppUnless (null incomps) $ parens $ ptext (sLit "incompatible indices:") <+> ppr incomps }}} Notice that we're not using `pprUserIfaceForAll` anymore (which consults `-fprint-explicit-foralls`), but instead we're using `pprWithCommas`, which causes the strange list-like output that we see today. Richard, do you have a strong opinion on how closed type families should be rendered? My inclination would be to revert back to the old behavior, but maybe you had a reason for choosing this strategy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 17:56:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 17:56:27 -0000 Subject: [GHC] #13423: Exception to I/O hack in demand analyzer too broad In-Reply-To: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> References: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> Message-ID: <060.a12801ef23d5a3817038615d67b16764@haskell.org> #13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- 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 dfeuer): Replying to [comment:1 rwbarton]: > Is this really wrong in this case though? In a single-threaded context there is no observable difference between writing an `IORef` and then diverging, and diverging immediately; and in a multi-threaded context the ordering of `writeIORef` with respect to anything else is not guaranteed. That's not true. Someone could write {{{#!hs fish n ref next `catch` \(e :: E) -> readIORef ref >>= ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 17:58:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 17:58:36 -0000 Subject: [GHC] #13423: Exception to I/O hack in demand analyzer too broad In-Reply-To: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> References: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> Message-ID: <060.1454dc426c3bcdc3ee5d38fd53f47b7f@haskell.org> #13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- 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 dfeuer): Oh, if you mean diverging in the stronger sense of falling into a hole without throwing an exception, then that's true, but it's not the situation I was talking about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 18:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 18:03:35 -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.b0f6a71a952077c3f143712b32cf3d3d@haskell.org> #13420: Bizarre pretty-printing of closed type families in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I do remember that this change was intentional (that is, I'm not surprised by your report) but the reasons are cloudy. I'd be happy if the binders were printed only with `-fprint-explicit-foralls` and agree that doing so is an improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 18:33:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 18:33:02 -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.28c541857e347064d4fdedc0979778a0@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * cc: niteria (added) Comment: I've found myself unable to build GHC inside vagrant running on VirtualBox with 7GB of memory. It always gets killed by OOM killer when compiling DynFlags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 19:12:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 19:12:59 -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.c0a595f9b49f71e1522ce5bf082c7838@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: | 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 Ben Gamari ): In [changeset:"4b673e804fb8598dac02596f107544c7f2ea263b/ghc" 4b673e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b673e804fb8598dac02596f107544c7f2ea263b" Fix Windows GCC driver In Windows 10 Insiders build 15019+ which will probably be released mainstream somewhere this year Microsoft seems to have started being stricter with API calls. The call to `FreeConsole` just after `CreateProcess` is making Windows treat the process as an interactive process. In which case it tries to use the `Desktop session` but fails resulting in the cryptic error reported. I don't understand why the call to `FreeConsole` was there and it doesn't seem to be needed, so removed. This fixes #13411 Test Plan: ./validate, alternative just do anything with ghc which requires compilation. Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3319 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 19:12:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 19:12:59 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.286c847fcb4abce3311377a50fab0634@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e0c433c81182c934ee4c4cc5c6cf25a1b6fb8d83/ghc" e0c433c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0c433c81182c934ee4c4cc5c6cf25a1b6fb8d83" Fix #13337. The big change is the introduction of solveSomeEqualities. This is just like solveEqualities, but it doesn't fail if there are unsolved equalities when it's all done. Anything unsolved is re-emitted. This is appropriate if we are not kind-generalizing, so this new form is used when decideKindGeneralizationPlan says not to. We initially thought that any use of solveEqualities would be tied to kind generalization, but this isn't true. For example, we need to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which is really desugaring). These equalities are all surely going to be soluble (if they weren't the "kc" pass would fail), but we still need to solve them again. Perhaps if the "kc" pass produced type- checked output that is then desugared, solveEqualities really would be tied only to kind generalization. Updates haddock submodule. Test Plan: ./validate, typecheck/should_compile/T13337 Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3315 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 20:00:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 20:00:59 -0000 Subject: [GHC] #13427: Per-function code-generation options Message-ID: <046.e32a9e2b9054c8f1723204dd8169ab38@haskell.org> #13427: Per-function code-generation options -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- On ghc-devs Ed Kmett has [[https://mail.haskell.org/pipermail/ghc- devs/2017-March/013923.html|asked]] for some way to more precisely specify code generation options (e.g. should AVX be used?). This idea has taken a few different shapes in the thread, but I suspect that the most sensible approach is add something like a `TARGET` pragma, which the user could attach to a top-level binding. Since the interactions with inlining are non-trivial, I suspect you would want to require that this only be applied to `NOINLINE` bindings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 20:09:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 20:09:34 -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.68be95edcd1c9eef5e489fc19dcdc897@haskell.org> #13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Driver | Version: 8.0.2 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 20:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 20:16:43 -0000 Subject: [GHC] #13396: thread blocked when running `deepseq` with infinite list In-Reply-To: <044.37c4fdee2aa4b8d8b9bca5da0b79856f@haskell.org> References: <044.37c4fdee2aa4b8d8b9bca5da0b79856f@haskell.org> Message-ID: <059.a0353e043dcc3f3c160e378a0dd7a40a@haskell.org> #13396: thread blocked when running `deepseq` with infinite list -------------------------------+-------------------------------------- Reporter: Forec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: thread blocked Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #13359 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by Phyx-): * related: => #13359 Comment: Thanks for the report, there's a few things wrong with the interrupt handler unfortunately. We'll have to sort them out soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 20:19:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 20:19:53 -0000 Subject: [GHC] #13427: Per-function code-generation options In-Reply-To: <046.e32a9e2b9054c8f1723204dd8169ab38@haskell.org> References: <046.e32a9e2b9054c8f1723204dd8169ab38@haskell.org> Message-ID: <061.bad8655011bb9f175e505ca2e50e7728@haskell.org> #13427: Per-function code-generation options -------------------------------------+------------------------------------- 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 ekmett): Annoyingly, they probably _do_ need to be able to INLINE in order to be at all useful. Consider a situation where a user builds a module that all requires an "avx2" target to build, then carefully wraps any use of that module in a user-space ISA check. We really _want_ these things to inline out int the surrounding caller. With the goal being to have all of that heavy haskell code erase, and just individual assembly instructions remain. Ultimately, how far it'll inline becomes a function of the fact that e.g. With a TARGET pragma saying we'll use avx2, the fact that without avx2, __m256's being passed in ymm registers (which don't exist yet) isn't a thought we can think at all. Basically, the only source of data that needs avx2 and the registers it entails is something that had the flag on in the first place, and given these all wind up being opaque looking primops its not like we have rewrite rules that are going to commute these out of the ISA check. If we start changing our story about how we do all the vector primitives to support downgrading to an emulation layer, that all might change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 14 20:50:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Mar 2017 20:50:59 -0000 Subject: [GHC] #13423: Exception to I/O hack in demand analyzer too broad In-Reply-To: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> References: <045.9cb1af71e4d0ff8c6c171a3d400ac1aa@haskell.org> Message-ID: <060.ff0f20e90f7639654ca919addf8d1f6c@haskell.org> #13423: Exception to I/O hack in demand analyzer too broad -------------------------------------+------------------------------------- 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 dfeuer): In any case, you can just swap out `writeIORef` for any other genuinely side-effecting primop and get the same sort of result, so that's not really too relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 01:21:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 01:21:40 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.7d8cebe1cb031c69e035d228b877ee23@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Generics 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:D3337 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm missing something: why is this a real problem? Adding a bunch of logic to fix it seems like overkill to me, personally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 01:22:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 01:22:14 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.9a0b19398def8c270894a8b952a2bcf0@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Generics 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:D3337 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 04:38:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 04:38:42 -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.23a40dbe5e47a1fbdb501c9cac140346@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.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 erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 12:50:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 12:50:18 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.74ad835bba11342cf4e15a692d55c34a@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case ----------------------------+------------------------------ Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+------------------------------ Comment (by vanto): Hi, I just found this at this address https://github.com/commercialhaskell/stack/issues/1798\\ The issue is not the same but it's the same screenshot. Hope this help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 13:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 13:18:47 -0000 Subject: [GHC] #13381: "opt_univ fell into a hole" panic from rewrite rule In-Reply-To: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> References: <045.2175aa97999f817b2de6d3d2c2ae9752@haskell.org> Message-ID: <060.b5debe32c0845a354e08d9ffc99f1420@haskell.org> #13381: "opt_univ fell into a hole" panic from rewrite rule -------------------------------------+------------------------------------- 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: Compile-time | Test Case: crash or panic | typecheck/should_compile/T13381 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` as 98692134c3aee35dd89992aff3c350f49543a67b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 13:19:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 13:19:13 -0000 Subject: [GHC] #13398: Associated type family instance validity checking is too conservative In-Reply-To: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> References: <050.f51eb0cab5dc56d8662a7a18bb037859@haskell.org> Message-ID: <065.1c707083577e77a0a52b186e5429daed@haskell.org> #13398: Associated type family instance validity checking is too conservative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T13398a, | indexed- | types/should_compile/T13398b Blocked By: | Blocking: Related Tickets: #11450 | Differential Rev(s): Phab:D3302 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 82366c4c1501d57dd8490818ef6e0709aca8836f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 13:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 13:21:17 -0000 Subject: [GHC] #13267: Constraint synonym instances In-Reply-To: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> References: <045.f8ed117474c8000ae242eae97e053b65@haskell.org> Message-ID: <060.5cac8090b03bd47e5093b71200a4f78f@haskell.org> #13267: Constraint synonym instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | polykinds/T13267 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.2` as 3ab6684bdf4abf700cc9b43aaa3d42c38c8ae291. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 13:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 13:24:14 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.07649bad2584b83e2d6473452746fdbb@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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) => simonpj Comment: Simon has said he is on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 13:24:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 13:24:50 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.deb217114ead5391239a85a9945f0c2b@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: lukemauer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 15:04:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 15:04:17 -0000 Subject: [GHC] #13428: internal error: Can't allocate thunk for free Message-ID: <048.d8b6e18ea634f61e3597bc1216950109@haskell.org> #13428: internal error: Can't allocate thunk for free -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: RTS linker | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to compile `stack` with `ghc-8.0.2` resulted in this: {{{ [ 73 of 124] Compiling Stack.PackageIndex ( src\Stack\PackageIndex.hs, C:\Users\abiehl\git\stack\dist- newstyle\build\x86_64-windows\ghc-8.0.2\stack-1.4.1\build\Stack\PackageIndex.o ) ghc.exe: internal error: Can't allocate thunk for free (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. cabal.exe: Failed to build stack-1.4.1. The build process terminated with exit code 3 }}} The file in question uses `TemplateHaskell` and I suspect the runtime linker to be the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 15:11:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 15:11:45 -0000 Subject: [GHC] #13428: internal error: Can't allocate thunk for free In-Reply-To: <048.d8b6e18ea634f61e3597bc1216950109@haskell.org> References: <048.d8b6e18ea634f61e3597bc1216950109@haskell.org> Message-ID: <063.51c2b3b5d9f7c1897179b36b7f7db63e@haskell.org> #13428: internal error: Can't allocate thunk for free -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: RTS linker Operating System: Windows | 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 awson): This is fixed in HEAD and 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 15:17:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 15:17:59 -0000 Subject: [GHC] #13428: internal error: Can't allocate thunk for free In-Reply-To: <048.d8b6e18ea634f61e3597bc1216950109@haskell.org> References: <048.d8b6e18ea634f61e3597bc1216950109@haskell.org> Message-ID: <063.33e5d7b1d92eb9235fc60752521954b7@haskell.org> #13428: internal error: Can't allocate thunk for free -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: RTS linker Operating System: Windows | 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 alexbiehl): * status: new => closed * resolution: => invalid Comment: Awesome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 15:52:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 15:52:16 -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.e8cde21eb553d0de92c050ff31921ed2@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` in 018ac7f4b2f7345e28d21fb1f99b44dbc79f6e85. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 15:52:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 15:52:37 -0000 Subject: [GHC] #13401: GHCi gives conflicting information about visible type application In-Reply-To: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> References: <047.c80f174e97b78bd78fc70070e2a08a9e@haskell.org> Message-ID: <062.2b1a746cfd4c33e1cb203da08541368a@haskell.org> #13401: GHCi gives conflicting information about visible type application -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11376, #11975 | Differential Rev(s): Phab:3310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` in 7596efd6d253c28abc663e7fac2b01442832a89e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 15:54:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 15:54:05 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs In-Reply-To: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> References: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> Message-ID: <061.0bfa75cadb3f6544f5ba5dd0a7a8883c@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: GHC change merged to `ghc-8.2` in 2bd87cd498a6dc3b7c37362f8645b00ba5262410. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 16:15:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 16:15:49 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.b01c509070b984d0048760ba393cd33d@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case -----------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: new => upstream * component: GHCi => Compiler * architecture: x86 => Unknown/Multiple Comment: This seems to be an issue with how GCC was configured. It has a hardcoded path that happens to coincide with the path of your memory card[1][2]. Easiest way around this is to change the drive letter of the memory card to something else. [1]https://sourceforge.net/p/mingw/bugs/2108/ [2]https://superuser.com/questions/836250/there-is-no-disk-in-the-drive- please-insert-a-disk-into-drive-e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 18:39:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 18:39:31 -0000 Subject: [GHC] #12159: Record-like GADTs with repeated fields (of same type) rejected In-Reply-To: <048.5dd46a690e4224728f1b88e3135dbfce@haskell.org> References: <048.5dd46a690e4224728f1b88e3135dbfce@haskell.org> Message-ID: <063.d24c6b6e7782b5de4b164e940b16efcc@haskell.org> #12159: Record-like GADTs with repeated fields (of same type) rejected -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just ran into this (in the “simple” case where a field would appear in all constructors with the same field type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 19:25:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 19:25:35 -0000 Subject: [GHC] #13388: Caret diagnostics interact badly with hsc2hs In-Reply-To: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> References: <046.035aa429bafdc9e9f3b325b11852dd45@haskell.org> Message-ID: <061.85b40fe205ba0a3bc473ac47fb8e5db2@haskell.org> #13388: Caret diagnostics interact badly with hsc2hs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cec90709c9c8c2c2955f11b9ad29f4c99bd075db/ghc" cec90709/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cec90709c9c8c2c2955f11b9ad29f4c99bd075db" Bump hsc2hs submodule Fixes #13388. Also updates the expected output for T12504, which previously contained a redundant LINE pragma. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 19:37:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 19:37:33 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.c4f41a9ee5dd109e7dd7d803ed4c5f25@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case -----------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: upstream => closed * resolution: => fixed Comment: It seems that the `GCC` in `GHC 8.0.1` and `GHC 8.0.2` were built on a path `D:\develop`. This path ended up being hard coded into the binary and it's checked when compiling things. This results in the following access: [[Image(https://cloud.githubusercontent.com/assets/1177385/23966480/683f0300-09b3-11e7 -8c6e-e1003d53402d.png)]] Because of this, you guys with `D:\` mapped to a removable drive get the dialog. This is a bit out of our control. But it seems that the `GCC` that will be used for the upcoming `GHC 8.2` release uses `C:\building`. Since in 99% of the cases everyone has a fixed drive on `C:\` if it's available, then it should work. So for now, I can recommend a workaround of changing the removable storage from `D:\` to something else, or wait for `GHC 8.2.1`. This is about as fixed as it's going to get. We'll try to keep an eye out in the future for what the build directory is. But we don't build `GCC`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 15 19:38:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Mar 2017 19:38:00 -0000 Subject: [GHC] #13400: realgcc.exe do not run GHCi in Windows in a particular case In-Reply-To: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> References: <044.485e12d0c01546b7ded7bccdfedf3894@haskell.org> Message-ID: <059.15eea0db774ae175739b27057cab4f0b@haskell.org> #13400: realgcc.exe do not run GHCi in Windows in a particular case -----------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 02:58:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 02:58:58 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.c3295b36a7d59a011f091f9980021971@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: This seems resolved. GHC now allows no impredicative polymorphism, even for levity-polymorphic values. Closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 03:22:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 03:22:09 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.7c004aed91201a49a36001e87a2b188c@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: I can't reproduce any more. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 10:23:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 10:23:30 -0000 Subject: [GHC] #12159: Record-like GADTs with repeated fields (of same type) rejected In-Reply-To: <048.5dd46a690e4224728f1b88e3135dbfce@haskell.org> References: <048.5dd46a690e4224728f1b88e3135dbfce@haskell.org> Message-ID: <063.b424a6f79bc50be59754c13ae119bd52@haskell.org> #12159: Record-like GADTs with repeated fields (of same type) rejected -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It just needs someone to nail down the details, write a spec (preferably a GHC proposal), and the execute -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 10:31:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 10:31:43 -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.2c10de0649a459884ba1f44900f3ff13@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 gueux): * cc: gueux (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 12:14:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 12:14:07 -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.d45db6abd0a84edb007205a72d07af82@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 awson): Clang driver is not particularly good on Windows. I believe using clang will buy us very little (if anything), and would, perhaps, make things even worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 12:34:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 12:34:44 -0000 Subject: [GHC] #13429: Optimizer produces Core with an infinite <> Message-ID: <045.cf5ba15167896826f7f0c0a59d69b609@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | 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: -------------------------------------+------------------------------------- While using vector package to implement convolution and supplying `-O1` or `-02` to ghc compilation results in core with an infinite loop. In order to trigger this behavior at least two modules is required. Attached is the minimal setup that I could come up with, that demonstrates the issue. Here is the stack trace: {{{ $ stack --install-ghc --resolver lts-8.3 exec -- ghc -O1 -prof -fprof-auto main.hs && ./main +RTS -xc [1 of 2] Compiling Loop ( Loop.hs, Loop.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.CAF --> evaluated by: Main.main, called from Main.CAF --> evaluated by: Loop.toKernel.\, called from Data.Vector.Fusion.Util.>>=, called from Loop.toKernel, called from Main.main, called from Main.CAF --> evaluated by: Data.Vector.Fusion.Util.>>=, called from Loop.toKernel, called from Main.main, called from Main.CAF *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Main.CAF main: <> }}} At first I though that it might be a bug in a vector package, which is still a possibility, but since I was not able to observe that issue with ghc-7.8.4, I decided to open an ticket here. I tested attached code with all of subsequent released ghc versions (7.10.1 - 8.0.2), which resulted in the infinite loop. Worth noting that sometimes, when recompilation of only the `main.hs` file is enforced, program starts to work as expected. Here is an example: {{{ $ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main [1 of 2] Compiling Loop ( Loop.hs, Loop.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... main: <> $ touch main.hs $ stack --resolver ghc-7.10.3 exec --package vector-0.11.0.0 --package primitive-0.6.1.0 -- ghc -O1 main.hs && ./main [2 of 2] Compiling Main ( main.hs, main.o ) Linking main ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 12:38:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 12:38:41 -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.529e0b2e97d158506c3882598c3cf258@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lehins): * Attachment "Loop.hs" added. Minimal implementation that triggers the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 12:40:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 12:40:41 -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.8a585481af9fdce1775c54b67260f70c@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lehins): * Attachment "main.hs" added. correlation has to be invoked from a separate module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 12:48:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 12:48:17 -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.c11dccd81ffbf798ba640c2d1acc24ce@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lehins): * Attachment "RUNS.md" added. Various versions that compilation was attempted with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 12:58:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 12:58:47 -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.6d3edb438d8a2a0a4a934a38b47c1706@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 angerman): Replying to [comment:16 awson]: > Clang driver is not particularly good on Windows. > > I believe using clang will buy us very little (if anything), and would, perhaps, make things even worse. What you are saying is that `clang` is worse than `opt` and `llc` on windows? I should really get myself some windows box somewhere :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 13:45:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 13:45:36 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.6f9ae735737f53aeaeb09fe730d59199@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles 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: > I first noticed something was a bit odd with `Constraint` when chasing > #11334. Consider this testcase (`-O0` is sufficient), > {{{#!hs > import Data.Typeable > > main = do > print $ typeRep (Proxy :: Proxy Eq) > print $ typeOf (Proxy :: Proxy Eq) > }}} > With `ghc-8.0` this will produce, > {{{ > Eq > Proxy (* -> *) Eq > }}} > Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, > which is clearly nonsense. > > I believe this issue may be the cause of some of the testsuite failures > that I'm seeing on #11011. Unfortunately I haven't the foggiest where > this issue might originate. > > See also > * #11621 > * #12933 New description: I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase (`-O0` is sufficient), {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. See also * #11621 * #12933 * #9547 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 13:59:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 13:59:56 -0000 Subject: [GHC] #13430: Can't scope type variables when pattern matching on GADTs Message-ID: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> #13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- I was very surprised that the following doesn't compile: {{{ {-# LANGUAGE GADTs, ScopedTypeVariables #-} data Foo x where A :: Foo Bool B :: Foo Int foo :: Foo x -> () foo (A :: Foo Bool) = () }}} GHC says that it couldn't match the type `y` with `Bool`. See [this question](http://stackoverflow.com/questions/42824949/type-inference-with- gadts) for a simple motivating example. As someone there pointed out, the situation would be improved with type application (#11350), but this ticket is about bringing the output type in scope with `ScopedTypeVariables`. This most closely reminds me of #1823 (!), but that was resolved many moons ago. This behavior also exists in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 14:05:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 14:05:06 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows Message-ID: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHC rejects | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- That's a somewhat confusing title, so let me explain in more detail what I mean. I first noticed this issue when someone [https://github.com/idris-lang /Idris-dev/pull/3684 couldn't build Idris] on 32-bit Windows (using GHC 7.8, 7.10, or 8.0). Trying to link the Idris executable resulted in this cryptic linker error: {{{ Preprocessing executable 'idris' for idris-0.99.1... [1 of 1] Compiling Main ( main\Main.hs, dist\build\idris \idris-tmp\Main.o ) Linking dist\build\idris\idris.exe ... C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(dohds01059.o):(.idata$5+0x0): multiple definition of `_imp__atan' C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libntdll.a(dgjjs01967.o):(.idata$5+0x0): first defined here collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} The culprit was apparently Idris's dependency on the `mintty` package. The important bit was that `mintty` lists `ntdll` as in the `extra-libraries` stanza of its `.cabal` file. As it turns out, you can also reproduce this with a more recent version of `Win32`, which also depends on `ntdll`. First, run these steps: {{{ $ cabal get Win32 $ cd Win32-2.5.2.0/ $ cabal sandbox init $ cabal install . -w $(pwd)/../../../../Software/ghc-8.0.1-x86/bin/ghc }}} This will install the recent `Win32-2.5.2.0` in a sandbox (NB: I'm using 32-bit Windows GHC 8.0.1 here). Now create this file (which I named `Bug.hs`): {{{ module Main (main) where main :: IO () main = print (atan 0.5 :: Double) }}} And you can reproduce the linker error like so: {{{ $ ../../../../Software/ghc-8.0.1-x86/bin/ghc Bug.hs -package-db .cabal- sandbox/i386-windows-ghc-8.0.1-packages.conf.d/ -package Win32 -fforce- recomp [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.exe ... C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(dohds01059.o):(.idata$5+0x0): multiple definition of `_imp__atan' C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libntdll.a(dgjjs01967.o):(.idata$5+0x0): first defined here collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} It's important to use 32-bit Windows GHC here, since I am unable to reproduce this with 64-bit Windows GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 14:21:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 14:21:12 -0000 Subject: [GHC] #13430: Can't scope type variables when pattern matching on GADTs In-Reply-To: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> References: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> Message-ID: <062.4dc44e9f825728d5b56bd40f912a56b8@haskell.org> #13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks absolutely right to me. `foo`'s argument type is `Foo x` not `Foo Bool`. Only ''after'' matching A do we get `Foo Bool`. But the type signature is matched before we get to the A part. Better to consider something more like the original question: {{{ data Bar x where MkBar :: Typeable b => a -> Bar (a,b) bar :: Bar x -> string bar (MkBar @a @b _) = show (typeRep (Proxy :: Proxy b)) }}} Here you want to use mention the type variable `b`. But there is no way to bring it into scope since we don't have visible type applications in patterns (yet #11350). I think that's really the right solution too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 14:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 14:22:00 -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.25746c1666fab665b6a6f5a6812a72e9@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 simonpj): #13430 points to a case from Stack Overflow where this was needed in the wild. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 14:28:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 14:28:13 -0000 Subject: [GHC] #13430: Can't scope type variables when pattern matching on GADTs In-Reply-To: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> References: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> Message-ID: <062.47529b1574f414598a503b7d6597967f@haskell.org> #13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): BTW here is a workaround: {{{ bar :: Bar x -> String bar x@(MkBar _) = case x of (x :: Bar (a, b)) -> show (typeRep (Proxy :: Proxy b)) }}} Here, ''inside'' the pattern match for `MkBar` we make a new pattern-match on `x`, and give it a scoped type signature. Not beautiful but it works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 14:29:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 14:29:04 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.ab9ffdf77171b97f0c945c832017bccc@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The issue stems from the order in which `ntdll` and `msvcrt` are given to the linker when compiling the executable. If you compile with `-v3`, you'll discover this linker invocation: {{{ "gcc.exe" ... "-lntdll" ... "-lmsvcrt" ... }}} If you swap the order in which `msvcrt` and `ntdll` are linked: {{{ "gcc.exe" ... "-lmsvcrt" ... "-lntdll" ... }}} Then it works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 14:43:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 14:43:38 -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.b5c4078bad3b048faf8a42eeb3bfb8fe@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 awson): Well, perhaps I was not quite correct. I mostly had in mind things like (for example) `clang` on Windows doesn't supporting `-flto`, but using separate utilities, e.g doing `llvm-link` between `opt` and `llc` we can accomplish the thing. OTOH, we still can call `clang` twice, first instead of `opt` then instead of `llc` with `llvm-link` in-between. Still I'm very much not sure we need to bother with the beast like `clang` to only be able to get rid of literally a couple of lines of haskell code. Moreover, I'm not sure OS X -O3 example is quite relevant here. Do you mean using `-O3` with `opt` and/or `llc` driver yields different results from if we use the same `-O3` with `clang` driver on the same version of llvm/clang? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 15:07:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 15:07:52 -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.754c0e655a304fa0e26c912505505a5d@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): Can you describe how I can reproduce this? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 15:17:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 15:17:32 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.15a27f18ee98a24885e74f72385654bf@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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 Lemming): `storablevector:Data.StorableVector.ST.Strict` has the same problem. http://hackage.haskell.org/package/storablevector-0.2.11/docs/Data- StorableVector-ST-Strict.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 15:25:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 15:25:09 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.515c86fc415071c11ea4070b0adc8635@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Instead of their fully spelled-out, more laborious counterparts. This would be crucial for Template Haskell, as its ability to infer these contexts is quite limited (see #10607 for an example where this cropped up). It seems like for this to be useful we will want the ability to more precisely apply `PartialTypeSignatures` (in particular from splices) to ensure that users are forced to enable it for their entire module to avoid spurious errors. Is there a ticket for this yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 15:42:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 15:42:13 -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.72845f8649b0c5b15041db3bcf50f6d3@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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: new => merge * milestone: => 7.10.4 Comment: This appears to be fixed in 8.2 with `vector-0.12.0.0`. Unfortunately, it's quite unclear what fixed it and working this our will likely be a significant investment of effort. Given that there is unlikely to be an 8.0.3, I think it's pretty unlikely that we will fix this in the 8.0 series but I'm marking this as `merge` regardless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 15:55:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 15:55:03 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.61bfa354cb1351b85497b9320fe7597e@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): As a person that suffers a lot from this -- what can be done? What is the "next" step? How much competence is required to debug this? How can a relatively clueless person (like me) help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 15:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 15:59:27 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.87d6f49f135c4c37add1058a5ad7756e@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): bgamari, yes, I believe #8510 is what you are looking for. I don't think that implementing this feature would be that difficult, either, since: 1. We already have a `Extension` datatype for representing all GHC extensions 2. The GHC API already has `setXOptM`/`unsetXOptM` for enabling/disabling `Extensions` within the scope of some computation So I think we'd just need a Template Haskell function `qWithExtensions :: Quasi m => [OnOff Extension] -> m a -> m a` that enabled/disables whatever the user provides. Then libraries like `deriveTopDown` could just use `qWithExtensions [On PartialTypeSignatures]` to wrap any splices that contain wildcard types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 16:14:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 16:14:05 -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.ef08ef26b2556c80d6cc93e94ff40f9d@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "ghc-8.0.svg" added. Building DynFlags with GHC 8.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 16:14:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 16:14:19 -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.06ae2299e18eb44fb0645562acf6048e@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "ghc-8.2.svg" added. Building DynFlags with GHC 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 16:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 16:18: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.2cda21a745219ed92b93aba57882f6c6@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed something catastrophic is happening here; this can be plainly seen in the `+RTS -h` profiles I attached above. These were produced by building two GHC trees, one bootstrapping with 8.2 and another with 8.0.2, taking the `DynFlags` command line from the stage1 build, and adding `-fforce-recomp -v +RTS -h >log 2>&1` to it. Clearly we have a significant amount of leakage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 16:19:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 16:19:44 -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.bbebfb59a04d0d5836d53db3cd859f57@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "ghc-8.0.log" added. Log output from GHC 8.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 16:19:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 16:19:59 -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.a331beaafbad594edbf39d5cae40591d@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "ghc-8.2.log" added. Log output from GHC 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:20:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:20:24 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.169588037960afa293bd54dabc3d23de@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd like to see whether #13324 can really fly first, and do this change as part of it. If #13324 doesn't fly, this change is just an unnecessary complication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:23:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:23:46 -0000 Subject: [GHC] #13432: ghc: panic! (the 'impossible' happened) Message-ID: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> #13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | 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: -------------------------------------+------------------------------------- **Command** {{{ ghc -c prettystub.hs }}} **Result** {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] hexEscape_a2yj :: t_a2yi[tau:1] (CHoleCan: hexEscape)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:23:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:23:56 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.c11c4b2025acb1e98a20e17972e46e5b@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Do you also, as #13415 implies, want the non-`deriving` case to work? {{{ instance _ => C (T a) where op x = ... bop y = ... }}} This would be more ambitious, because you'd have to infer the constraints for the arbitrary user-written code in "...", and `TcInstDcls` isn't set up to do that. Remember that two instance declarations might both need each other. That's why there's a fixpoint in the deriving code. I think it'd be a lot easier to handle the deriving case than the general case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:24:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:24:45 -0000 Subject: [GHC] #13432: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> References: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> Message-ID: <061.65a32a589d2f2e0e0b8432177499deb5@haskell.org> #13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | 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 brikken): * Attachment "PrettyJSON.hs" added. source file to be compiled -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:25:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:25:27 -0000 Subject: [GHC] #13432: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> References: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> Message-ID: <061.ca26a5dc680651a3f3869f186ad1ff15@haskell.org> #13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | 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 brikken): * Attachment "PrettyStub.hs" added. required module #1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:25:31 -0000 Subject: [GHC] #13432: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> References: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> Message-ID: <061.fc260ee5075baaa1dce6b8116d8e0b9b@haskell.org> #13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps a dup of #13416? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 17:25:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 17:25:45 -0000 Subject: [GHC] #13432: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> References: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> Message-ID: <061.70f8d6ec95d764cdebcac713db378374@haskell.org> #13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | 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 brikken): * Attachment "SimpleJSON.hs" added. required module #2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 18:09:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 18:09:27 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.500f012f38cd30b433167dd599eadf22@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 simonpj]: > If #13324 doesn't fly, this change is just an unnecessary complication. I don't agree. This ticket demonstrates a somewhat orthogonal bug: the error messages for using named wildcards in instance declarations are wildly misleading! We should be able to fix this, even if it takes longer to make `PartialTypeSignatures` work for arbitrary instances with wildcards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 18:12:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 18:12:17 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.9609ac96cf3f0bc7e3508ee759ec0775@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 simonpj]: > Do you also, as #13415 implies, want the non-`deriving` case to work? Indeed, I think that if I can figure out how to make it work for `deriving`, I don't think inferring constraints for arbitrary instances would be that fundamentally different in operation. Granted, I don't think I'm going to knock out both at the same time. Baby steps and all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 18:15:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 18:15:38 -0000 Subject: [GHC] #13432: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> References: <046.8e689cc31fd3cd96f6716c45e209f79f@haskell.org> Message-ID: <061.1f961681baa75e12fa0db89ac3a71f53@haskell.org> #13432: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: brikken | 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: #13416 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13416 Comment: Replying to [comment:1 simonpj]: > Perhaps a dup of #13416? Yep. You'll get a better error message in GHC 8.2: {{{ [1 of 3] Compiling SimpleJSON ( SimpleJSON.hs, interpreted ) [2 of 3] Compiling PrettyStub ( PrettyStub.hs, interpreted ) [3 of 3] Compiling Main ( PrettyJSON.hs, interpreted ) PrettyJSON.hs:23:36: error: Variable not in scope: hexEscape :: Char -> Doc | 23 | Nothing | mustEscape c -> hexEscape c | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 19:16:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 19:16:45 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way Message-ID: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that profiling has regressed sometime between GHC 8.0 and 8.2. A few times since September I have noticed that profiled programs (in particular, GHC itself built with profiling enabled) seem to segmentation fault. This most recent case was produced by building commit 6ebfbdfb64cb8bb5c2ddaf2ad3ad350755c5eb2b with the following in `build.mk`, {{{ BuildFlavour = prof define add_mods_flag = $(foreach mod,$(2),$(eval $(basename $(mod))_HC_OPTS += $(1))) endef $(call add_mods_flag,-fprof-auto,$(wildcard compiler/typecheck/*.hs)) STRIP_CMD = : }}} and using the resulting stage2 compiler to bootstrap the same commit. Eventually the build will fail with a segmentation fault. Unfortunately it seems the crash isn't entirely reproducible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 19:20:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 19:20:10 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.7f0effdee49a8cd3c2751e388c904e90@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 19:24:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 19:24:38 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.dd200dd828a3645808c6510ce74a280b@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Looking through history since 8.0, #5654 seems relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 19:31:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 19:31:55 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.870def77fbcd2537f6707104c69e0a4a@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): mpickering has reported this as #13387. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 19:34:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 19:34:11 -0000 Subject: [GHC] #13387: Segfault when profiling on OS X In-Reply-To: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> References: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> Message-ID: <064.e63f6c1252dfe9c7183e5566e71df16e@haskell.org> #13387: Segfault when profiling on OS X -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: 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 have opened #13433 which addresses the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 19:36:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 19:36:54 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.0cf09efc805b116800f436aa75078f4b@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is some gdb output from a crash, {{{ $ ~/ghc-utils/debug-ghc ~/ghc/roots/8.2-profiled/bin/ghc -v -O2 Main.hs -fforce-recomp +RTS -p gdb --args /home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315/bin/ghc -B/home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315 -v -O2 Main.hs -fforce-recomp +RTS -p GNU gdb (Debian 7.12-4) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315/bin/ghc...run done. (gdb) run Starting program: /mnt/work/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315/bin/ghc -B/home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315 -v -O2 Main.hs -fforce-recomp +RTS -p [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff6853700 (LWP 19991)] [New Thread 0x7ffff6052700 (LWP 19992)] [New Thread 0x7ffff5851700 (LWP 19993)] [New Thread 0x7ffff5050700 (LWP 19994)] Glasgow Haskell Compiler, Version 8.2.0.20170315, stage 2 booted by GHC version 8.0.2 Using binary package database: /home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315/package.conf.d/package.cache There is no package.cache in /home/ben/.ghc/x86_64-linux-8.2.0.20170315/package.conf.d, checking if the database is empty There are no .conf files in /home/ben/.ghc/x86_64-linux-8.2.0.20170315/package.conf.d, treating package database as empty package flags [] loading package database /home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315/package.conf.d loading package database /home/ben/.ghc/x86_64-linux-8.2.0.20170315/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.0.20170315 wired-in package dph-seq not found. wired-in package dph-par not found. package flags [] loading package database /home/ben/ghc/roots/8.2-profiled/lib/ghc-8.2.0.20170315/package.conf.d loading package database /home/ben/.ghc/x86_64-linux-8.2.0.20170315/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.0.20170315 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Main.hs !!! Chasing dependencies: finished in 0.94 milliseconds, allocated 0.503 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-03-07 08:43:42 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Main.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( Main.hs, Main.o ) *** Parser [Main]: !!! Parser [Main]: finished in 73.04 milliseconds, allocated 54.502 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 572.66 milliseconds, allocated 398.957 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 11,856, types: 8,892, coercions: 0, joins: 0/0} !!! Desugar [Main]: finished in 178.87 milliseconds, allocated 132.900 megabytes *** Simplifier [Main]: Thread 1 "ghc" received signal SIGSEGV, Segmentation fault. 0x00000000000002e1 in ?? () (gdb) bt #0 0x00000000000002e1 in ?? () #1 0x0000000000000000 in ?? () (gdb) info reg rax 0x64a8ec0 105549504 rbx 0x64a8ec0 105549504 rcx 0x64a8ec0 105549504 rdx 0x420acd6000 283649073152 rsi 0x420acd6fff 283649077247 rdi 0x54c96c8 88905416 rbp 0x420b84fbc0 0x420b84fbc0 rsp 0x7fffffff9fc8 0x7fffffff9fc8 r8 0x1 1 r9 0x420b84fc40 283661106240 r10 0x8 8 r11 0x420b84ffd0 283661107152 r12 0x420acd5ff8 283649073144 r13 0x64b0718 105580312 r14 0x64ad160 105566560 r15 0x420b8480d0 283661074640 rip 0x2e1 0x2e1 eflags 0x10207 [ CF PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/32a 0x420b84fbc0 0x420b84fbc0: 0x54cb638 0x64a8ec0 0x420b84fbd0: 0x54c98d8 0x42018bde00 0x420b84fbe0: 0x0 0x6245070 0x420b84fbf0: 0x54d2590 0x42018bde00 0x420b84fc00: 0x54c99c0 0x42018bde00 0x420b84fc10: 0x0 0x42095d8000 0x420b84fc20: 0x54d2590 0x42018bde00 0x420b84fc30: 0x54c99c0 0x42018bde00 0x420b84fc40: 0x0 0x42095d8020 0x420b84fc50: 0x54d2590 0x42018bde00 0x420b84fc60: 0x54c99c0 0x42018bde00 0x420b84fc70: 0x0 0x42095d8040 0x420b84fc80: 0x54d2590 0x42018bde00 0x420b84fc90: 0x54c99c0 0x42018bde00 0x420b84fca0: 0x0 0x42095d8060 0x420b84fcb0: 0x54d2590 0x42018bde00 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 22:39:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 22:39:42 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.0f9017d2f4f4755d79b979e58fdb5e75@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What would you like it to say? You get the exact same message from {{{ instance x => Show (Maybe a) }}} namely {{{ Foo.hs:4:10: error: * Illegal constraint: x (Use ConstraintKinds to permit this) * In the context: x While checking an instance declaration In the instance declaration for `Show (Maybe a)' | 4 | instance x => Show (Maybe a) | ^^^^^^^^^^^^^^^^^^^ }}} In any case, making instance declarations have `LHsSIgWcType` sounds as if instnace are ''allowed''' to have wildcards, but they aren't, so that feels like the wrong solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 22:44:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 22:44:53 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.5e6ab0db035e466dba56035d77d22542@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 simonpj]: > What would you like it to say? You get the exact same message from > {{{ > instance x => Show (Maybe a) > }}} That isn't using a named wildcard, so I would expect that to give an error message involving `ConstraintKinds`. I wouldn't expect it from a named wildcard `_x`, however. > In any case, making instance declarations have `LHsSIgWcType` sounds as if instnace are ''allowed''' to have wildcards, but they aren't, so that feels like the wrong solution. It's true that instance heads aren't allowed to have wildcards. But then again, there are many other types in which wildcards are allowed to appear syntactically (e.g., `data Foo _`) but are later rejected, so we're not breaking convention by doing this. Besides, I don't see any simpler solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 23:18:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 23:18:55 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.49b867f8da1943faa37e82cf7e16f403@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I still don't know what you are trying to achieve. The error message looks spot on to me, and is the same whether you write `x`, `x_`, `_x` or `xx`, just as it is in any other type that does not admit wildcards. What error message do you actually want? What about the other uses of `LHsSigType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 16 23:24:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Mar 2017 23:24:44 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.0d3116ca23303f4950a18dd594e1280e@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The point that I'm trying to make is that we're gradually transitioning instance declarations over to recognizing wildcard types, so this is a necessary first step to take in that direction. Having recognized this, we need to `Wc`-ify the `LHsSigType`s used in instance declaration AST types. Having done so, we will get the //immediate// benefit of having better error messages when named wildcards are used, and we will get the knock-on benefit of making it easier for named wildcard to be properly integrated later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 01:27:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 01:27:46 -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.8fd4414b12e9350d7f0db0e84d14d04d@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 angerman): Replying to [comment:18 awson]: > Well, perhaps I was not quite correct. > > I mostly had in mind things like (for example) `clang` on Windows doesn't supporting `-flto`, but using separate utilities, e.g doing `llvm- link` between `opt` and `llc` we can accomplish the thing. > > OTOH, we still can call `clang` twice, first instead of `opt` then instead of `llc` with `llvm-link` in-between. > > Still I'm very much not sure we need to bother with the beast like `clang` to only be able to get rid of literally a couple of lines of haskell code. Moreover, I'm not sure OS X -O3 example is quite relevant here. Do you mean using `-O3` with `opt` and/or `llc` driver yields different results from if we use the same `-O3` with `clang` driver on the same version of llvm/clang? The actual diff is here: https://phabricator.haskell.org/D3352, which you might or might now have seen. Maybe the `-flto` on windows has changed with llvm4 already? We could I guess, do two clang runs, my intention though is to replace `ghc -> llvm ir -> opt -> llc -> mangler -> as -> object` to `ghc -> llvm ir -> clang -> object`. The mentioned macOS `-O3` bug, referred to the following lines, which sadly do not say which llvm version exhibited the issue. {{{ -- Bug in LLVM at O3 on OSX. llvmOpts = if platformOS (targetPlatform dflags) == OSDarwin then ["-O1", "-O2", "-O2"] else ["-O1", "-O2", "-O3"] }}} I'm proposing to take this opportunity and start from a blank slate and drop any **maybe it's still broken, maybe not** parts from the pipeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 01:34:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 01:34:52 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.8cea0f5eab363691d59cb10a3935fe15@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: 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): In cleaning up `tcView`/`coreView` to handle the disparity between the type-checker and Core vis-a-vis `Constraint`/`Type`, I came across a problem: which function (`coreView` or `tcView`) to use in the pure unifier? I decided that `coreView` was necessary there, because the pure unifier is used for instance overlap detection, where a `Constraint`/`Type` confusion could cause type unsoundness. But then `polykinds/T11480b` failed. A simplification of the problem is this: We have a class `C :: forall k. (Type -> k) -> Constraint`. The solver goes looking for an instance `C Constraint Eq`. (This instance is well-kinded.) But it finds an instance `C Type Eq`. As far as Core is concerned, this found instance is also well-typed... but the solver then looks at `C Type Eq` and falls over because the instance looks ill-kinded to it. One solution to this is to have the caller of any entry point into the pure unifier choose which notion of equality (i.e. `tcView`'s version or `coreView`'s version) it wants. But it's unclear what the right choices are. Here are the competing concerns: 1. We absolutely cannot have `type instance F Type = Int` and `type instance F Constraint = Bool`. That's begging for someone to write `unsafeCoerce`. 2. We also don't want the solver to find the instance for `C Type` when it goes looking for `C Constraint`, as that's very confusing to a solver that thinks `Type` and `Constraint` are different. 3. It would sure be nice to have both `Typeable Constraint` and `Typeable Type` be solvable. The only way I can think of resolving this is: - Forbid '''type''' instances that overlap w.r.t. `coreView`'s equality. - Allow '''class''' instances that overlap w.r.t. `coreView`'s equality. (After all, overlapping class instances can't cause unsoundness. - Use `tcView` when doing instance matching (for any instance flavor). This satisfies goals (1), (2), and (3). But it seems very squirrelly indeed to have different overlap checks for type instances and class instances. The only other alternative is to forbid `coreView` overlap for all instances and say that `Typeable Constraint` is insoluble, drastically reducing the set of `Typeable` things. I would love some thoughts from the crowd on this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 02:20:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 02:20:28 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.49c4ba00ac3acc3c299c6c5ff4f3bd1d@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): A bisection suggests that 2effe18ab51d66474724d38b20e49cc1b8738f60, the Early Inline patch, is the culprit here. Next I'm going to try two things, * another profiled build of `ghc-8.2` with full linting * a profiled build of `ghc-8.2` with 2effe18ab51d66474724d38b20e49cc1b8738f60 reverted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 08:05:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 08:05:10 -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.0f37342ea12983ca75a871e79d5a951a@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 awson): Ah, it looks so much happened under the hood which I wasn't aware of! A couple of comments and answers then: 1. `-flto` doesn't work on windows even on the current llvm5 and won't in the foreseeable future, because it requires GOLD linker plugin to work on unices, and we have neither on windows. 2. AFAIUI, Matthias Braun's early advice to use `clang` driver was mostly inspired by his ignorance of how different STG execution model is from that of C, later he understood this and stated that since we need `-fllvm` anyway, i.e. need to bypass `clang`'s "high-level" predefined `-OX` sets of options then either using `clang` or `opt/llc` drivers is "equally good/bad" in our use case. 3. Btw, why can't we simply do `ghc -> llvm ir -> clang -> mangler -> as -> object` if we still need the mangler? Or we can but *don't want*? 4. Even if not using `clang`, a part of your patches in [https://phabricator.haskell.org/D3352] still looks relevant, e.g. we can drop `pprLlvmHeader/moduleLayout` thingy since it is inferred by LLVM tools from module target triple anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 08:12:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 08:12:49 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.b0cd51315e46fa25796ad5be107144f0@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is really strange! Inlining doesn't affect semantics, and anything that passes Lint should not seg-fault. So it may have tickled the bug but it seems hard to believe that it's the cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 08:27:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 08:27:36 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting Message-ID: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is basically reproduceable every time I validate. During validation, the program times out, but when I run it by hand, it segfaults. Running in debug sanity mode, I get: {{{ hstry: internal error: MVAR_CLEAN on mutable list (GHC version 8.3.20170316 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Simon Marlow, I'm happy to investigate more if you can't repro. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 08:53:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 08:53:12 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.875c0a1f40b60cb6bb460949fd0dbf48@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is deeply strange. I have established * It happens with HEAD. * The combination of `-ffull-laziness` and `-fspec-constr` makes it produce the wrong answer `[1]`. Omitting either makes it give the right answer `[1,128,129,255]`. * Here are my command lines. I switched off everything I could. Failure case: {{{ simonpj at cam-05-unx:~/tmp$ ~/5builds/HEAD-5/inplace/bin/ghc-stage1 -dcore- lint -O2 -o T13425 T13425.hs -fforce-recomp -fno-enable-rewrite-rules -fno-liberate-case -fno-strictness -fno-cse -fno-call-arity -fno- specialise -fno-float-in -fno-late-dmd-anal [1 of 1] Compiling Main ( T13425.hs, T13425.o ) Linking T13425 ... simonpj at cam-05-unx:~/tmp$ ./T13425 [1] }}} Switch off full laziness (works) {{{ simonpj at cam-05-unx:~/tmp$ ~/5builds/HEAD-5/inplace/bin/ghc-stage1 -dcore- lint -O -o T13425 T13425.hs -fforce-recomp -fno-enable-rewrite-rules -fno- liberate-case -fno-strictness -fno-cse -fno-call-arity -fno-specialise -fno-float-in -fno-late-dmd-anal -fno-full-laziness [1 of 1] Compiling Main ( T13425.hs, T13425.o ) Linking T13425 ... simonpj at cam-05-unx:~/tmp$ ./T13425 [1,128,129,255] }}} Switch off spec-constr (works) {{{ simonpj at cam-05-unx:~/tmp$ ~/5builds/HEAD-5/inplace/bin/ghc-stage1 -dcore- lint -O -o T13425 T13425.hs -fforce-recomp -fno-enable-rewrite-rules -fno- liberate-case -fno-strictness -fno-cse -fno-call-arity -fno-specialise -fno-float-in -fno-late-dmd-anal -fno-spec-constr [1 of 1] Compiling Main ( T13425.hs, T13425.o ) Linking T13425 ... simonpj at cam-05-unx:~/tmp$ ./T13425 [1,128,129,255] }}} I'm out the rest of today. This is a bad bug; might someone look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:42:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:42:59 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class Message-ID: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- 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 FlexibleInstances, TypeFamilies, TypeInType, MagicHash #-} import Data.Kind import GHC.Exts class Shw (a :: TYPE rep) where shw :: a -> String instance Int# ~ a => Shw (a :: TYPE IntRep) where shw a = "I#" ++ show (I# a) main = putStrLn (shw 3#) }}} induces a segfault {{{ $ runghc --version runghc 8.0.1 $ runghc test.hs I#Segmentation fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:43:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:43:26 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.50e9b304e7060deb43165226dfe56312@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:47:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:47:52 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.3f8fef57b8a30db17df0ebe58129dd8d@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'll take a peek today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:48:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:48:40 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.b0bd43b1128dad1022a47c0c645dc40b@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | 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: Incorrect result | Unknown/Multiple at runtime | 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 Fri Mar 17 09:50:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:50:13 -0000 Subject: [GHC] #13436: feature for checking files in temp location Message-ID: <045.68d2a645f1b97a24d8113555ea7c6b4f@haskell.org> #13436: feature for checking files in temp location -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: ghc-pkg | 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: -------------------------------------+------------------------------------- ghc-pkg register can do sanity checks on files being in the right place. These are a useful sanity check. The checks can also be disabled with the `--force-files` flag. When installing package files and registering we can either install files and then register or the reverse. The reverse style can be helpful in simplifying the locking system that allows concurrent package installation and use. In particular, new versions of cabal will 1. prepare all package files in a temporary directory; 2. register with ghc-pkg; and 3. use an atomic directory rename to move the package files to their final location This procedure simplifies the locking considerably by not requiring any locks between concurrent package readers and writers, just requiring locks between concurrent writers. Step 2 above requires that we be able to register when the files are not yet in their final location. This can be done with the `--force-files` flag, but we lose out on the useful sanity checks. So this feature request is for a flag that lets us say "do please do the file checks, but instead of looking for files in their final locations, look for them here". Since file paths in the package registration info are usually absolute paths, then the specification of where to look for files would need to be done in terms of changing a prefix. For example, a registration file may contain: {{{ import-dirs: /home/me/.cabal/store/uniplate-1.6.12-3K1HlYoxKOQ3XlQlOoSFWj }}} And this is used to check for the .hi files for all the modules. But in the above scenario the files will actually all be in /home/me/.cabal/store/**incoming**/uniplate-1.6.12-3K1HlYoxKOQ3XlQlOoSFWj so we will want to say something like: {{{ ghc-pkg register uniplate.conf \ --file-root=/home/me/.cabal/store/=/home/me/.cabal/store/incoming/ }}} or another example of a slightly different use case would be {{{ ghc-pkg register uniplate.conf \ --file-root=/=$PWD/image/ }}} this is for the case of `--prefix=/usr/local` and `make install DESTDIR=$PWD/image` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:54:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:54:06 -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.838bc8e5f09f550145403f0949e1ddfb@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 angerman): - if lto depends on gold, than this will clearly only work on ELF based systems, I'm not just if lld would solve this though, it's supposed to be somewhat stable already. - I don't see the STG/C difference in the emails. I might be not reading something right though. Yes if we want exact control over opt and llc, which we can't get through clang, we will need to revert back to those tools. I however would prefer not to. That `clang` or `opt/llc` are equally suboptimal is certainly correct. I would argue that one tool is preferable over two tools, unless we find actual usecases we can't achieve with that single tool (and can not subsequently convince the llvm people that our usecase is legit.). - Yes, we could ask clang to output assembly, (or bitcode if we wanted to use llvms bitcode linkter), and use clang as the assembler as well. I simply want to get rid of the mangler if possible (see also #11138); right now we use the mangler for three things: a) avx mangling, which I'm not certain we still need, and if we need it we should figure out why and fix it in llvm upstream. b) function/object rewrites, which I'm suspicious of as well (see https://reviews.llvm.org/D30812) and c) the `-dead_strip` fix, which we do not need with llvm5 or a patched llvm4 anymore and only affects mach-o based systems (iOS, macOS, ...) anyway. - Dropping the dreaded module layout / header logic was a long time goal of mine, as it is not only painful to keep those up to date, and I'm not even sure we have the proper values. As the Imrpoved LLVM Proposal was about bundling llvm **with** ghc, to have better control over the llvm backend, bundling clang (or if we really must opt+llc) looks to me like the way to go. Ideally though, I'd prefer to find all necessary fixes we need in llvm and have them upstreamed in llvm5, such that ghc8.4 can simply require llvm5. However I'm not opposed to laying the foundation to bundle clang with ghc, should the need arise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:56:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:56:54 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.13cfa0733a72c070a067c8051dd4b148@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: angerman Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * owner: (none) => angerman Comment: I'll assign this to me for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 09:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 09:58:56 -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.7fb35d1e02a9afcdbea76bdba476a187@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D3358 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => phab:D3358 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 11:48:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 11:48:01 -0000 Subject: [GHC] #13437: Easier editing of multi-line GHCi-commands Message-ID: <047.967b8a1ef91ee884091d61967540843f@haskell.org> #13437: Easier editing of multi-line GHCi-commands -------------------------------------+------------------------------------- Reporter: fredefox | 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: -------------------------------------+------------------------------------- In my terminal emulator I can write something like: {{{ cat > /dev/null << EOF bla bla bla EOF }}} If I later want to edit something in this command I can recall the command from history and I can navigate to the line I want to change. In GHCi this is not possible, the history only recalls *one line* at a time. It would be nice if it recognized commands entered using {{{ :{ ... }: }}} and would give you that whole command when recalling commands from the history. Also, it would be very handy if doing e.g. Shift+Enter would insert a newline into your multi-line command rather than run the command. Furthermore, it could also serve as a handy shortcut for engaging the multi-line command mode. So say you were sitting at the prompt {{{ > }}} and you then hit enter, then GHCi moves to a new-line but has inserted the {{{ :{ }}} part for you, it could similarly close the command for you when you hit Enter (without holding down the modifier key). I believe this change would make GHCi's multi-line command mode way more useful. Currently I very seldomly (if ever) use GHCi for anything other than one-liners. This means that I usually have to edit the source-file I'm currently working on to put things into scope (or try and formulate a long and awkward expression). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 11:51:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 11:51:02 -0000 Subject: [GHC] #13437: Easier editing of multi-line GHCi-commands In-Reply-To: <047.967b8a1ef91ee884091d61967540843f@haskell.org> References: <047.967b8a1ef91ee884091d61967540843f@haskell.org> Message-ID: <062.a96657ea9146e1332b6897bcf2bb822b@haskell.org> #13437: Easier editing of multi-line GHCi-commands -------------------------------------+------------------------------------- Reporter: fredefox | 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 fredefox: Old description: > In my terminal emulator I can write something like: > > {{{ > cat > /dev/null << EOF > bla > bla > bla > EOF > }}} > > If I later want to edit something in this command I can recall the > command from history and I can navigate to the line I want to change. In > GHCi this is not possible, the history only recalls *one line* at a time. > It would be nice if it recognized commands entered using {{{ :{ ... }: > }}} and would give you that whole command when recalling commands from > the history. > > Also, it would be very handy if doing e.g. Shift+Enter would insert a > newline into your multi-line command rather than run the command. > > Furthermore, it could also serve as a handy shortcut for engaging the > multi-line command mode. So say you were sitting at the prompt {{{ > }}} > and you then hit enter, then GHCi moves to a new-line but has inserted > the {{{ :{ }}} part for you, it could similarly close the command for you > when you hit Enter (without holding down the modifier key). > > I believe this change would make GHCi's multi-line command mode way more > useful. Currently I very seldomly (if ever) use GHCi for anything other > than one-liners. This means that I usually have to edit the source-file > I'm currently working on to put things into scope (or try and formulate a > long and awkward expression). New description: In my terminal emulator I can write something like: {{{ cat > /dev/null << EOF bla bla bla EOF }}} If I later want to edit something in this command I can recall the command from history and I can navigate to the line I want to change. In GHCi this is not possible, the history only recalls *one line* at a time. It would be nice if it recognized commands entered using {{{ :{ ... }: }}} and would give you that whole command when recalling commands from the history. Also, it would be very handy if doing holding down a modifier key when hitting enter (e.g. Shift) would insert a newline into your multi-line command rather than run the command. Furthermore, it could also serve as a handy shortcut for engaging the multi-line command mode. So say you were sitting at the prompt {{{ > }}} and you then hit Shift+Enter, then GHCi moves to a new-line but has inserted the {{{ :{ }}} part for you, it could similarly close the command for you when you hit Enter (without holding down the modifier key). I believe this change would make GHCi's multi-line command mode way more useful. Currently I very seldomly (if ever) use GHCi for anything other than one-liners. This means that I usually have to edit the source-file I'm currently working on to put things into scope (or try and formulate a long and awkward expression). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 11:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 11:53:08 -0000 Subject: [GHC] #13437: Easier editing of multi-line GHCi-commands In-Reply-To: <047.967b8a1ef91ee884091d61967540843f@haskell.org> References: <047.967b8a1ef91ee884091d61967540843f@haskell.org> Message-ID: <062.3fc9b65998e286b2426d8fc50937b375@haskell.org> #13437: Easier editing of multi-line GHCi-commands -------------------------------------+------------------------------------- Reporter: fredefox | 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 fredefox: Old description: > In my terminal emulator I can write something like: > > {{{ > cat > /dev/null << EOF > bla > bla > bla > EOF > }}} > > If I later want to edit something in this command I can recall the > command from history and I can navigate to the line I want to change. In > GHCi this is not possible, the history only recalls *one line* at a time. > It would be nice if it recognized commands entered using {{{ :{ ... }: > }}} and would give you that whole command when recalling commands from > the history. > > Also, it would be very handy if doing holding down a modifier key when > hitting enter (e.g. Shift) would insert a newline into your multi-line > command rather than run the command. > > Furthermore, it could also serve as a handy shortcut for engaging the > multi-line command mode. So say you were sitting at the prompt {{{ > }}} > and you then hit Shift+Enter, then GHCi moves to a new-line but has > inserted the {{{ :{ }}} part for you, it could similarly close the > command for you when you hit Enter (without holding down the modifier > key). > > I believe this change would make GHCi's multi-line command mode way more > useful. Currently I very seldomly (if ever) use GHCi for anything other > than one-liners. This means that I usually have to edit the source-file > I'm currently working on to put things into scope (or try and formulate a > long and awkward expression). New description: In my terminal emulator I can write something like: {{{ cat > /dev/null << EOF bla bla bla EOF }}} If I later want to edit something in this command I can recall the command from history and I can navigate to the line I want to change. In GHCi this is not possible, the history only recalls *one line* at a time. It would be nice if it recognized commands entered using {{{ :{ ... }: }}} and would give you that whole command when recalling commands from the history. Also, it would be very handy if holding down a modifier key when hitting enter (e.g. Shift) would insert a newline into your multi-line command rather than run the command. Furthermore, it could also serve as a handy shortcut for engaging the multi-line command mode. So say you were sitting at the prompt {{{ > }}} and you then hit Shift+Enter, then GHCi moves to a new-line but has inserted the {{{ :{ }}} part for you, it could similarly close the command for you when you hit Enter (without holding down the modifier key). I believe this change would make GHCi's multi-line command mode way more useful. Currently I very seldomly (if ever) use GHCi for anything other than one-liners. This means that I usually have to edit the source-file I'm currently working on to put things into scope (or try and formulate a long and awkward expression). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 13:06:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 13:06:01 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.30c5a564ac364a25d33bdf89b72a035b@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I believe the type checker should reject that class declaration. I'm not an expert at levity polymorphism, but I ''think'' class methods are supposed to have uniform calling conventions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 13:06:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 13:06:24 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.8918c9e811b41f921872b6242e1b5fa6@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- 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: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => GHC accepts invalid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 13:07:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 13:07:13 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.79735fa963ed502b569d2f246978c441@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Compiler (Type checker) * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 13:27:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 13:27:47 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.90da9c1cd510879cecfc533e3a4613b7@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:24:01 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.71eb7e614052d70f965ea57a4f884ba4@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"dca44adb9e14992e0aed49cdfd4b2baa2182073b/ghc" dca44adb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dca44adb9e14992e0aed49cdfd4b2baa2182073b" Fix #12709 by not building bad applications In an effort to report multiple levity polymorphism errors all at once, the desugarer does not fail when encountering bad levity polymorphism. But we must be careful not to build the bad applications, lest they try to satisfy the let/app invariant and call isUnliftedType on a levity polymorphic type. This protects calls to mkCoreAppDs appropriately. test case: typecheck/should_fail/T12709 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:24:01 -0000 Subject: [GHC] #13202: Levity polymorphism panic in GHCi In-Reply-To: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> References: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> Message-ID: <061.7568528cddca7264bc1a805e749a19d8@haskell.org> #13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"fa13c136e6e666b9a1393c1c0041020ad842c069/ghc" fa13c136/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fa13c136e6e666b9a1393c1c0041020ad842c069" Fix #13202 by failing more eagerly in tcRnStmt test cases: ghci/scripts/T13202{,a} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:24:01 -0000 Subject: [GHC] #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar In-Reply-To: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> References: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> Message-ID: <065.f06c609a911d21309720268468721528@haskell.org> #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | 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 Richard Eisenberg ): In [changeset:"02cc8f0c423e85033bdfd26f1492301b724930d8/ghc" 02cc8f0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02cc8f0c423e85033bdfd26f1492301b724930d8" Fix #13343 by not defaulting SigTvs test case: typecheck/should_compile/T13343 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:24:01 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.9e02bef0938c6c20222c53513350764d@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"66d174a9650c3099e2e694f71b43c2dac89b21b1/ghc" 66d174a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="66d174a9650c3099e2e694f71b43c2dac89b21b1" Test #13435 in typecheck/should_run/T13435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:26:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:26:16 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.f615e967d75bd6270fb73e952f8acfa3@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * milestone: 8.4.1 => 8.2.1 Comment: Levity polymorphism will evolve, and so I think it's worth merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:26:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:26:41 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.bfce60a6acac3da2652670103f222a4b@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_run/T13435 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_run/T13435 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:27:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:27:15 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.83033c00004096186b2b5f808a6262e5@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12709 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T12709 * milestone: => 8.2.1 Comment: Please merge for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:28:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:28:22 -0000 Subject: [GHC] #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar In-Reply-To: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> References: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> Message-ID: <065.375f4228cf58a56e4415c39885422fa9@haskell.org> #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.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/T13343 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T13343 * milestone: => 8.2.1 Comment: My comment:1 gets it all wrong, but it was simple in the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:28:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:28:58 -0000 Subject: [GHC] #13202: Levity polymorphism panic in GHCi In-Reply-To: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> References: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> Message-ID: <061.9c0e4e55760d89a73a2f74f4299c9b96@haskell.org> #13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T13202{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => ghci/scripts/T13202{,a} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:33:45 -0000 Subject: [GHC] #13438: ghci :browse does not work with DuplicateRecordFields Message-ID: <042.11a55998df45140f6a656eacb5763ba3@haskell.org> #13438: ghci :browse does not work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple duplicaterecordfields ghci | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using `:browse` on module which has enabled DuplicateRecordFields and datatypes are exported, does not return the field accessor functions. So for example: {{{#!hs data Login = Login { code :: Text , password :: Text } )}}} `browse` for module does not return `code` and `password` accessor functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 15:35:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 15:35:13 -0000 Subject: [GHC] #13438: ghci :browse does not work with DuplicateRecordFields In-Reply-To: <042.11a55998df45140f6a656eacb5763ba3@haskell.org> References: <042.11a55998df45140f6a656eacb5763ba3@haskell.org> Message-ID: <057.1095c664677b0728015a53e8177d7a11@haskell.org> #13438: ghci :browse does not work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: | duplicaterecordfields ghci Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by rik: Old description: > Using `:browse` on module which has enabled DuplicateRecordFields and > datatypes are exported, does not return the field accessor functions. > > So for example: > {{{#!hs > data Login = Login > { code :: Text > , password :: Text > } > )}}} > > `browse` for module does not return `code` and `password` accessor > functions. New description: Using `:browse` on module which has enabled DuplicateRecordFields and datatypes are exported, does not return the field accessor functions. So for example: {{{#!hs data Login = Login { code :: Text , password :: Text } }}} `browse` for module does not return `code` and `password` accessor functions. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 16:03:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 16:03:19 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function In-Reply-To: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> References: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> Message-ID: <061.44714c510ea8d71635e275cb10f72064@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13014 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 16:03:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 16:03:27 -0000 Subject: [GHC] #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary In-Reply-To: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> References: <046.24c2998367c5a8124c7521e8ac11ef2c@haskell.org> Message-ID: <061.534faf60dd63f2ff21829ac791832d88@haskell.org> #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The panic in comment:9 has been fixed after #13343 was resolved. The original bug in this ticket, however, still occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 16:56:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 16:56:09 -0000 Subject: [GHC] #13439: ForeignPtr finalizers not searched for reachable objects? Message-ID: <056.f796c398b55429929f19e9b623b919ea@haskell.org> #13439: ForeignPtr finalizers not searched for reachable objects? -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | Keywords: ForeignPtr | Operating System: Unknown/Multiple finalizers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program produces pairs of ForeignPtr's. The finalizer of the second ForeignPtr, uses the first ForeignPtr. When running this program it looks like the first ForeignPtr is finalized before the second one. {{{ import Control.Concurrent import Foreign.Concurrent (newForeignPtr) import Control.Monad import Foreign.ForeignPtr hiding (newForeignPtr) import Foreign.Ptr import System.Mem (performMajorGC) import Data.IORef import Data.Set as Set main = do rFinalized <- newIORef Set.empty forM_ [0..50000] $ \i -> do fp0 <- newForeignPtr nullPtr $ atomicModifyIORef' rFinalized (\s -> (Set.insert i s, ())) newForeignPtr nullPtr $ do finalized <- atomicModifyIORef' rFinalized (\s -> (Set.delete i s, Set.member i s)) when finalized $ putStrLn "fp0 was prematurely finalized" touchForeignPtr fp0 performMajorGC threadDelay 1000000 }}} {{{ $ ghc t.hs [1 of 1] Compiling Main ( t.hs, t.o ) Linking t ... $ ./t fp0 was prematurely finalized fp0 was prematurely finalized fp0 was prematurely finalized fp0 was prematurely finalized fp0 was prematurely finalized }}} Is this a bug in the implementation or an omission in the documentation of `Foreign.Concurrent.newForeignPtr`? Note that a more obvious program behaves correctly. {{{ main = do rFinalized <- newIORef False fp0 <- newForeignPtr nullPtr $ writeIORef rFinalized True newForeignPtr nullPtr $ do finalized <- readIORef rFinalized when finalized $ putStrLn "fp0 was prematurely finalized" touchForeignPtr fp0 performMajorGC threadDelay 1000000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 17:04:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 17:04:58 -0000 Subject: [GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC Message-ID: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC -------------------------------------+------------------------------------- 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, {{{ main :: IO () main = do { putStr "hello"; x <- getChar; -- or x <- getLine; putStr "x = "; print x; } }}} the program works in GHCi and after compilation with GHC. in GHCi it works fine but after compilation it does not work fine. in GHCi the first line of code is evaluated the first while after compilation is the second line which is evaluated first. so in GHCi we have as a result: {{{ hellom x = 'm' }}} and after compilation we have as a result: {{{ m hellox = 'm' }}} After compilation, putStr is not evaluated the first. It is getChar or getLine. In GHCi the behavior is correct. But after compilation the behavior is strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 17:47:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 17:47:44 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.2f89a2ef04de837967936d9790bb7458@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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:"a7dbafe9292212f3cbc21be42eb326ab0701db7e/ghc" a7dbafe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7dbafe9292212f3cbc21be42eb326ab0701db7e" No join-point from an INLINE function with wrong arity The main payload of this patch is NOT to make a join-point from a function with an INLINE pragma and the wrong arity; see Note [Join points and INLINE pragmas] in CoreOpt. This is what caused Trac #13413. But we must do the exact same thing in simpleOptExpr, which drove me to the following refactoring: * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new module CoreOpt along with a few others (exprIsConApp_maybe, pushCoArg, etc) This eliminates a module loop altogether (delete CoreArity.hs-boot), and stops CoreSubst getting too huge. * Rename Simplify.matchOrConvertToJoinPoint to joinPointBinding_maybe Move it to the new CoreOpt Use it in simpleOptExpr as well as in Simplify * Define CoreArity.joinRhsArity and use it }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 17:50:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 17:50:52 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.dbaa8a75ac6e5559efb6e3282e42382e@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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 fixes the crashes. But the INLINE pragams on `fillBlock` and `fillLine` are silly -- recursive functions are never inlined. And now they are (very mildly) harmful since they stop me turning the function into a join point. See the Note mentioned above. Best to remove the pragmas. I have not tested the `storablevector` crash; might someone do that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 17:51:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 17:51:17 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.05820fa91f876da31d88ca04566d2b40@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj 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: GHC rejects | Test Case: valid program | simplCore/should_compile/T13413 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T13413 Comment: Merge to 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 18:33:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 18:33:34 -0000 Subject: [GHC] #13439: ForeignPtr finalizers not searched for reachable objects? In-Reply-To: <056.f796c398b55429929f19e9b623b919ea@haskell.org> References: <056.f796c398b55429929f19e9b623b919ea@haskell.org> Message-ID: <071.2f21db208e98b993369e60f3cec03ff4@haskell.org> #13439: ForeignPtr finalizers not searched for reachable objects? -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: ForeignPtr | finalizers Operating System: 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): The documentation of [http://hackage.haskell.org/package/base-4.9.1.0/docs /Foreign-ForeignPtr.html#v:touchForeignPtr touchForeignPtr] mentions that it can't be used in finalizers to keep the pointer alive. But the program fails the same if one replaces it with {{{ main = do rFinalized <- newIORef Set.empty forM_ [0..50000] $ \i -> do fp0 <- newForeignPtr nullPtr $ atomicModifyIORef' rFinalized (\s -> (Set.insert i s, ())) + mv <- newMVar fp0 newForeignPtr nullPtr $ do finalized <- atomicModifyIORef' rFinalized (\s -> (Set.delete i s, Set.member i s)) when finalized $ putStrLn "fp0 was prematurely finalized" - touchForeignPtr fp0 + void $ takeMVar mv performMajorGC threadDelay 1000000 }}} Which means that the references in finalizers are peculiar in some sense beyond the specifics of `touchForeignPtr`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 18:37:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 18:37:50 -0000 Subject: [GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC In-Reply-To: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> References: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> Message-ID: <059.3f893b215abdfe33f980c5d7de6d7b87@haskell.org> #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC -------------------------------------+------------------------------------- Reporter: vanto | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Are you on Windows? If so, what console are you using? I know there are several issues regarding input/output buffering which might explain the discrepancies you're seeing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 18:42:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 18:42:31 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.21cf9c85fb9ca7c3cd70659e09bafcbf@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj 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: GHC rejects | Test Case: valid program | simplCore/should_compile/T13413 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `storablevector` now builds for me without issue on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 19:18:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 19:18:59 -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.e881ab3b4b0d6136b015aec8bfb3c7b6@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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): I was able to reproduce this issue using lists instead of vector package, confirming that it is indeed a bug in ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 19:28:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 19:28:18 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.75b8f719337db0b76df9a818c14ae28d@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Reid thinks he's found the ultimate source, in an optimization he made intended to help with tag bit checks. Here's a greatly reduced reproduction case: {{{#!hs import Data.Bits ((.&.)) flags :: Int -> Int flags x | x .&. 128 > 0 = 12 | otherwise = 13 {-# NOINLINE flags #-} main :: IO () main = print (flags 255) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 20:06:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 20:06:48 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.6a55dda49e8ba99974b8ef6c2a7d3483@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I reduced the file from ~400 lines to ~150 lines: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Data.Vector.Hybrid.Internal (Vector) where import Control.Monad (liftM2) import Data.Functor.Identity (Identity(..)) import GHC.ST (ST, runST) import Text.Read (ReadPrec, readPrec) ----- class Monad m => PrimMonad m where type PrimState m instance PrimMonad (ST s) where type PrimState (ST s) = s class GMVector v a where gmbasicLength :: v s a -> Int gmbasicUnsafeSlice :: Int -> Int -> v s a -> v s a gmbasicUnsafeNew :: PrimMonad m => Int -> m (v (PrimState m) a) gmbasicUnsafeWrite :: PrimMonad m => v (PrimState m) a -> Int -> a -> m () type family GMutable (v :: * -> *) :: * -> * -> * class GMVector (GMutable v) a => GVector v a where gbasicUnsafeFreeze :: PrimMonad m => GMutable v (PrimState m) a -> m (v a) data Step s a where Yield :: a -> s -> Step s a instance Functor (Step s) where {-# INLINE fmap #-} fmap f (Yield x s) = Yield (f x) s data Stream m a = forall s. Stream (s -> m (Step s a)) s data Chunk v a = Chunk Int (forall m. (PrimMonad m, GVector v a) => GMutable v (PrimState m) a -> m ()) data New v a = New { newrun :: forall s. ST s (GMutable v s a) } type MBundle m v a = Stream m (Chunk v a) type Bundle v a = MBundle Identity v a mbfromStream :: Monad m => Stream m a -> MBundle m v a {-# INLINE mbfromStream #-} mbfromStream (Stream step t) = Stream step' t where step' s = do r <- step s return $ fmap (\x -> Chunk 1 (\v -> gmbasicUnsafeWrite v 0 x)) r mbunsafeFromList :: Monad m => [a] -> MBundle m v a {-# INLINE [1] mbunsafeFromList #-} mbunsafeFromList xs = mbfromStream (sfromList xs) blift :: Monad m => Bundle v a -> MBundle m v a {-# INLINE [1] blift #-} blift (Stream vstep t) = Stream (return . runIdentity . vstep) t sfromList :: Monad m => [a] -> Stream m a {-# INLINE sfromList #-} sfromList zs = Stream step zs where step (x:xs) = return (Yield x xs) step _ = undefined sfoldlM :: Monad m => (a -> b -> m a) -> a -> Stream m b -> m a {-# INLINE [1] sfoldlM #-} sfoldlM m w (Stream step t) = foldlM_loop w t where foldlM_loop z s = do r <- step s case r of Yield x s' -> do { z' <- m z x; foldlM_loop z' s' } gmvunstream :: (PrimMonad m, GVector v a) => Bundle v a -> m (GMutable v (PrimState m) a) {-# INLINE [1] gmvunstream #-} gmvunstream s = gmvmunstreamUnknown (blift s) gmvmunstreamUnknown :: (PrimMonad m, GVector v a) => MBundle m v a -> m (GMutable v (PrimState m) a) {-# INLINE gmvmunstreamUnknown #-} gmvmunstreamUnknown s = do v <- gmbasicUnsafeNew 0 (_, _) <- sfoldlM copyChunk (v,0) s return undefined where {-# INLINE [0] copyChunk #-} copyChunk (v,i) (Chunk n f) = do let j = i+n v' <- if gmbasicLength v < j then gmbasicUnsafeNew undefined else return v f (gmbasicUnsafeSlice i n v') return (v',j) newunstream :: GVector v a => Bundle v a -> New v a {-# INLINE [1] newunstream #-} newunstream s = s `seq` New (gmvunstream s) gnew :: GVector v a => New v a -> v a {-# INLINE [1] gnew #-} gnew m = m `seq` runST (gbasicUnsafeFreeze =<< newrun m) gunstream :: GVector v a => Bundle v a -> v a {-# INLINE gunstream #-} gunstream s = gnew (newunstream s) gfromList :: GVector v a => [a] -> v a {-# INLINE gfromList #-} gfromList = gunstream . mbunsafeFromList greadPrec :: (GVector v a, Read a) => ReadPrec (v a) {-# INLINE greadPrec #-} greadPrec = do xs <- readPrec return (gfromList xs) ----- data MVector :: (* -> * -> *) -> (* -> * -> *) -> * -> * -> * where MV :: !(u s a) -> !(v s b) -> MVector u v s (a, b) instance (GMVector u a, GMVector v b) => GMVector (MVector u v) (a, b) where gmbasicLength (MV ks _) = gmbasicLength ks gmbasicUnsafeSlice s e (MV ks vs) = MV (gmbasicUnsafeSlice s e ks) (gmbasicUnsafeSlice s e vs) gmbasicUnsafeNew n = liftM2 MV (gmbasicUnsafeNew n) (gmbasicUnsafeNew n) -- Removing this INLINE pragma makes it compile {-# INLINE gmbasicUnsafeNew #-} gmbasicUnsafeWrite (MV ks vs) n (k,v) = do gmbasicUnsafeWrite ks n k gmbasicUnsafeWrite vs n v data Vector :: (* -> *) -> (* -> *) -> * -> * type instance GMutable (Vector u v) = MVector (GMutable u) (GMutable v) instance (GVector u a, GVector v b) => GVector (Vector u v) (a, b) where gbasicUnsafeFreeze = undefined instance (GVector u a, GVector v b, Read a, Read b, c ~ (a, b)) => Read (Vector u v c) where readPrec = greadPrec }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 20:08:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 20:08:19 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.ce7029ad52d8de2483163af3e0a0d18d@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | typecheck/should_run/T13435 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: GHC accepts invalid program => Runtime crash Comment: Guess I was wrong.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 20:12:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 20:12:34 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.cf6449c759b3e5f27bc75f0f8be2e3e1@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 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): Phab:D3359 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * differential: => Phab:D3359 * milestone: => 8.2.1 Comment: Yep, sorry about that! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 20:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 20:36:16 -0000 Subject: [GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC In-Reply-To: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> References: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> Message-ID: <059.fa047a8dd319d7b421dfbe225a3b7c00@haskell.org> #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC -------------------------------------+------------------------------------- Reporter: vanto | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): for RyanGIScott\\ yes, I am on Windows. I use a standard Windows console (cmd.exe)\\ I also use Linux Debian8 under virtualBox.\\ I have just tested this program on Linux and here are the results.\\ With GHCi the result is:\\ {{{ *Main> main hellomx = 'm' *Main> }}} It seems much better than GHCi on Windows.\\ After compiling, the result is the same as Windows.\\ {{{ vanto at debian:~/sourcehs$./test m hellox = 'm' }}} On the other hand, I used runghc to test the program on Windows and Linux and here are the results:\\ with Windows\\ the result is the same as compilation on Windows\\ {{{ c:\sourcehs>runghc test.hs m hellox = 'm' }}} with Linux\\ the result is the same as GHCi on Windows\\ {{{ vanto at debian:~/sourcehs$ runghc test.hs hellom x = 'm' }}} Hope this help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 20:51:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 20:51:03 -0000 Subject: [GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC In-Reply-To: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> References: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> Message-ID: <059.e710cdc8acba49f5c70d9c60be2f6d8c@haskell.org> #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC -------------------------------------+------------------------------------- Reporter: vanto | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): On Linux I use GHC version: 8.0.2\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 20:58:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 20:58:11 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.e244bcc500be6c98c49cfedf8b5cb1b5@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 21:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 21:03:16 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.27724d80d8582911266a3b1a81513f13@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => upstream * milestone: => 8.4.1 Comment: I believe this to be an upstream bug in `mingw-w64-crt`. It seems that `ntdll.dll` undocumented exports a few functions such as `atan`. The import libraries are created by default using a tool that scrapes the exports table of a dll and makes a `.def` file and then `dlltool` is called to generate the library. The problem is that this tool on the `x86` version seems to think these functions are `DATA` references (e.g. readonly data) instead of functions. And this it only exports `_imp__atan` instead of both `_atan` and `_imp__atan`. On `x64` the tool does get this correct. {{{ Tamar at Kino MINGW64 ~/MINGW-packages/mingw-w64-crt-git/src/mingw-w64 $ find -iname ntdll.def | xargs grep atan ./mingw-w64-crt/lib32/ntdll.def:atan DATA ./mingw-w64-crt/lib64/ntdll.def:atan ./mingw-w64-crt/libarm32/ntdll.def:atan }}} This will require some upstream patching because controlling the link order in all cases is very hard. In the meantime since it seems that `Win32` is the only one that's introducing this dependency, I think I can apply a patch locally there for `x86`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 21:11:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 21:11:08 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.8b39d80a7154679acc8e059fa9329025@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What is the patch you're referring to, out of curiosity? I'd also need to apply this patch to my `mintty` library as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 21:13:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 21:13:02 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.c6e11a66da6b1b4a55d6105aa78ac6aa@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): compiling and bundling a fixed `libntdll.a` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 21:31:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 21:31:12 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.8c3b60f8d006baeb5584bc7e58e100d7@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Or rather, depending on the amount of functions, I'll probably dynamically import them instead of statically linking. That way I can avoid `libntdll.a` completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 22:23:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 22:23:14 -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.4972fadea92d399c8ea9e459a664ccc1@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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): Replying to [comment:2 lehins]: > I was able to reproduce this issue using lists instead of vector package, confirming that it is indeed a bug in ghc. Could you attach that reproduction here? I suspect this might be worth investigating a bit more, despite the pain, to make sure that the underlying problem was actually fixed and not just buried. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 22:29:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 22:29:47 -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.8481514714238215f60c080d7e1c7f12@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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 lehins): * Attachment "Loop.2.hs" added. Same implementation triggering a bug using List instead of vector. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 22:46:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 22:46:02 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.67fb8a6aeb1942f1aa4b214807d6514a@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Upstream bug reported https://sourceforge.net/p/mingw-w64/bugs/596/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 22:54:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 22:54:53 -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.4d96a2f9afedbf1ce03e07a5735135f4@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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 rwbarton): Thanks. I confirmed that the bug was present in HEAD as of Feb 1 but is not present any more. Something rather curious is that the bug cannot be reproduced when there are `.hi` and `.o` files present from a previous compilation with the same version of ghc, even when passing `-fforce-recomp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 23:19:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 23:19:33 -0000 Subject: [GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC In-Reply-To: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> References: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> Message-ID: <059.b409d0b35e8f5c0ff3f0e2dae94cc6b1@haskell.org> #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #2189 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #2189 Comment: As it turns out, this is a duplicate of a //long//-standing bug in GHCi, #2189. Fixing that bug will probably require rewriting the whole IO manager to use native Win32 IO (see #11394), but luckily, someone is working on this. Until then, I can offer you two workarounds. 1. If you want to have a stronger guarantee that `"hello"` will be printed first, you can use `hFlush stdout` to force this: {{{#!hs import System.IO main :: IO () main = do { putStr "hello"; hFlush stdout; x <- getChar; -- or x <- getLine; putStr "x = "; print x; } }}} 2. Alternatively, you can try a different buffering strategy. By default, `stdout`'s buffering mode is `NoBuffering` (which should, in theory, mean that all output is immediately printed to the screen, were it not for #2189). But you can change the buffering mode to something else: {{{#!hs import System.IO main :: IO () main = do { hSetBuffering stdout $ BlockBuffering $ Just 1; putStr "hello"; x <- getChar; -- or x <- getLine; putStr "x = "; print x; } }}} This does buffer the output, but only 1 character at a time. I've experimentally verified that both of these workaround work on my Windows machine, on both `cmd.exe` and MSYS2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 23:20:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 23:20:13 -0000 Subject: [GHC] #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC In-Reply-To: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> References: <044.907dfc87e5483789a92f01c6ffdeea47@haskell.org> Message-ID: <059.3af11d4bc2a1e3a9d01a9bedb85f2b6d@haskell.org> #13440: putStr doesn't have the same behavior in GHCi and after compilation with GHC ------------------------------+---------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #2189 | Differential Rev(s): Wiki Page: | ------------------------------+---------------------------------------- Changes (by RyanGlScott): * os: Unknown/Multiple => Windows * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 17 23:38:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Mar 2017 23:38:07 -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.f331107551db93704ea293e956084663@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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): It's good to hear that it is fixed. It would be nice to know what is the actual cause and a reliable way to avoid this bug with ghc-8.0.2 and older, so anybody who stumbles upon it has a workaround. It feels like it has something to do with class constraints and inlining, but what exactly is still a mystery to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 01:21:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 01:21:05 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match Message-ID: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- In my musings in preparation toward teaching my undergrads about GADTs, I tried defining the usual old `Vec` in terms of `FList`s (definition below) and pattern synonyms. Here is the code: {{{ {-# LANGUAGE ScopedTypeVariables, PatternSynonyms, DataKinds, PolyKinds, GADTs, TypeOperators, TypeFamilies #-} module VecFList where import Data.Functor.Identity data FList f xs where FNil :: FList f '[] (:@) :: f x -> FList f xs -> FList f (x ': xs) data Nat = Zero | Succ Nat type family Length (xs :: [k]) :: Nat where Length '[] = Zero Length (_ ': xs) = Succ (Length xs) type family Replicate (n :: Nat) (x :: a) = (r :: [a]) where Replicate Zero _ = '[] Replicate (Succ n) x = x ': Replicate n x type Vec n a = FList Identity (Replicate n a) pattern Nil :: forall n a. n ~ Length (Replicate n a) => n ~ Zero => Vec n a pattern Nil = FNil pattern (:>) :: forall n a. n ~ Length (Replicate n a) => forall m. n ~ Succ m => a -> Vec m a -> Vec n a pattern x :> xs <- Identity x :@ xs where x :> xs = Identity x :@ xs }}} This fails with {{{ /Users/rae/temp/Bug.hs:30:34: error: • Could not deduce: m0 ~ Length xs arising from the "provided" constraints claimed by the signature of ‘:>’ from the context: n ~ Length (Replicate n a) bound by the type signature of pattern synonym ‘:>’ at /Users/rae/temp/Bug.hs:30:11-12 • In the declaration for pattern synonym ‘:>’ • Relevant bindings include xs :: FList Identity xs (bound at /Users/rae/temp/Bug.hs:30:34) }}} If I comment out the last two lines (the "explicitly bidirectional" part), compilation succeeds, even though the reported error is on the first line of the `:>` pattern synonym definition (the pattern part). Also, the following separate declaration compiles without incident: {{{ (>>>) :: forall n a. n ~ Length (Replicate n a) => forall m. n ~ Succ m => a -> Vec m a -> Vec n a x >>> xs = Identity x :@ xs }}} I believe the original program should compile, and should continue to compile if I replace the `<-` in the patsyn definition with `=`. For the curious: I tried putting an injectivity annotation on `Replicate` to avoid those `n ~ Length (Replicate n a)` constraints, but type family injectivity just isn't strong enough. Also, I'm not at all sure this definition is any use. But the behavior I report above shouldn't happen, regardless. Reproducible in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 02:03:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 02:03:53 -0000 Subject: [GHC] #13439: ForeignPtr finalizers not searched for reachable objects? In-Reply-To: <056.f796c398b55429929f19e9b623b919ea@haskell.org> References: <056.f796c398b55429929f19e9b623b919ea@haskell.org> Message-ID: <071.9547a6d7dcf5036f1ba34dd43ff9b261@haskell.org> #13439: ForeignPtr finalizers not searched for reachable objects? -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: ForeignPtr | finalizers Operating System: 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): The semantics of finalizers for [http://hackage.haskell.org/package/base-4.9.1.0/docs/System-Mem- Weak.html#g:4 weak pointers] would explain this behavior. If they are indeed the same for ForeignPtr's, it would help saying so in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 06:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 06:17:19 -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.2197af0482e3a9273819a4aca1afffc1@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I now believe the culprit is this added line in originally `lintCoreVar`, now `lintVarOcc`: {{{#!diff + ; ensureEqTys ty ty' $ mkBndrOccTypeMismatchMsg var' var ty' ty }}} Reasoning: `perf` showed that when running with `-dcore-lint`, the single function that takes the most time after the garbage collector is `nonDetCmpTypeX_go`. Before the join points patch, it took 6.5% of the total time. After, it took 9.1% of the total time. And there seems to be nothing that corresponds to this `ensureEqTys` call before the join points patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 07:01:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 07:01:52 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM Message-ID: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to implement casts between floating-point and integral types #4092) @rwbarton suggested the following CMM: {{{ stg_wordToFloatzh(W_ w) { D_ d; STK_CHK_P_LL(WDS(1), stg_wordToFloatzh, w); Sp(-1) = w; d = Sp(-1); return (d); } }}} This code works outside of GHC, but when I try to add it as `rts/CastFloatWord.cmm` the CMM linter complains with: {{{ Cmm lint error: in basic block c5 in assignment: _c2::F64 = I64[Sp + -1 * 8]; Reg ty: F64 Rhs ty: I64 Program was: {offset c6: // global _c1::I64 = R1; //tick src if (Sp - 1 * 8 < SpLim) goto c3; else goto c5; c3: // global //tick src R1 = _c1::I64; R2 = stg_wordToFloatzh; call stg_gc_prim_p_ll(R1, R2) args: 8, res: 0, upd: 8; c5: // global I64[Sp + -1 * 8] = _c1::I64; _c2::F64 = I64[Sp + -1 * 8]; D1 = _c2::F64; call (P64[(old + 8)])(D1) args: 8, res: 0, upd: 8; } }}} For hand written CMM code like this, it would be nice to have a cast/coercion to allow this code to pass the linter. Looking for suggestions as to the syntax. I suspect that it would be best if the destination type was made explicit in the cast operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 07:48:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 07:48:17 -0000 Subject: [GHC] #13443: Typeclass resolution errors quite puzzling Message-ID: <051.f75b47e89b46a32f178b489cb149873e@haskell.org> #13443: Typeclass resolution errors quite puzzling -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is based on a post I made to haskell-cafe: https://mail.haskell.org/pipermail/haskell-cafe/2016-August/124622.html Here's a program with an odd error message (GHC 8.0.1): {{{ data A a = A a deriving Eq data B = B main :: IO () main = print (A B == A B) test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) }}} I get an error about `Eq B` even though it's `Eq A` that is manifestly required at the call site. This error is odder when `A` and `B` are defined far away from the use of `==`. This is even odder: {{{ data A a = A a data B = B instance Ord a => Eq (A a) where main :: IO () main = print (A B == A B) test/main.hs:7:15: error: • No instance for (Ord B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) }}} Now not only is the type puzzling (`B` instead of `A`) but the *class* is puzzling (`Ord` instead of `Eq`). This occurred to me in practice because `Data.Graph.Inductive.PatriciaTree.Gr` has `(Eq a, Ord b) => Eq (Gr a b)`. It would have been a lot more helpful to see {{{ * No instance for (Ord B) * arising from (Eq A) * arising from the use of '==' }}} Does anyone agree with me that GHC should produce the full trace when it fails to resolve instances rather than just the proximal failure? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 08:30:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 08:30:35 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.39be9212c80dbd6d1fc2121aa03c89cc@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: new Priority: high | 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 ezyang): Yes, I've diagnosed the problem. The trouble is that the new algorithm for computing package shadowing doesn't remember the order packages were specified in package databases, so it doesn't respect the flag ordering; instead, it relies entirely on the (deterministic) comparison of unit identifiers. Probably the reason why this wobbled is because Cabal was allocating different unit identifiers on different platforms, causing the (deterministic) comparison to wobble, so that we picked one or another. It would be very good to fix this in time for GHC 8.2. However, fixing this seems a bit annoying in the current algorithm, because there isn't really a good way to remember the package ordering after we suck all the packages into an InstalledPackageIndex. I'll work on a fix this weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 09:10:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 09:10:45 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.0e5fd3e28fe7feebf2ff1428c7ece37d@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 erikd): For the time being, I'm going with the following syntax: {{{ _c2::F64 = I64[Sp + -1 * 8]; }}} where the `` is the cast destination type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 11:00:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 11:00:46 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.62db3dc03b871949e233c3c0cb7de2b3@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 11:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 11:04:10 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default Message-ID: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- TO my suprise, GHC 8.2.1 enables colors by default which is rather annoying to me as it looks rather ugly with my terminal coloring scheme. This should follow GCC's model instead which defaults them off and allows to customize the coloring scheme via `GCC_COLORS`. Quoting the GCC man- page: > `-fdiagnostics-color[=WHEN]` > `-fno-diagnostics-color` > > Use color in diagnostics. WHEN is never, always, or auto. The default depends on how > the compiler has been configured, it can be any of the above WHEN options or also never > if GCC_COLORS environment variable isn't present in the environment, and auto > otherwise. auto means to use color only when the standard error is a terminal. The > forms -fdiagnostics-color and -fno-diagnostics-color are aliases for > `-fdiagnostics-color=always` and `-fdiagnostics-color=never`, respectively. > > The colors are defined by the environment variable `GCC_COLORS`. Its value is a colon- > separated list of capabilities and Select Graphic Rendition (SGR) substrings. SGR > commands are interpreted by the terminal or terminal emulator. (See the section in the > documentation of your text terminal for permitted values and their meanings as > character attributes.) These substring values are integers in decimal representation > and can be concatenated with semicolons. Common values to concatenate include 1 for > bold, 4 for underline, 5 for blink, 7 for inverse, 39 for default foreground color, 30 > to 37 for foreground colors, 90 to 97 for 16-color mode foreground colors, 38;5;0 to > 38;5;255 for 88-color and 256-color modes foreground colors, 49 for default background > color, 40 to 47 for background colors, 100 to 107 for 16-color mode background colors, > and 48;5;0 to 48;5;255 for 88-color and 256-color modes background colors. > > The default `GCC_COLORS` is > > `error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01` > > where 01;31 is bold red, 01;35 is bold magenta, 01;36 is bold cyan, 01;32 is bold green > and 01 is bold. Setting GCC_COLORS to the empty string disables colors. Supported > capabilities are as follows. > > "error=" > SGR substring for error: markers. > > "warning=" > SGR substring for warning: markers. > > "note=" > SGR substring for note: markers. > > "caret=" > SGR substring for caret line. > > "locus=" > SGR substring for location information, file:line or file:line:column etc. > > "quote=" > SGR substring for information printed within quotes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 11:23:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 11:23:17 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.5e3eac2603ea2509ad4664b5e8495e18@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Quoting also https://gcc.gnu.org/gcc-4.9/changes.html when this was introduced to GCC: > Support for colorizing diagnostics emitted by GCC has been added. The `-fdiagnostics-color=auto` will enable it when outputting to terminals, `-fdiagnostics-color=always` unconditionally. The `GCC_COLORS` environment variable can be used to customize the colors or disable coloring. **If `GCC_COLORS` variable is present in the environment, the default is `-fdiagnostics-color=auto`, otherwise `-fdiagnostics-color=never`.** -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 12:25:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 12:25:22 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.0f09a551ff58724810a429ba04a0c6ff@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | 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 Sat Mar 18 15:06:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 15:06:36 -0000 Subject: [GHC] #13445: Fix 32 bit Windows build of GHC 8.2 Message-ID: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> #13445: Fix 32 bit Windows build of GHC 8.2 --------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: #13431 Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Current head is broken due to some `-Werr` failures and a bug in `x86 mingw-w64` distribution. See #13431 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 15:22:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 15:22:14 -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.598d0d77c4a1c8240c02387ada206d85@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 15:25:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 15:25:06 -0000 Subject: [GHC] #13445: Fix 32 bit Windows build of GHC 8.2 In-Reply-To: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> References: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> Message-ID: <059.a8b74c3ffb993d30f122ccf985e61452@haskell.org> #13445: Fix 32 bit Windows build of GHC 8.2 ----------------------------------------+---------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #13431 | Differential Rev(s): Phab:D3362 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by Phyx-): * priority: normal => highest * cc: bgamari (added) * differential: => Phab:D3362 * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 15:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 15:37: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.4d01fc8b08228f3746306c6c4906b8d1@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hmm, removing that test (if it's even okay) also didn't have as much effect as I hoped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 16:19:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 16:19:14 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.7e3c7c4088a6d081f9fc6eb39692ccd3@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 16:20:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 16:20:44 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.5ae635c5f5c192620757ddf927bcdf5d@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 16:32:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 16:32:52 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.5c74204981f3c3c8f083280387fe54da@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Quick update: At this point I have determined that the issue is the fix to #5642. Ultimately it seems like we are ending up with a `stg_sel_5_upd` being invoked on a `SimplEnv.FloatFlag`, which is not a single-constructor record (it is a enumeration). Naturally, things go terribly awry. Still trying to work out exactly how we get into this situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 17:55:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 17:55:58 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.61a482cd5e29a99057adefc486d1c0a2@haskell.org> #149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: Is this still an issue, or can we close this ticket? I'm unclear as to the status. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:04:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:04:58 -0000 Subject: [GHC] #13443: Typeclass resolution errors quite puzzling In-Reply-To: <051.f75b47e89b46a32f178b489cb149873e@haskell.org> References: <051.f75b47e89b46a32f178b489cb149873e@haskell.org> Message-ID: <066.e5b371984e426ab591887a3a2ea1406d@haskell.org> #13443: Typeclass resolution errors quite puzzling -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | 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 dfeuer): * failure: None/Unknown => Poor/confusing error message * milestone: => 8.4.1 Comment: I think it would be very useful to offer this as an option. Turning it on by default could be quite harmful, however, as context reduction can take many steps (thousands or more in type-heavy code) and we don't want to use a ton of memory unnecessarily. One option might be to let users set a particular maximum depth to report. Another (maybe?) could be to add a feature a bit like `HasCallStack` at the type level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:10:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:10:56 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.58493497b1ca68178fc8c873552b0536@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 bgamari]: > Quick update: At this point I have determined that the issue is the fix to #5654. Ultimately it seems like we are ending up with a `stg_sel_5_upd` being invoked on a `SimplEnv.FloatFlag`, which is not a single-constructor record (it is a enumeration). Naturally, things go terribly awry. Still trying to work out exactly how we get into this situation. How can the fix to a closed ticket fix a new one? I'm missing something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:21:28 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.1973ef83ec6a52c2e1a94bf8d4029172@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'd prefer to make the default `auto`. To be frank, looking pretty in your coloring scheme seems less important than helping new users understand what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:23:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:23:38 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.1eb9111c9f4b83b706c6618495f38e59@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To put it another way, the fix to #5654 caused this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:25:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:25:14 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.29a34bf8d19cf7c6dd7b244dc4c3eca1@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I do agree that the ability to configure the color scheme with a `GHC_COLORS` environment variable would be a cool feature. But I agree with David that I think outright disabling colors unless an environment variable is defined is going too far. Moreover, you can disable colors quite easily with `-fdiagnostics-color=never` in GHC, so I don't think this needs to be a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:27:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:27:14 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.33797c5f241f62aa224d8e934e69183e@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 18:50:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 18:50:26 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.cabc12392b1eaa4c699dd71e2309cd39@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: merge Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge Comment: I'm going to go ahead and revert 3a18baff06abc193569b1b76358da26375b3c8d6, 2a02040b2e23daa4f791afc290c33c9bbe3c620c, and 394231b301efb6b56654b0a480ab794fe3b7e4db on `ghc-8.2` due to #13433. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 19:20:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 19:20:10 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.fb5fe9888942a4d48dddfbeb1264b5bd@haskell.org> #149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds to me like this is still an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 20:17:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 20:17:52 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.ac474c2668f576776a9500f76640706c@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 bgamari): Can we have a keyword in there as well? Anything to avoid Cmm turning into more of a symbol-soup that it already is. Perhaps `cast I64[Sp + -1 * 8];`¿ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 20:27:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 20:27:16 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags In-Reply-To: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> References: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> Message-ID: <060.10f753bf5b2047b7d9ccb711ced18c00@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10961 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Dalaing, what ever happened to this? I would like to see this happen. Currently it is significantly harder than necessary for API users to use the pretty printer due to the spurious dependence on the entirety of `DynFlags`. Moreover, this dependency leads to an awkward coupling between the printer and the all encompassing `DynFlags` module, leading to a proliferation of import loops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 21:07:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 21:07:09 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.426f44ebf2a27400037e5a865583ac40@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 erikd): Sure, that should be easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 21:12:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 21:12:38 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled Message-ID: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a very perplexing bug that MitchellSalad discovered and advertised in [https://www.reddit.com/r/haskell/comments/604mze/deferred_type_errors_without_setting/ this Reddit post]. Consider this code: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fno-defer-type-errors #-} module Main where import Data.Coerce (Coercible) import GHC.Exts (Constraint) import GHC.TypeLits (Symbol) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) instance a => Show (a :- b) where showsPrec d (Sub Dict) = showParen (d > 10) $ showString "Sub Dict" class Lifting p f where lifting :: p a :- p (f a) data Blah a = Blah newtype J (a :: JType) = J (Blah (J a)) newtype JComparable a = JComparable (J (T (JTy a))) instance Lifting JReference JComparable where lifting = Sub 'a' class (Coercible a (J (JTy a))) => JReference a where type JTy a :: JType type T a = 'Generic ('Iface "java.lang.Comparable") '[a] data JType = Class Symbol | Generic JType [JType] | Iface Symbol type JObject = J (Class "java.lang.Object") instance JReference JObject where type JTy JObject = 'Class "java.lang.Object" main :: IO () main = print (lifting :: JReference JObject :- JReference (JComparable JObject)) }}} There are three concerning things about this: 1. Look at the line `lifting = Sub 'a'`. That's obviously bogus, as `Char`s are not `Dict`s! Yet GHC 8.0.2 and HEAD readily typecheck this code without warnings. 2. So now that we seem to have circumvented type safety, what happens if we actually try to //run// code which uses this bogus `Lifting` instance? Something truly bizarre, that's what: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: 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. λ> main *** Exception: Bug.hs:34:17: error: • Couldn't match expected type ‘Dict (JReference (JComparable a))’ with actual type ‘Char’ • In the first argument of ‘Sub’, namely ‘'a'’ In the expression: Sub 'a' In an equation for ‘lifting’: lifting = Sub 'a' • Relevant bindings include lifting :: JReference a :- JReference (JComparable a) (bound at Bug.hs:34:3) (deferred type error) }}} Somehow, we managed to defer a type mismatch between `Char` and `Dict`. All while `-fno-defer-type-errors` is enabled! 3. Worst of all, this is a regression from GHC 8.0.1, as it will actually detect the type mismatch at compile-time: {{{ $ /opt/ghc/8.0.1/bin/ghci Bug.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:34:17: error: • Couldn't match expected type ‘Dict (JReference (JComparable a))’ with actual type ‘Char’ • In the first argument of ‘Sub’, namely ‘'a'’ In the expression: Sub 'a' In an equation for ‘lifting’: lifting = Sub 'a' • Relevant bindings include lifting :: JReference a :- JReference (JComparable a) (bound at Bug.hs:34:3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 21:29:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 21:29:33 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.c0b026f5931804bde887644212a520db@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Any specific suggestions on how the default color scheme could be tuned to be more aesthetically pleasing? I think red is pretty standard for errors, but the colors of warnings and margins could perhaps be tweaked if needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 22:17:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 22:17:38 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.e5b6bfeb8d8e6d2ac6fea43244e12b2f@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 rwbarton): Replying to [comment:1 erikd]: > For the time being, I'm going with the following syntax: > {{{ > _c2::F64 = I64[Sp + -1 * 8]; > }}} > where the `` is the cast destination type. I'm a little confused, is this supposed to be valid input Cmm? I thought I got a syntax error when I tried writing things like {{{ a = I64[Sp - WDS(1)]; }}} but if you can write that, then the version for a double should certainly be {{{ a = F64[Sp - WDS(1)]; }}} and not involve any sort of "cast". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 22:43:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 22:43:53 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.ff84603504b6a5fe27c03db88b8f2d2c@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 rwbarton): In particular, an actual cast is problematic as your original purpose here was precisely to implement a word to double cast operation. It seems like the goal of adding this cast is to slip past Cmm's type checking, but as there actually is a well-typed way to do what you want in Cmm, it would be better to do that; and add input Cmm syntax for it if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 22:50:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 22:50:03 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.642ef18a33fd036c03f9372150707875@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Commit 03541cbae50f0d1cdf99120ab88698f29a278159 {{{ From 03541cbae50f0d1cdf99120ab88698f29a278159 Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Fri, 9 Sep 2016 17:42:42 +0100 Subject: [PATCH] Be less picky about reporing inaccessible code Triggered by the discussion on Trac #12466, this patch makes GHC less aggressive about reporting an error when there are insoluble Givens. Being so agressive was making some libraries fail to compile, and is arguably wrong in at least some cases. See the discussion on the ticket. Several test now pass when they failed before; see the files-modified list for this patch. }}} caused this regression. Thought, Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 18 23:55:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Mar 2017 23:55:57 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.c25b1f1ef34c9a29b2ca53f63f18d426@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Total shot in the dark: perhaps the reason that this is typechecking is that, post-03541cbae50f0d1cdf99120ab88698f29a278159, GHC treats all cases with insoluble given constraints as inaccessible. In the case of `lifting = Sub 'a'`, you have the given constraint `Coercible a (J (JTy a))`, and since GHC can't reduce the type family `JTy a` any, it deems `Coercible a (J (JTy a))` insoluble, causing it to typecheck. However, if you actually use `lifting` and instantiate the type variable `a` with `JObject`, then `JTy JObject` //does// reduce, and now the given constraint is `Coercible JObject (J ('Class "java.lang.Object"))`, or equivalently, `Coercible (J ('Class "java.lang.Object")) (J ('Class "java.lang.Object"))`, which //is// soluble! Perhaps this is revealing a typechecker implementation detail that inaccessible cases become deferred type errors if they are actually accessed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 00:05:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 00:05:59 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.ed89f942472502dc3dc688a7f4f3c9b9@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: That commit was never entirely satisfactory, as it hit the problem with a hammer instead of (IIRC) trying to distinguish between insoluble constraints in positive and negative position. Or something like that. Whether that relates to the problem here I couldn't say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 00:11:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 00:11:05 -0000 Subject: [GHC] #13447: error on MacOS Sierra upgrading stack Message-ID: <047.6ba3c83fc73a5c6771edcf78f4ed56cb@haskell.org> #13447: error on MacOS Sierra upgrading stack -------------------------------------+--------------------------------- Reporter: wolfkden | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stack upgrade | Operating System: MacOS X Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+--------------------------------- Wolfgangs-MacBook-Air:~ wolf$ stack upgrade Fetched package index. Populated index cache. stack-1.4.0: download Downloaded lts-6.25 build plan. Caching build plan Preparing to install GHC to an isolated location. This will not interfere with any system-level installation. Downloaded ghc-7.10.3. Installed GHC. [1 of 1] Compiling Main ( /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack68242/Setup.hs, /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack68242/Setup.o ) Linking /Users/wolf/.stack/setup-exe-cache/x86_64-osx/tmp-setup-Simple- Cabal-1.22.5.0-ghc-7.10.3 ... HUnit-1.3.1.2: download annotated-wl-pprint-0.7.0: download Cabal-1.24.2.0: download annotated-wl-pprint-0.7.0: configure SHA-1.6.4.2: download annotated-wl-pprint-0.7.0: build HUnit-1.3.1.2: configure HUnit-1.3.1.2: build Cabal-1.24.2.0: configure Cabal-1.24.2.0: build SHA-1.6.4.2: configure SHA-1.6.4.2: build annotated-wl-pprint-0.7.0: copy/register ansi-terminal-0.6.2.3: download ansi-terminal-0.6.2.3: configure ansi-terminal-0.6.2.3: build HUnit-1.3.1.2: copy/register auto-update-0.1.4: download auto-update-0.1.4: configure auto-update-0.1.4: build auto-update-0.1.4: copy/register ansi-terminal-0.6.2.3: copy/register base-compat-0.9.1: download base-compat-0.9.1: configure ansi-wl-pprint-0.6.7.3: download base-compat-0.9.1: build ansi-wl-pprint-0.6.7.3: configure ansi-wl-pprint-0.6.7.3: build ansi-wl-pprint-0.6.7.3: copy/register base-orphans-0.5.4: download base-compat-0.9.1: copy/register base-orphans-0.5.4: configure base16-bytestring-0.1.1.6: download base-orphans-0.5.4: build base16-bytestring-0.1.1.6: configure base16-bytestring-0.1.1.6: build base16-bytestring-0.1.1.6: copy/register base64-bytestring-1.0.0.1: configure base64-bytestring-1.0.0.1: build base64-bytestring-1.0.0.1: copy/register byteable-0.1.1: download byteable-0.1.1: configure byteable-0.1.1: build byteable-0.1.1: copy/register bytestring-builder-0.10.6.0.0: configure bytestring-builder-0.10.6.0.0: build bytestring-builder-0.10.6.0.0: copy/register clock-0.7.2: download clock-0.7.2: configure clock-0.7.2: build clock-0.7.2: copy/register cryptohash-sha256-0.11.100.1: download cryptohash-sha256-0.11.100.1: configure cryptohash-sha256-0.11.100.1: build base-orphans-0.5.4: copy/register data-default-class-0.0.1: configure data-default-class-0.0.1: build cryptohash-sha256-0.11.100.1: copy/register data-default-class-0.0.1: copy/register dlist-0.7.1.2: configure digest-0.0.1.2: download dlist-0.7.1.2: build digest-0.0.1.2: configure digest-0.0.1.2: build dlist-0.7.1.2: copy/register digest-0.0.1.2: copy/register easy-file-0.2.1: download ed25519-0.0.5.0: download easy-file-0.2.1: configure easy-file-0.2.1: build ed25519-0.0.5.0: configure ed25519-0.0.5.0: build easy-file-0.2.1: copy/register extra-1.4.10: download extra-1.4.10: configure extra-1.4.10: build ed25519-0.0.5.0: copy/register extra-1.4.10: copy/register file-embed-0.0.10: download file-embed-0.0.10: configure fail-4.9.0.0: download file-embed-0.0.10: build fail-4.9.0.0: configure fail-4.9.0.0: build fail-4.9.0.0: copy/register cereal-0.5.2.0: download file-embed-0.0.10: copy/register cereal-0.5.2.0: configure filelock-0.1.0.1: download cereal-0.5.2.0: build filelock-0.1.0.1: configure filelock-0.1.0.1: build filelock-0.1.0.1: copy/register generic-deriving-1.10.5: download generic-deriving-1.10.5: configure generic-deriving-1.10.5: build cereal-0.5.2.0: copy/register generics-sop-0.2.2.0: download generics-sop-0.2.2.0: configure generics-sop-0.2.2.0: build generic-deriving-1.10.5: copy/register gitrev-1.2.0: download gitrev-1.2.0: configure gitrev-1.2.0: build gitrev-1.2.0: copy/register hourglass-0.2.10: download hourglass-0.2.10: configure hourglass-0.2.10: build hourglass-0.2.10: copy/register hspec-discover-2.2.4: download hspec-discover-2.2.4: configure hspec-discover-2.2.4: build hspec-discover-2.2.4: copy/register hspec-expectations-0.7.2: download hspec-expectations-0.7.2: configure hspec-expectations-0.7.2: build hspec-expectations-0.7.2: copy/register ieee754-0.7.9: download ieee754-0.7.9: configure ieee754-0.7.9: build ieee754-0.7.9: copy/register memory-0.13: download memory-0.13: configure memory-0.13: build SHA-1.6.4.2: copy/register microlens-0.4.7.0: download microlens-0.4.7.0: configure microlens-0.4.7.0: build microlens-0.4.7.0: copy/register generics-sop-0.2.2.0: copy/register monad-loops-0.4.3: configure memory-0.13: copy/register monad-loops-0.4.3: build mtl-2.2.1: configure asn1-types-0.3.2: download mtl-2.2.1: build asn1-types-0.3.2: configure asn1-types-0.3.2: build monad-loops-0.4.3: copy/register cryptonite-0.19: download cryptonite-0.19: configure cryptonite-0.19: build mtl-2.2.1: copy/register asn1-types-0.3.2: copy/register logict-0.6.0.2: download logict-0.6.0.2: configure asn1-encoding-0.9.4: download logict-0.6.0.2: build asn1-encoding-0.9.4: configure asn1-encoding-0.9.4: build logict-0.6.0.2: copy/register nats-1.1.1: download nats-1.1.1: configure nats-1.1.1: build nats-1.1.1: copy/register network-2.6.3.1: download asn1-encoding-0.9.4: copy/register network-2.6.3.1: configure asn1-parse-0.9.4: download network-2.6.3.1: build asn1-parse-0.9.4: configure asn1-parse-0.9.4: build asn1-parse-0.9.4: copy/register old-locale-1.0.0.7: configure old-locale-1.0.0.7: build old-locale-1.0.0.7: copy/register old-time-1.1.0.3: configure old-time-1.1.0.3: build network-2.6.3.1: copy/register open-browser-0.2.1.0: download open-browser-0.2.1.0: configure open-browser-0.2.1.0: build old-time-1.1.0.3: copy/register patience-0.1.1: download patience-0.1.1: configure open-browser-0.2.1.0: copy/register patience-0.1.1: build pem-0.2.2: download pem-0.2.2: configure pem-0.2.2: build patience-0.1.1: copy/register pem-0.2.2: copy/register pid1-0.1.0.0: download pid1-0.1.0.0: configure prelude-extras-0.4.0.3: download pid1-0.1.0.0: build prelude-extras-0.4.0.3: configure prelude-extras-0.4.0.3: build pid1-0.1.0.0: copy/register primitive-0.6.1.0: configure primitive-0.6.1.0: build prelude-extras-0.4.0.3: copy/register random-1.1: configure random-1.1: build primitive-0.6.1.0: copy/register regex-applicative-0.3.3: download regex-applicative-0.3.3: configure regex-applicative-0.3.3: build regex-applicative-0.3.3: copy/register random-1.1: copy/register safe-0.3.10: download safe-0.3.10: configure safe-0.3.10: build setenv-0.1.1.3: download setenv-0.1.1.3: configure setenv-0.1.1.3: build setenv-0.1.1.3: copy/register silently-1.2.5: configure silently-1.2.5: build safe-0.3.10: copy/register silently-1.2.5: copy/register smallcheck-1.1.1: download smallcheck-1.1.1: configure socks-0.5.5: download smallcheck-1.1.1: build socks-0.5.5: configure socks-0.5.5: build smallcheck-1.1.1: copy/register split-0.2.3.1: download split-0.2.3.1: configure split-0.2.3.1: build split-0.2.3.1: copy/register stm-2.4.4.1: download stm-2.4.4.1: configure stm-2.4.4.1: build socks-0.5.5: copy/register syb-0.6: download syb-0.6: configure stm-2.4.4.1: copy/register syb-0.6: build StateVar-1.1.0.4: download StateVar-1.1.0.4: configure StateVar-1.1.0.4: build StateVar-1.1.0.4: copy/register async-2.1.0: download async-2.1.0: configure async-2.1.0: build syb-0.6: copy/register stm-chans-3.0.0.4: configure async-2.1.0: copy/register tagged-0.8.4: download stm-chans-3.0.0.4: build tagged-0.8.4: configure tagged-0.8.4: build stm-chans-3.0.0.4: copy/register tar-0.5.0.3: download tar-0.5.0.3: configure tagged-0.8.4: copy/register tar-0.5.0.3: build text-1.2.2.1: download cryptonite-0.19: copy/register text-1.2.2.1: configure text-1.2.2.1: build cryptohash-0.11.9: download cryptohash-0.11.9: configure cryptohash-0.11.9: build cryptohash-0.11.9: copy/register tf-random-0.5: download tf-random-0.5: configure tf-random-0.5: build tar-0.5.0.3: copy/register th-expand-syns-0.4.1.0: download th-expand-syns-0.4.1.0: configure th-expand-syns-0.4.1.0: build tf-random-0.5: copy/register QuickCheck-2.8.2: download QuickCheck-2.8.2: configure th-expand-syns-0.4.1.0: copy/register QuickCheck-2.8.2: build th-lift-0.7.6: download th-lift-0.7.6: configure th-lift-0.7.6: build th-lift-0.7.6: copy/register th-reify-many-0.1.6: download th-reify-many-0.1.6: configure th-reify-many-0.1.6: build th-reify-many-0.1.6: copy/register time-locale-compat-0.1.1.3: download time-locale-compat-0.1.1.3: configure time-locale-compat-0.1.1.3: build time-locale-compat-0.1.1.3: copy/register transformers-compat-0.4.0.4: configure transformers-compat-0.4.0.4: build transformers-compat-0.4.0.4: copy/register MonadRandom-0.4.2.3: download MonadRandom-0.4.2.3: configure MonadRandom-0.4.2.3: build MonadRandom-0.4.2.3: copy/register distributive-0.5.0.2: download distributive-0.5.0.2: configure distributive-0.5.0.2: build QuickCheck-2.8.2: copy/register distributive-0.5.0.2: copy/register exceptions-0.8.3: download exceptions-0.8.3: configure microlens-mtl-0.1.10.0: download exceptions-0.8.3: build microlens-mtl-0.1.10.0: configure microlens-mtl-0.1.10.0: build exceptions-0.8.3: copy/register microlens-mtl-0.1.10.0: copy/register mmorph-1.0.6: download mmorph-1.0.6: configure quickcheck-io-0.1.4: download mmorph-1.0.6: build quickcheck-io-0.1.4: configure quickcheck-io-0.1.4: build quickcheck-io-0.1.4: copy/register mmorph-1.0.6: copy/register hspec-core-2.2.4: download hspec-core-2.2.4: configure retry-0.7.4.1: download hspec-core-2.2.4: build retry-0.7.4.1: configure retry-0.7.4.1: build retry-0.7.4.1: copy/register safe-exceptions-0.1.4.0: download safe-exceptions-0.1.4.0: configure safe-exceptions-0.1.4.0: build safe-exceptions-0.1.4.0: copy/register temporary-1.2.0.4: download temporary-1.2.0.4: configure temporary-1.2.0.4: build hspec-core-2.2.4: copy/register temporary-1.2.0.4: copy/register hspec-2.2.4: download hspec-2.2.4: configure hspec-smallcheck-0.4.1: download hspec-2.2.4: build hspec-smallcheck-0.4.1: configure hspec-smallcheck-0.4.1: build hspec-smallcheck-0.4.1: copy/register hspec-2.2.4: copy/register transformers-base-0.4.4: configure unexceptionalio-0.3.0: download transformers-base-0.4.4: build unexceptionalio-0.3.0: configure unexceptionalio-0.3.0: build transformers-base-0.4.4: copy/register unexceptionalio-0.3.0: copy/register monad-control-1.0.1.0: download monad-control-1.0.1.0: configure errors-2.1.2: download monad-control-1.0.1.0: build errors-2.1.2: configure errors-2.1.2: build monad-control-1.0.1.0: copy/register errors-2.1.2: copy/register lifted-base-0.2.3.8: download lifted-base-0.2.3.8: configure unix-compat-0.4.1.4: download lifted-base-0.2.3.8: build unix-compat-0.4.1.4: configure unix-compat-0.4.1.4: build lifted-base-0.2.3.8: copy/register unix-compat-0.4.1.4: copy/register enclosed-exceptions-1.0.2: download enclosed-exceptions-1.0.2: configure resourcet-1.1.8.1: download enclosed-exceptions-1.0.2: build resourcet-1.1.8.1: configure resourcet-1.1.8.1: build enclosed-exceptions-1.0.2: copy/register unix-time-0.3.7: download unix-time-0.3.7: configure resourcet-1.1.8.1: copy/register conduit-1.2.8: download unix-time-0.3.7: build conduit-1.2.8: configure conduit-1.2.8: build unix-time-0.3.7: copy/register utf8-string-1.0.1.1: download utf8-string-1.0.1.1: configure utf8-string-1.0.1.1: build utf8-string-1.0.1.1: copy/register vector-0.11.0.0: download vector-0.11.0.0: configure vector-0.11.0.0: build conduit-1.2.8: copy/register x509-1.6.4: download x509-1.6.4: configure x509-1.6.4: build Cabal-1.24.2.0: copy/register zlib-0.6.1.2: download zlib-0.6.1.2: configure text-1.2.2.1: copy/register zlib-0.6.1.2: build blaze-builder-0.4.0.2: download blaze-builder-0.4.0.2: configure blaze-builder-0.4.0.2: build x509-1.6.4: copy/register fast-logger-2.4.7: download fast-logger-2.4.7: configure fast-logger-2.4.7: build blaze-builder-0.4.0.2: copy/register blaze-markup-0.7.1.0: download blaze-markup-0.7.1.0: configure fast-logger-2.4.7: copy/register blaze-markup-0.7.1.0: build cookie-0.4.2.1: download cookie-0.4.2.1: configure zlib-0.6.1.2: copy/register cookie-0.4.2.1: build hashable-1.2.4.0: download hashable-1.2.4.0: configure hashable-1.2.4.0: build cookie-0.4.2.1: copy/register hastache-0.6.1: download hastache-0.6.1: configure hashable-1.2.4.0: copy/register hastache-0.6.1: build constraints-0.8: download constraints-0.8: configure constraints-0.8: build blaze-markup-0.7.1.0: copy/register blaze-html-0.8.1.2: download blaze-html-0.8.1.2: configure constraints-0.8: copy/register blaze-html-0.8.1.2: build hfsevents-0.1.6: download hfsevents-0.1.6: configure hfsevents-0.1.6: build hastache-0.6.1: copy/register hfsevents-0.1.6: copy/register http-api-data-0.2.4: download http-api-data-0.2.4: configure fsnotify-0.2.1: download http-api-data-0.2.4: build fsnotify-0.2.1: configure fsnotify-0.2.1: build fsnotify-0.2.1: copy/register lifted-async-0.9.0: download lifted-async-0.9.0: configure lifted-async-0.9.0: build lifted-async-0.9.0: copy/register mime-types-0.1.0.7: download mime-types-0.1.0.7: configure mime-types-0.1.0.7: build http-api-data-0.2.4: copy/register monad-unlift-0.2.0: download monad-unlift-0.2.0: configure blaze-html-0.8.1.2: copy/register monad-unlift-0.2.0: build parsec-3.1.11: download monad-unlift-0.2.0: copy/register parsec-3.1.11: configure parsec-3.1.11: build path-pieces-0.2.1: configure path-pieces-0.2.1: build path-pieces-0.2.1: copy/register mime-types-0.1.0.7: copy/register regex-applicative-text-0.1.0.1: download regex-applicative-text-0.1.0.1: configure store-core-0.3: download regex-applicative-text-0.1.0.1: build store-core-0.3: configure store-core-0.3: build regex-applicative-text-0.1.0.1: copy/register streaming-commons-0.1.16: download streaming-commons-0.1.16: configure streaming-commons-0.1.16: build store-core-0.3: copy/register system-filepath-0.4.13.4: download system-filepath-0.4.13.4: configure system-filepath-0.4.13.4: build parsec-3.1.11: copy/register network-uri-2.6.1.0: download network-uri-2.6.1.0: configure network-uri-2.6.1.0: build streaming-commons-0.1.16: copy/register system-filepath-0.4.13.4: copy/register text-binary-0.2.1.1: download text-binary-0.2.1.1: configure text-binary-0.2.1.1: build network-uri-2.6.1.0: copy/register system-fileio-0.3.16.3: download system-fileio-0.3.16.3: configure text-binary-0.2.1.1: copy/register hackage-security-0.5.2.2: download system-fileio-0.3.16.3: build hackage-security-0.5.2.2: configure text-metrics-0.1.0: download hackage-security-0.5.2.2: build text-metrics-0.1.0: configure text-metrics-0.1.0: build system-fileio-0.3.16.3: copy/register text-metrics-0.1.0: copy/register unicode-transforms-0.1.0.1: download unordered-containers-0.2.7.1: download unicode-transforms-0.1.0.1: configure unicode-transforms-0.1.0.1: build unordered-containers-0.2.7.1: configure unordered-containers-0.2.7.1: build unicode-transforms-0.1.0.1: copy/register x509-store-1.6.2: download x509-store-1.6.2: configure x509-store-1.6.2: build x509-store-1.6.2: copy/register x509-system-1.6.4: download x509-system-1.6.4: configure x509-system-1.6.4: build x509-system-1.6.4: copy/register x509-validation-1.6.5: download x509-validation-1.6.5: configure x509-validation-1.6.5: build x509-validation-1.6.5: copy/register tls-1.3.8: download tls-1.3.8: configure tls-1.3.8: build hackage-security-0.5.2.2: copy/register zip-archive-0.2.3.7: download zip-archive-0.2.3.7: configure vector-0.11.0.0: copy/register mwc-random-0.13.4.0: download zip-archive-0.2.3.7: build mwc-random-0.13.4.0: configure mwc-random-0.13.4.0: build zip-archive-0.2.3.7: copy/register resource-pool-0.2.3.2: configure resource-pool-0.2.3.2: build unordered-containers-0.2.7.1: copy/register scientific-0.3.4.9: download scientific-0.3.4.9: configure resource-pool-0.2.3.2: copy/register semigroups-0.18.2: download scientific-0.3.4.9: build semigroups-0.18.2: configure semigroups-0.18.2: build scientific-0.3.4.9: copy/register th-lift-instances-0.1.10: download th-lift-instances-0.1.10: configure th-lift-instances-0.1.10: build th-lift-instances-0.1.10: copy/register th-orphans-0.13.1: download th-orphans-0.13.1: configure th-orphans-0.13.1: build semigroups-0.18.2: copy/register Glob-0.7.12: download Glob-0.7.12: configure Glob-0.7.12: build th-orphans-0.13.1: copy/register attoparsec-0.13.1.0: download attoparsec-0.13.1.0: configure attoparsec-0.13.1.0: build tls-1.3.8: copy/register case-insensitive-1.2.0.7: download case-insensitive-1.2.0.7: configure Glob-0.7.12: copy/register case-insensitive-1.2.0.7: build connection-0.2.6: download connection-0.2.6: configure connection-0.2.6: build case-insensitive-1.2.0.7: copy/register dlist-instances-0.1.1.1: download dlist-instances-0.1.1.1: configure connection-0.2.6: copy/register dlist-instances-0.1.1.1: build http-types-0.9.1: download http-types-0.9.1: configure dlist-instances-0.1.1.1: copy/register optparse-applicative-0.13.0.0: download http-types-0.9.1: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build http-types-0.9.1: copy/register http-client-0.5.3.3: download http-client-0.5.3.3: configure http-client-0.5.3.3: build optparse-applicative-0.13.0.0: copy/register th-utilities-0.2.0.1: download th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build th-utilities-0.2.0.1: copy/register vector-binary-instances-0.2.3.2: download vector-binary-instances-0.2.3.2: configure vector-binary-instances-0.2.3.2: build http-client-0.5.3.3: copy/register http-client-tls-0.3.4: download http-client-tls-0.3.4: configure vector-binary-instances-0.2.3.2: copy/register http-client-tls-0.3.4: build void-0.7.1: download void-0.7.1: configure void-0.7.1: build void-0.7.1: copy/register http-client-tls-0.3.4: copy/register contravariant-1.4: download contravariant-1.4: configure zlib-bindings-0.1.1.5: download contravariant-1.4: build zlib-bindings-0.1.1.5: configure zlib-bindings-0.1.1.5: build zlib-bindings-0.1.1.5: copy/register contravariant-1.4: copy/register comonad-4.2.7.2: download comonad-4.2.7.2: configure comonad-4.2.7.2: build comonad-4.2.7.2: copy/register bifunctors-5.2: download bifunctors-5.2: configure bifunctors-5.2: build attoparsec-0.13.1.0: copy/register aeson-1.0.2.1: download conduit-extra-1.1.14: download conduit-extra-1.1.14: configure conduit-extra-1.1.14: build aeson-1.0.2.1: configure aeson-1.0.2.1: build mwc-random-0.13.4.0: copy/register hit-0.6.3: download hit-0.6.3: configure hit-0.6.3: build bifunctors-5.2: copy/register conduit-extra-1.1.14: copy/register profunctors-5.2: download profunctors-5.2: configure cryptonite-conduit-0.1: download profunctors-5.2: build cryptonite-conduit-0.1: configure cryptonite-conduit-0.1: build cryptonite-conduit-0.1: copy/register monad-logger-0.3.20.1: download monad-logger-0.3.20.1: configure monad-logger-0.3.20.1: build monad-logger-0.3.20.1: copy/register project-template-0.2.0: download project-template-0.2.0: configure project-template-0.2.0: build profunctors-5.2: copy/register semigroupoids-5.0.1: download semigroupoids-5.0.1: configure project-template-0.2.0: copy/register vector-algorithms-0.7.0.1: download semigroupoids-5.0.1: build vector-algorithms-0.7.0.1: configure vector-algorithms-0.7.0.1: build hit-0.6.3: copy/register semigroupoids-5.0.1: copy/register free-4.12.4: download free-4.12.4: configure free-4.12.4: build free-4.12.4: copy/register either-4.4.1.1: download adjunctions-4.3: download either-4.4.1.1: configure either-4.4.1.1: build adjunctions-4.3: configure adjunctions-4.3: build either-4.4.1.1: copy/register keys-3.11: download keys-3.11: configure keys-3.11: build adjunctions-4.3: copy/register kan-extensions-4.2.3: download kan-extensions-4.2.3: configure kan-extensions-4.2.3: build keys-3.11: copy/register optparse-simple-0.0.3: download optparse-simple-0.0.3: configure optparse-simple-0.0.3: build kan-extensions-4.2.3: copy/register optparse-simple-0.0.3: copy/register pointed-4.2.0.2: download pointed-4.2.0.2: configure pointed-4.2.0.2: build pointed-4.2.0.2: copy/register vector-instances-3.3.1: download vector-instances-3.3.1: configure vector-instances-3.3.1: build vector-instances-3.3.1: copy/register vector-algorithms-0.7.0.1: copy/register mono-traversable-0.10.2: download mono-traversable-0.10.2: configure mono-traversable-0.10.2: build aeson-1.0.2.1: copy/register http-conduit-2.2.3: download binary-tagged-0.1.4.1: download binary-tagged-0.1.4.1: configure aeson-compat-0.3.6: download binary-tagged-0.1.4.1: build http-conduit-2.2.3: configure http-conduit-2.2.3: build aeson-compat-0.3.6: configure aeson-compat-0.3.6: build http-conduit-2.2.3: copy/register aeson-compat-0.3.6: copy/register path-0.5.9: download path-0.5.9: configure persistent-2.6: download path-0.5.9: build persistent-2.6: configure binary-tagged-0.1.4.1: copy/register persistent-2.6: build yaml-0.8.20: download yaml-0.8.20: configure yaml-0.8.20: build path-0.5.9: copy/register path-io-1.1.0: download path-io-1.1.0: configure path-io-1.1.0: build path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.17.0: download hpack-0.17.0: configure hpack-0.17.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: download persistent-sqlite-2.6: download persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure persistent-sqlite-2.6: build hpack-0.17.0: copy/register mono-traversable-0.10.2: copy/register store-0.3: download store-0.3: configure store-0.3: build persistent-template-2.5.1.6: copy/register persistent-sqlite-2.6: copy/register store-0.3: copy/register stack-1.4.0: configure [1 of 1] Compiling Main ( /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/Setup.hs, /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.4.0... stack-1.4.0: build Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/ghc89392_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/ghc89392_0/libghc_68.dylib: malformed mach-o: load commands size (49264) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed all 185 actions. -- While building package stack-1.4.0 using: /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Wolfgangs-MacBook-Air:~ wolf$ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 00:46:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 00:46:02 -0000 Subject: [GHC] #13447: error on MacOS Sierra upgrading stack In-Reply-To: <047.6ba3c83fc73a5c6771edcf78f4ed56cb@haskell.org> References: <047.6ba3c83fc73a5c6771edcf78f4ed56cb@haskell.org> Message-ID: <062.610a54bbd72b329a8b842cc514235929@haskell.org> #13447: error on MacOS Sierra upgrading stack ---------------------------------+------------------------------------- Reporter: wolfkden | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: stack upgrade Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------------- Changes (by RyanGlScott): * 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 Sun Mar 19 00:55:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 00:55:45 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.9efdd2388783399f8132a011d949d1e4@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D3364 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Rufflewind): * differential: => D3364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 01:01:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 01:01:10 -0000 Subject: [GHC] #13448: Make HPC use an RTS option to select the tix file Message-ID: <045.1617dd0f725b9d27c0e7ca3988277c6b@haskell.org> #13448: Make HPC use an RTS option to select the tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Code Coverage | 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: -------------------------------------+------------------------------------- Phab:D3357 will document the currently-undocumented `HPCTIXFILE` environment variable. I think, however, that we really should change how that's controlled. Make it an RTS option like any other, which can be controlled using `with-rtsopts`, `+RTS`, or the `GHCRTS` environment variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 01:04:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 01:04:44 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.af4bb856db8414e61b32e22d075bdff1@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3364 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D3364 => Phab:D3364 Comment: Impressive turnaround time, Rufflewind! Many thanks for your continued work on this effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 01:07:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 01:07:19 -0000 Subject: [GHC] #13449: Multiple pattern synonym declarations for one signature Message-ID: <051.2e620c70743ab323e5de4b97be818010@haskell.org> #13449: Multiple pattern synonym declarations for one signature -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I'm not sure if I've seen this before. I want to be able to write {{{#!hs data Ty a where TBool :: Ty Bool data Exp a where Lit :: Ty a -> a -> Exp a pattern Fls, Tru :: () => a ~ Bool => Exp a pattern Fls = Lit TBool False pattern Tru = Lit TBool False }}} instead of {{{#!hs pattern Fls :: () => a ~ Bool => Exp a pattern Fls = Lit TBool False pattern Tru :: () => a ~ Bool => Exp a pattern Tru = Lit TBool False }}} just as this is allowed {{{#!hs fls, tru :: Exp Bool fls = Lit TBool False tru = Lit TBool False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 01:11:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 01:11:40 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.ccef7090d1c64b802b7c92c28718a122@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 erikd): > I'm a little confused, is this supposed to be valid input Cmm? The `cast ` is my proposed extension to CMM. > It seems like the goal of adding this cast is to slip past Cmm's type checking, The CMM type checker seems fine with this, its CMM's linter than complains. > but as there actually is a well-typed way to do what you want in Cmm, There is? Please elaborate! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 02:42:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 02:42:50 -0000 Subject: [GHC] #13450: Better parse error for empy character literal Message-ID: <050.83e6f9a404a53c1bc5e7037bac0334a8@haskell.org> #13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Empty character literals give an obscure error message. As an example, this code: {{{#!hs example = foo : bar where foo = '' bar = "asdf" }}} gives the following error when loaded in GHCi: {{{ err.hs:4:6: parse error (possibly incorrect indentation or mismatched brackets) }}} This has affected me once, as a beginner. I've seen it affect a few other beginners, and the error message isn't very helpful to figuring out what's wrong. It would be nice if a better error message could be reported. If there's a parse error on `''`, then GHC could report something like: {{{ err.hs:3:11: parse error on `''`. Note: Character literals may not be empty. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 03:34:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 03:34:16 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.919465b3d4ed13e2d3c18bc006b1c222@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 rwbarton): Take any old function that calculates with `Double` like {{{#!hs f :: Double -> Double f x = x + 1 }}} and compile it with `-O -ddump-cmm`, and it will do things like {{{ cOz: _sOd::F64 = %MO_F_Add_W64(F64[R1 + 7], 1.0 :: W64); I64[Hp - 8] = GHC.Types.D#_con_info; F64[Hp] = _sOd::F64; R1 = Hp - 7; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} `F64[A]` is the way to denote the 64-bit floating point quantity at address `A`. So internally Cmm has a representation of exactly the construct you need already. I'm just not sure whether it is possible to write that construct in a `.cmm` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 03:49:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 03:49:33 -0000 Subject: [GHC] #13451: Bind implicit parameter in patterns Message-ID: <051.db400dc2cca3bd9a6a599c9f27d0cab0@haskell.org> #13451: Bind implicit parameter in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple ImplicitParams | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is there any reason why variables for `ImplicitParams` can't be bound in patterns, so you can write {{{#!hs data Exp = Val Int | Op Op Exp Exp data Op = Add | Mul data Protect where Protect :: (?op :: Op) => Protect protectOp :: Exp -> Maybe Protect protectOp (Op ?op _ _) = Just Protect protectOp _ = Nothing }}} instead of {{{#!hs protectOp :: Exp -> Maybe Protect protectOp (Op op _ _) = Just Protect where ?op = op protectOp _ = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 05:06:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 05:06:40 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.57ec2deb93f958d1c755a16a24bc6d0d@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 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 erikd): * status: new => closed * resolution: => invalid Comment: Ok, this works: {{{ stg_wordToFloatzh(W_ w) { D_ d; STK_CHK_P_LL(WDS(1), stg_wordToFloatzh, w); Sp(-1) = w; d = D_ [Sp(-1)]; return (d); } }}} Closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 05:52:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 05:52:09 -0000 Subject: [GHC] #12065: there is a way to override the .tix path with HPCTIXFILE In-Reply-To: <045.acf890da63effd264c753e4e22e0c6f2@haskell.org> References: <045.acf890da63effd264c753e4e22e0c6f2@haskell.org> Message-ID: <060.d39a2923cc5bebe212afabddb29bcc6b@haskell.org> #12065: there is a way to override the .tix path with HPCTIXFILE -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Code Coverage | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3357 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3357 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 06:00:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 06:00:34 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options (was: Recompiling with -fhpc flag added does nothing) In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.24e5cc108c9ff877900622ac72a964e2@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * type: bug => feature request * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 8.4.1 Old description: > When you recompile without modifiying any source code, nothing happens, > as expected. The file is already compiled, after all. If you then add the > -fhpc flag, it still doesn't recompile, even though it now should > generate .tix files. These files are now unexpectedly missing, until the > source files are modified or the .o and .hi files are deleted, and the > code is recompiled again with the -fhpc flag. > > reproduce: > 1. compile program > 2. compile program with -fhpc > note: missing .tix file > 3. delete .hi and .o files > 4. compile program with -fhpc > 5. success; .tix file is generated New description: When you recompile without modifying any source code, nothing happens, as expected. The file is already compiled, after all. If you then change compilation options, such as adding the `-fhpc` or `-O2` flag, it still doesn't recompile, even though the program might now be expected to behave or perform differently. Users can work around this using `-fforce-recomp`, but perhaps they shouldn't have to, or perhaps they should be warned that this may be necessary. One option might be to record "significant" compilation options in the `.hi` file, to determine whether they have changed in a way that suggests recompilation may be in order. -- Comment: The original ticket claimed this was a bug recompiling with `-fhpc`, but in fact this is the way GHC behaves with compilation option changes in general. I've taken the liberty of modifying the title and description and making this a feature request, because I think there's a reasonable feature request here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 06:05:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 06:05:58 -0000 Subject: [GHC] #13452: Lock .tix file Message-ID: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> #13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Code Coverage | 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 HPC documentation [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html #caveats-and-shortcomings-of-haskell-program-coverage warns] that > HPC does not attempt to lock the `.tix` file, so multiple concurrently running binaries in the same directory will exhibit a race condition. This sounds like something that shouldn't be too terribly hard to fix, once we determine exactly how we want to deal with contention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 06:06:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 06:06:21 -0000 Subject: [GHC] #13448: Make HPC use an RTS option to select the tix file In-Reply-To: <045.1617dd0f725b9d27c0e7ca3988277c6b@haskell.org> References: <045.1617dd0f725b9d27c0e7ca3988277c6b@haskell.org> Message-ID: <060.db938deb3cb34c8c75c9cf19bda7c924@haskell.org> #13448: Make HPC use an RTS option to select the tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Code Coverage | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 09:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 09:08:18 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.0346670ce830eae54c602873151d5c88@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 erikd): * status: closed => new * resolution: invalid => Comment: Nope, that doesn't work, it segfaults. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 09:27:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 09:27:03 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.0aea9fe1303655d6a83fab6a7cfbdadb@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 erikd): Thinking about it some more, I can't see how CMM could represent a casting operation without the `CmmCast` expression I added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 11:17:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 11:17:45 -0000 Subject: [GHC] #13453: Seemingly can't mix ImplicitParams in where clauses Message-ID: <051.bccff68ec9bff91f7ffb698077162b7c@haskell.org> #13453: Seemingly can't mix ImplicitParams in where clauses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple ImplicitParams | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These are fine {{{#!hs v = () where a = True b = 'a' }}} {{{#!hs v = () where ?a = True ?b = 'a' }}} but the moment one of them is an `ImplicitParams` it fails to parse {{{#!hs -- tAMA.hs:9:3-4: error: Parse error in pattern: ?b -- Compilation failed. v = () where a = True ?b = 'a' -- tAMA.hs:9:3: error: parse error on input ‘b’ -- Compilation failed. v = () where ?a = True b = 'a' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 11:18:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 11:18:34 -0000 Subject: [GHC] #13453: Seemingly can't mix ImplicitParams in where clauses In-Reply-To: <051.bccff68ec9bff91f7ffb698077162b7c@haskell.org> References: <051.bccff68ec9bff91f7ffb698077162b7c@haskell.org> Message-ID: <066.fff9ebd2897b96aacc453a104c8de1d5@haskell.org> #13453: Seemingly can't mix ImplicitParams in where clauses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | ImplicitParams 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: > These are fine > > {{{#!hs > v = () where > a = True > b = 'a' > }}} > > {{{#!hs > v = () where > ?a = True > ?b = 'a' > }}} > > but the moment one of them is an `ImplicitParams` it fails to parse > > {{{#!hs > -- tAMA.hs:9:3-4: error: Parse error in pattern: ?b > -- Compilation failed. > v = () where > a = True > ?b = 'a' > > -- tAMA.hs:9:3: error: parse error on input ‘b’ > -- Compilation failed. > v = () where > ?a = True > b = 'a' > }}} New description: These are fine {{{#!hs v = () where a = True b = 'a' }}} {{{#!hs v = () where ?a = True ?b = 'a' }}} but the moment one of them is an `ImplicitParams` variable '''as well''' as a regular one, it fails to parse {{{#!hs -- tAMA.hs:9:3-4: error: Parse error in pattern: ?b -- Compilation failed. v = () where a = True ?b = 'a' -- tAMA.hs:9:3: error: parse error on input ‘b’ -- Compilation failed. v = () where ?a = True b = 'a' }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 11:23:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 11:23:11 -0000 Subject: [GHC] #13451: Bind implicit parameter in patterns In-Reply-To: <051.db400dc2cca3bd9a6a599c9f27d0cab0@haskell.org> References: <051.db400dc2cca3bd9a6a599c9f27d0cab0@haskell.org> Message-ID: <066.e3fb540b920d79afd820cffd08fc2126@haskell.org> #13451: Bind implicit parameter in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | ImplicitParams Operating System: 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): Also applies here maybe, {{{#!hs greet :: (?name :: String) => String greet = "hi " ++ ?name -- t1QY.hs:12:4-8: error: Parse error in pattern: ?name -- Compilation failed. a :: String a = greet where (?name, False) = ("Iceland_jack", True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 12:14:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 12:14:07 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.ce016183613393b4938fb5a362db0d2a@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: bgamari => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 12:48:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 12:48:33 -0000 Subject: [GHC] #13449: Multiple pattern synonym declarations for one signature In-Reply-To: <051.2e620c70743ab323e5de4b97be818010@haskell.org> References: <051.2e620c70743ab323e5de4b97be818010@haskell.org> Message-ID: <066.2dbcb7c764207c884daeb035f0ad1b8b@haskell.org> #13449: Multiple pattern synonym declarations for one signature -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11727 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11727 Comment: This is a duplicate of #11727, which is fixed in GHC 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 12:53:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 12:53:12 -0000 Subject: [GHC] #13454: Operators not allowed as fields in Record Pattern Synonyms Message-ID: <051.27085269b67e022e580ad0a1da270800@haskell.org> #13454: Operators not allowed as fields in Record Pattern Synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I want to write the following record pattern synonym {{{#!hs pattern MkOp :: Op -> Exp -> Exp -> Exp pattern MkOp {(·), a, b} <- (splitOp -> Just ((·), a, b)) where MkOp (·) a b = a · b }}} given this code {{{#!hs data Exp = Val Int | Add Exp Exp | Mul Exp Exp deriving Show type Op = Exp -> Exp -> Exp splitOp :: Exp -> Maybe (Op, Exp, Exp) splitOp (Add a b) = Just (Add, a, b) splitOp (Mul a b) = Just (Mul, a, b) splitOp _ = Nothing }}} It works fine if `(·)` is replaced by `operator`. Fields of regular data types works just fine: {{{#!hs data F a = F { (·) :: a -> a -> a, x :: a, y :: a } f F{(·), x, y} = x·y g F{..} = x·y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 13:22:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 13:22:17 -0000 Subject: [GHC] #13455: GHCi crash GHC with creation of a "crash dump file" in Windows Message-ID: <044.f149bf4e5b33fbf125319c782a924e93@haskell.org> #13455: GHCi crash GHC with creation of a "crash dump file" in Windows --------------------------------+---------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- Hi,\\ I repeated this several times in order and GHC crash after typing the command {{{:r}}} several times in GHCi\\ If the two files are taken separately there is no crash\\ file {{{test1.hs}}} {{{ main :: IO () main = do { putStr "hello"; x <- getChar; putStr "x = "; print x; } }}} file {{{test2.hs}}} {{{ putStr :: String -> IO () putStr [] = return () putStr (x:xs) = do putChar x putChar '\n' putStrLn :: String -> IO () putStrLn xs = do putStr xs putChar '\n' }}} 1- open GHCi\\ 2- {{{:load}}} test1.hs\\ 3- run main\\ 4- {{{:load}}} test2.hs\\ 5- an error message comes then type {{{:r}}}\\ 6- keep trying {{{:r}}} until the crash of GHC. usually at the end of the third time.\\ 7- see the Windows message to the screen.\\ a "crash dump file" is created. It say:\\ exception code 0xC0000096\\ process name: ghc.exe: C:\ghc-8.0.2\bin\ghc.exe\\ information: the thread tried to execute a statement that the operation is not allowed in the current mode of the computer\\ modules name:\\ ghc.exe, ntdll.dll, kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, rpcrt4.dll, msvcrt.dll, shell32.dll, shlwapi.dll, wsock32.dll, ws2_32.dll, nsi.dll, imm32.dll, msctf.dll, lpk.dll, usp10.dll, comctl32.dll, ole32.dll, userenv.dll, secur32.dll, apphelp.dll\\ a particularly pointed to by Windows file is msvcrt.dll\\ Hope this help -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 14:20:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 14:20:42 -0000 Subject: [GHC] #13453: Seemingly can't mix ImplicitParams in where clauses In-Reply-To: <051.bccff68ec9bff91f7ffb698077162b7c@haskell.org> References: <051.bccff68ec9bff91f7ffb698077162b7c@haskell.org> Message-ID: <066.85f78bfe8fea5cf51cfeb1703b25f0f8@haskell.org> #13453: Seemingly can't mix ImplicitParams in where clauses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: invalid | ImplicitParams Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: As documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 14:25:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 14:25:57 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.39b21291e0e3cfaa6f9ce91556d4f7dd@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | 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 rwbarton): It should be {{{ d = D_[Sp - WDS(1)]; }}} `Sp(-1)` is already a memory access ("the value at `Sp - WDS(1)`"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 15:18:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 15:18:40 -0000 Subject: [GHC] #13387: Segfault when profiling on OS X In-Reply-To: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> References: <049.65db446b5244d78a1fbacaac0b4705ed@haskell.org> Message-ID: <064.fdacf27cf7c6c5bb1e634ace40782977@haskell.org> #13387: Segfault when profiling on OS X -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: high | 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: #13433 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #13433 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 15:48:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 15:48:36 -0000 Subject: [GHC] #13449: Multiple pattern synonym declarations for one signature In-Reply-To: <051.2e620c70743ab323e5de4b97be818010@haskell.org> References: <051.2e620c70743ab323e5de4b97be818010@haskell.org> Message-ID: <066.f99eec715d1080d72af8591936339ae6@haskell.org> #13449: Multiple pattern synonym declarations for one signature -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11727 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Cheers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 16:01:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 16:01:32 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.0139a631941d7ec5bf457a9194331448@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Note that we already do something along these lines. See the `FlagChecker` module. However, it seems quite clear that the flags accounted for here are woefully incomplete. Patches welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 16:03:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 16:03:32 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.048cd69b0aee1c2d45643539d319ce67@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: In fact, I believe this is an outright duplicate of #10923. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 16:41:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 16:41:11 -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.62a2e862d5854654eb4ac5d26fa3d822@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Okay, found the REAL culprit. It's embarrassingly simple, and not at all what I had been looking for. Running `ghc` with `-dcore-lint -v` and grepping for `Core Linted result` revealed the issue, this new line in `simplifyPgmIO`: {{{#!diff Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "Occurrence analysis" (pprCoreBindings tagged_binds); + lintPassResult hsc_env CoreOccurAnal tagged_binds; -- Get any new rules, and extend the rule base -- See Note [Overall plumbing for rules] in Rules.hs }}} We now run Core Lint twice per simplifier iteration, which in my sample program amounted to running Core Lint 50% more times overall. That's rather expensive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 16:54:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 16:54:36 -0000 Subject: [GHC] #13442: Add a coercion/cast operator to CMM In-Reply-To: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> References: <044.016a5dad5104a6cf0119a0a912907080@haskell.org> Message-ID: <059.c97e7949bef7959452f67baf4abd91f3@haskell.org> #13442: Add a coercion/cast operator to CMM -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 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 rwbarton): * status: new => closed * resolution: => invalid Comment: Replying to [comment:10 erikd]: > Thinking about it some more, I can't see how CMM could represent a casting operation without the `CmmCast` expression I added. Let's please not add a generic casting operation to Cmm. We already have a variety of specific conversions; and the whole point here is that it is not easy to implement the specific conversion that you need (as in ticket:4092#comment:9). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 16:54:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 16:54:48 -0000 Subject: [GHC] #11796: Warn about unwanted instances in a modular way In-Reply-To: <046.91e31cdcc0e901faacb417cf9f6c616f@haskell.org> References: <046.91e31cdcc0e901faacb417cf9f6c616f@haskell.org> Message-ID: <061.43a5b62ed08ec085a7794c6aafd5867f@haskell.org> #11796: Warn about unwanted instances in a modular way -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: feature request | 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: #11219 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bergmark): * cc: bergmark (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 17:01:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 17:01:38 -0000 Subject: [GHC] #11796: Warn about unwanted instances in a modular way In-Reply-To: <046.91e31cdcc0e901faacb417cf9f6c616f@haskell.org> References: <046.91e31cdcc0e901faacb417cf9f6c616f@haskell.org> Message-ID: <061.dc07b3e8adb08e357f44ce46db8cff09@haskell.org> #11796: Warn about unwanted instances in a modular way -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: feature request | 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: #11219 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bergmark): Another notorious instance is `Show (a -> b)` from `base:Text.Show.Functions`. I ran across a bug where this instance was used by mistake because one of my libraries used it thus propagating the instance down to me. My solution was to remove this import from the offending library and also adding an `Unsatisfiable => Show (a -> b)` instance locally to prevent it from being used in the future. The latter does course not scale and shouldn't be used in libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 17:32:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 17:32:09 -0000 Subject: [GHC] #13456: GHCi run commands that are not documented in Users Guide Documentation Message-ID: <044.bd64a38557199b0514ccf5021317207d@haskell.org> #13456: GHCi run commands that are not documented in Users Guide Documentation -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, GHCi commands all begin with {{{:}}} and the command name may be abbreviated.\\ if you write {{{:}}} add to the command, for example:\\ {{{::l}}} or {{{::r}}} or {{{::set +m}}} and so on, the command run\\ on the other hand {{{::}}} do not run\\ Hope this help -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 17:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 17:40:15 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.0712ad6f7613b5da3cd59610b687b14c@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 rwbarton): * Attachment "nofib" added. normal nofib output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 17:40:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 17:40:51 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.cfb6f0b78edb624fd418a16b5a0bcb3e@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 rwbarton): * Attachment "nofib.slow" added. slow nofib output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 18:03:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 18:03:29 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.c9084628a7dc465d810ff5db6aa33cbe@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 rwbarton): I got rather different results from nofib, attached above. Note that these are for a full recompilation from scratch. Judging from the Size column in your nofib output, I guess that you probably also did a full recompilation from scratch. In the program that regressed the most in my nofib run, tak, it looks like the code generator just output basic blocks in a different order. Probably the order of the `then` and `else` branches of a conditional got reversed. tak is known to be very sensitive to (poorly-understood) alignment effects (#8279) so I'm inclined to assume this is just noise that we can't do much about. Not really sure what to make of the larger regressions that you saw, or why I can't reproduce them. -- Ticket URL: GHC The Glasgow Haskell Compiler From matthew at wellquite.org Sun Mar 19 19:18:49 2017 From: matthew at wellquite.org (matthew) Date: Mon, 20 Mar 2017 02:18:49 +0700 Subject: =?utf-8?B?Rnc6IG1hbnkgdGhhbmtz?= Message-ID: <1081981801.20170319221849@wellquite.org> Greetings! I wanted to thank you a lot for all you've done, it was a real help. Please read my whole message here http://pleasure.stgeorgebrainbalance4life.com/7372 Pardon my monkey thumbs, matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Sun Mar 19 22:40:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 22:40:53 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.e75bfb1d38a881785d953fb273a84094@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I'm currently working on a refactor to fix #13313 which should make it easier to implement this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 22:57:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 22:57:44 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.db5f1cb61dd9a9ec954545e349f8f66f@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: duplicate => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 22:58:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 22:58:03 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.cf9ab28cea44cfc7b44512785281e6e5@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3368 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => patch * differential: => Phab:D3368 Comment: Fixing the original issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 06:18:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 06:18:17 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe Message-ID: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.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: -------------------------------------+------------------------------------- Several years ago, Edward Kmett wrote a [https://www.schoolofhaskell.com/school/to-infinity-and-beyond/older-but- still-interesting/deamortized-st#newsflash--unsafeinterleavest-is-unsafe- blog post] that (among other things) explains that `unsafeInterleaveST` is not thread-safe; actions may be performed multiple times. The fix that would seem to match everything else best would be to rename `unsafeInterleaveST` to `unsafeDupableInterleaveST` and define `unsafeInterleaveST m = unsafeDupableInterleaveST (noDuplicate >> m)` using an `ST`ish version of `noDuplicate`. As Kmett explains, the dupable version is useful for high performance when the suspended action is known to be idempotent. Actually, the action being idempotent is insufficient, but I believe a sufficient condition is that the action does not both read and write any reference or array element. While we're at it, we need to document all the functions in `Control.Monad.ST.Unsafe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 06:18:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 06:18:35 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.d78861f885c81ffde36061ff1eea82e8@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 06:38:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 06:38:35 -0000 Subject: [GHC] #13458: Panic with unsafeCoerce and -dcore-lint Message-ID: <045.4b7b475fb8114631ab81f1483482bbf6@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MagicHash, TypeInType, ScopedTypeVariables #-} module UIOST where import GHC.Exts import Data.Kind import Unsafe.Coerce unsafeCoerce' :: forall (r :: RuntimeRep) (a :: TYPE r) (b :: TYPE r). a -> b unsafeCoerce' = unsafeCoerce unsafeCoerce }}} Compiling this with optimization and `-dcore-lint` produces a panic: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170308 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_aW7 :: TYPE r_aW6) r_aW6 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType }}} Using `unsafeCoerce# unsafeCoerce` produces the panic without optimization. I have not been able to reproduce the problem without `-dcore-lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 06:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 06:45:06 -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.d6fcf94afcfd51caf2d939ef2a5dc13f@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > {{{#!hs > {-# LANGUAGE MagicHash, TypeInType, ScopedTypeVariables #-} > module UIOST where > import GHC.Exts > import Data.Kind > import Unsafe.Coerce > > unsafeCoerce' :: forall (r :: RuntimeRep) > (a :: TYPE r) (b :: TYPE r). > a -> b > unsafeCoerce' = unsafeCoerce unsafeCoerce > }}} > > Compiling this with optimization and `-dcore-lint` produces a panic: > > {{{ > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.1.20170308 for x86_64-unknown-linux): > runtimeRepPrimRep > typePrimRep (a_aW7 :: TYPE r_aW6) > r_aW6 > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1191:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in > ghc:Outputable > pprPanic, called at compiler/simplStg/RepType.hs:360:5 in > ghc:RepType > }}} > > Using `unsafeCoerce# unsafeCoerce` produces the panic without > optimization. I have not been able to reproduce the problem without > `-dcore-lint`. New description: {{{#!hs {-# LANGUAGE MagicHash, TypeInType, ScopedTypeVariables #-} module UIOST where import GHC.Exts import Data.Kind import Unsafe.Coerce unsafeCoerce' :: forall (r :: RuntimeRep) (a :: TYPE r) (b :: TYPE r). a -> b unsafeCoerce' = unsafeCoerce id }}} Compiling this with optimization and `-dcore-lint` produces a panic: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170308 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_aW7 :: TYPE r_aW6) r_aW6 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType }}} Using `unsafeCoerce# id` produces the panic without optimization. I have not been able to reproduce the problem without `-dcore-lint`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 06:53:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 06:53:21 -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.69a28eb752ec340d70907d609d13a6e7@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the trouble here is that the (properly uninhabited) type {{{#!hs forall (r :: RuntimeRep) (a :: TYPE r) (b :: TYPE r). a -> b }}} has kind `*`, so `unsafeCoerce` happily accepts it as a target. But then when `unsafeCoerce` inlines, core lint sees `unsafeCoerce#` being used in a bogus fashion. Question: do representation-polymorphic functions need to get non-`*` kinds? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 07:36:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 07:36:42 -0000 Subject: [GHC] #13459: sdist make target doesn't create required ghc-tarballs dir Message-ID: <043.0a476631f8b1f15df2577a228e75503b@haskell.org> #13459: sdist make target doesn't create required ghc-tarballs dir -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 07:38:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 07:38:58 -0000 Subject: [GHC] #13460: StandardTargets wiki page is out of date Message-ID: <043.971d9ccd865651dc554f6b0f52e79710@haskell.org> #13460: StandardTargets wiki page is out of date -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was looking for the target for building the user manual so I checked https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets. Unfortunately none of the "documentation targets" seem to work. I tried those targets in {{{./}}}, {{{./docs}}}, and {{{./docs/users_guide}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 07:49:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 07:49:50 -0000 Subject: [GHC] #13459: sdist make target doesn't create required ghc-tarballs dir In-Reply-To: <043.0a476631f8b1f15df2577a228e75503b@haskell.org> References: <043.0a476631f8b1f15df2577a228e75503b@haskell.org> Message-ID: <058.18703925a6d2708e3371064f5b21e1d7@haskell.org> #13459: sdist make target doesn't create required ghc-tarballs dir -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: New description: Even after creating `ghc-tarballs` manually the directory is never used. Generated tarballs are still in `sdistprep`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 08:24:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 08:24:43 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.3280153bc6be1d30152dccf05369a4a5@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:68 simonpj]: > Akio, I've fixed that wrapper issue. Thank you! > > What's next on this ticket? After rebasing the branch on top of your fix, the nofib improvements are again consistent but very small: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- hpg +0.2% -1.1% 0.212 0.212 0.0% infer +0.3% -1.2% 0.054 0.054 0.0% solid +0.3% -6.6% 0.181 0.181 0.0% sphere +0.3% -1.7% 0.086 0.086 0.0% -------------------------------------------------------------------------------- Min +0.2% -6.6% -23.2% -23.4% -19.2% Max +0.7% +0.1% +16.3% +16.2% 0.0% Geometric Mean +0.3% -0.1% -0.1% -0.1% -0.3% }}} The branch can perform nested CPR in simple cases, but it fails to transform some cases I would like it to. Currently I'm trying to make `extendSigsWithLam` a bit more aggressive by allowing it to generate nested CPR information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 08:38:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 08:38:54 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.360fb57a8921089292f1f216f712e022@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > will get the immediate benefit of having better error messages Why will the error messages get better? Can you give an example? Is that an argument for putting wildcards everywhere? Why couldn't we just improve the error messages for `LHsSigType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 08:44:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 08:44:05 -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.dfd75bca50f359549434fc382725feab@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Another possible approach would be to find a way to avoid the crash and just compile the bogus code like the fool said.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 08:47:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 08:47:38 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.836198bf0ab098e27c7dfc7822f8c555@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: 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 first note that we intend to make `Constraint` and `Type` distinct throughout the compiler. Then `tcView` = `coreView` again, and this entire problem goes away. We should not leave this too long. Until then we are looking for a ''sound'' solution, but it doesn't have to be a ''good'' solution. I'm puzzled about where the instance for `C Type Eq` comes from; after all, `Eq :: Type -> Constraint`. I wonder what would go wrong if we just used `coreView` for both class and family instances. I think (3); but I still don't see an example except perhaps with a polykinded type constructor e.g. `Typeable Type (Proxy Type)` and `Typeable Constraint (Proxy Constraint)`, and perhaps we can live with that for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 08:50:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 08:50:06 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.4f87ba86c2280790bf6b7f8a1fa3baa5@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | typecheck/should_run/T13435 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't get this. David says it crashes; Richard adds a test that succeeds. Who is right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 09:15:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 09:15:53 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.18389d52fe15c27cb374ca9ac74fa2bf@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I feel like we might not be on the same page here, so let me try to clear things up. I might be operating under a misconception here, but isn't it impossible to properly detect wildcards in a type (and integrate it with `-XPartialTypeSignatures`) unless it's a `LHsSigWcType`? That is why the error message you get when you use named wildcards in instance contexts currently is so bizarre--it doesn't even properly //detect// that it's a wildcard, but instead misinterprets it as a type variable (leading to the not-quite-on-the-mark `-XConstraintKinds` error). So given this, if we are to be able to support `-XPartialTypeSignatures` eventually, we need to first transition from the use of `LHsSigType` in instance declarations to `LHsSigWcType`. I chose to do this first in its own Diff since: * It's far easier than adding `-XPartialTypeSignatures` support all in ome go. This is an easily identifiable and necessary component that still requires changing quite a few files, so splitting this task out will make the Diff(s) that //do// deal with `-XPartialTypeSignatures` support less noisy. * It requires a Haddock change, which is somewhat ugly, and I'd rather get it out of the way upfront. * It has the immediate benefit of getting GHC to recognize named wildcards in instance declarations, as noted above. Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 10:26:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 10:26:02 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.6a9ef01a30a77d120f0a7e1ac8118e6b@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11394, #13440 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #11394 => #11394, #13440 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 10:26:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 10:26:47 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.e1d284bb4e12d7239cd86ec5f332dd28@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > There are a variety of issues caused by the impedance mismatch between > GHC's use of Posix I/O interfaces on Windows (particularly with respect > to console I/O), > > * #10542: Incorrect Unicode input on Windows Console > * #7593: Unable to print exceptions of unicode identifiers > * #4471: Incorrect Unicode output on Windows Console > * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows > > As pointed on in ticket:2189#comment:12 the ultimate solution to this > would be to move all of GHC's IO to use the respective Win32 interfaces. > > = Also relevant = > * #7353: Windows lacks support in the I/O manager > * #806: hGetBufNonBlocking doesn't work on Windows > * #3081: Double output after Ctrl+C on Windows New description: There are a variety of issues caused by the impedance mismatch between GHC's use of Posix I/O interfaces on Windows (particularly with respect to console I/O), * #10542: Incorrect Unicode input on Windows Console * #7593: Unable to print exceptions of unicode identifiers * #4471: Incorrect Unicode output on Windows Console * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows As pointed on in ticket:2189#comment:12 the ultimate solution to this would be to move all of GHC's IO to use the respective Win32 interfaces. = Also relevant = * #7353: Windows lacks support in the I/O manager * #806: hGetBufNonBlocking doesn't work on Windows * #3081: Double output after Ctrl+C on Windows * #13440: `putStr` has different behaviour on Windows -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 11:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 11:37:41 -0000 Subject: [GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows In-Reply-To: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> References: <050.07651db8cbe0b77cfaa38ab7f0e57979@haskell.org> Message-ID: <065.f11e2627e8a5d4b3bd8dbc3378c2f3eb@haskell.org> #13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => closed * resolution: => wontfix * architecture: x86 => Unknown/Multiple Comment: Well, the long story short is this won't get fixed. The issue is that `mingw-w64` have their own version of the math functions. So depending on the link order you specify you get either the weird one exported in `ntdll` (which honestly I think is a mistake that Microsoft never could correct due to backwards compatibility.) Anyway, we debated three options, one of which I proposed was to remove these functions from `ntdll.a` entirely as MSDN does not document them. This lends more evidence to my theory that they were a mistake. But it seems this can't be done, so instead I suggested to also change the x64 version to break. The reason is that at least it's consistent and you won't end up with a different math function by accident. On the long term, this means that no haskell library should use `ntdll.a` as libraries don't have full control over the link ordering. This of course extends to other C code compiled by GHC. Those have to be linked to a shared library and then used by haskell code or dynamically load ntdll. Such is life. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 11:44:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 11:44:29 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.37353f329bb11f9bd7e2917ea711be6c@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I'm currently working on this and a few other things for my 8.4 contributions. But I'll refrain from mass assigning all these issues to me until I know for sure I can get it done. Currently it looks viable though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 13:17:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 13:17:32 -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.40062f2d9f515fbbf1f8b8810d8bda8e@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: lukemaurer (added) Comment: Ha! That's funny. I don't know why Luke added that, but I suggest we just remove it. Occurrence analysis doesn't really add anything new that Lint can catch, I think. Or add yet another flag. But taking a big slow- down for this just doesn't seem worth it. Luke do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 13:18:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 13:18:55 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.dc470aad1c6a62ee82fbb45c88ec2baa@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): Hmm. I can re-try. Did you see any wins either? What does your summary table (like the above) look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 13:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 13:36:31 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.4be7a09eca8783176cdaa17f2496e9ec@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I might be operating under a misconception here, but isn't it impossible to properly detect wildcards in a type What do you mean by "properly detect"? How would things be better if we did "properly detect" them? Specifically * Why will the error messages get better? Can you give an example? * Is that an argument for putting wildcards everywhere? Why should only instance declarations get the benefit of this error message improvement? * Why couldn't we just improve the error messages for `LHsSigType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 13:37:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 13:37:56 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.fbd313c6205dd9744f69bc4549c3a052@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > it fails to transform some cases I would like it to. Can you give some specific programs that you would like to be optimised and aren't? A list of specific examples would help to make sure that everyone on this thread was talking about the same things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 13:55:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 13:55:59 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.cd1ff488e037ae3619f964dd655cc97a@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 simonpj]: > What do you mean by "properly detect"? I'll once again point you to the original example that I reported: {{{#!hs {-# LANGUAGE NamedWildCards #-} module Bug where instance _x => Show (Maybe a) }}} {{{ Bug.hs:4:10: error: • Illegal constraint: _x (Use ConstraintKinds to permit this) • In the context: _x While checking an instance declaration In the instance declaration for ‘Show (Maybe a)’ | 4 | instance _x => Show (Maybe a) | ^^^^^^^^^^^^^^^^^^^^ }}} In this example, **`_x` is a named wildcard, and GHC is not detecting this.** The error message //should// be that we're using a named wildcard without having `-XPartialTypeSignatures` on. > How would things be better if we did "properly detect" them? Specifically > > * Why will the error messages get better? Can you give an example? Yes. Please refer to [https://phabricator.haskell.org/D3332#e4a3ef42 this test case] in Phab:D3332. Instead of the completely misleading error message about `-XConstraintKinds` that it currently gives, it now detects the use of a named wildcard and says: {{{#!hs Wildcard ‘_x’ not allowed in an instance declaration for ‘Show’ }}} It doesn't suggest turning on `-XPartialTypeSignatures` yet because that's the subject of #13324, and as I noted in comment:9, even getting GHC to recognize the use of a wildcard in instance declarations is a somewhat significant task, which is why I opened a separate ticket for it in the first place. > * Is that an argument for putting wildcards everywhere? Why should only instance declarations get the benefit of this error message improvement? That's not at all what I'm trying to advocate for here. The point (which I tried to articulate in comment:9, but I'll restate here) is that we have identified a place where we'd //like// to have wildcard constraints, so in order to accomplish that goal, we need to: 1. Change the use of `LHsSigType` in instance declarations to `LHsSigWcType` so that we can use wildcards there in the first place 2. Change the typechecker code so that it fills in wildcard constraints when typechecking instance contexts Doing both in one go would be an enormous change, so I'm trying to do this piecemeal and tackle (1) on its own first. That's it. (I originally made an appeal to having better error messages from this change, but now I thoroughly regret doing so, because it has completely derailed the discussion.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 16:10:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 16:10:28 -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.00108159d4d631d1f93c4587cf146ced@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): BTW, do you withdraw comment:25? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 16:32:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 16:32:48 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.6948314b28ed453e79371e6c31a22ae2@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I'm inclined to agree with the proposal to use `coreView` in class/family instances, so we would regard an instance of `Typeable * Constraint` as overlapping `Typeable * Type` and hence not be able to solve the former. FWIW, here's an actual implementation of `unsafeCoerce` in GHC 8.0.2 exploiting this bug: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes, TypeFamilies, TypeOperators #-} import Data.Kind import Data.Typeable type family F x a b type instance F Type a b = a type instance F Constraint a b = b foo :: x :~: y -> F x a b -> F y a b foo Refl = id unsafeCoerce :: a -> b unsafeCoerce x = case eqT :: Maybe (Type :~: Constraint) of Nothing -> error "No more bug!" Just r -> foo r x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 16:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 16:34:53 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.cd964ab5e276c681d9b1cfe392a9dddc@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): If you don't read or write to the same STRef (or STArray element) like you state (and don't use unsafeIOToST, etc.) then this is a sufficient condition for your operation to be idempotent. =) You can actually strengthen to not reading from a ref that you write to before you write to it. The write washes away your sins by destroying any information leaked. I actually exploit that extra structure in my monadic revisions code. But again, this is just a weak way to state a demand for idempotence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 16:44:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 16:44:12 -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.730bc984e25cd143264ee2dda9470b0b@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): And does this address Joachim's comment on [https://phabricator.haskell.org/rGHC2effe18ab51d]? {{{ This might be interesting for @lukemaurer: According to https://perf.haskell.org/ghc/#revision/2effe18ab51d66474724d38b20e49cc1b8738f60 this patch undid the effect of join points on fannkuch-redux (i..e allocation goes up by 1318762.9%, but runtime goes down by 5%). Was this ever cleared up? Also, integer runtime goes up by 13%, and hidden by 6%, and code size generally by around 4%. Expected? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 16:46:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 16:46:55 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.0400999be271b0ee9d46f266cfe08ead@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): ekmett, what I was trying to get at is that as well as being run twice by different threads, the action could even be run twice ''at the same time'', interleaving reads and writes in an unspecified order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:04:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:04:06 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole, importing a module with a lot of identifiers Message-ID: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> #13461: Panic on compile of file with a hole, importing a module with a lot of identifiers -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I was trying to test the performance of `validSubstitutions`, I generated a file with a lot of identifiers, and compiled it with my current GHC, `The Glorious Glasgow Haskell Compilation System, version 8.0.2`. The example was very simple, just: {{{ import ManyIds test :: Int -> Int test = _ }}} Where `ManyIds.hs` was generated with the python script: {{{ print("module ManyIds where") print() for i in range(10000): print("a{} :: Int -> Int".format(i)) print("a{} _ = {}".format(i,i)) print() }}} i.e. it has a lot of identifiers of the form {{{ ... a1337 :: Int -> Int a1337 _ = 1337 a1338 :: Int -> Int a1338 _ = 1338 ... }}} The error I got was: {{{ [2 of 2] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] __a5IO :: t_a5IN[tau:1] (CHoleCan: _)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:07:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:07:36 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else (was: Panic on compile of file with a hole, importing a module with a lot of identifiers) In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.d8f998a21b747b2c20a1ff31edd19134@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Tritlo: Old description: > So I was trying to test the performance of `validSubstitutions`, I > generated a file with a lot of identifiers, and compiled it with my > current GHC, `The Glorious Glasgow Haskell Compilation System, version > 8.0.2`. > > The example was very simple, just: > > {{{ > import ManyIds > > test :: Int -> Int > test = _ > }}} > > Where `ManyIds.hs` was generated with the python script: > {{{ > print("module ManyIds where") > print() > > for i in range(10000): > print("a{} :: Int -> Int".format(i)) > print("a{} _ = {}".format(i,i)) > print() > }}} > > i.e. it has a lot of identifiers of the form > > {{{ > ... > a1337 :: Int -> Int > a1337 _ = 1337 > > a1338 :: Int -> Int > a1338 _ = 1338 > ... > }}} > > The error I got was: > > {{{ > [2 of 2] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-apple-darwin): > initTc: unsolved constraints > WC {wc_insol = [W] __a5IO :: t_a5IN[tau:1] (CHoleCan: _)} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: The example is very simple, just: {{{ test :: Int -> Int test = _ }}} which produces the panic: {{{ [1 of 1] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] __awc :: t_awb[tau:1] (CHoleCan: _)} }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:08:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:08:46 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.1562bcaade44ebe95d96dbc402319636@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > The example is very simple, just: > > {{{ > test :: Int -> Int > test = _ > }}} > > which produces the panic: > > {{{ > [1 of 1] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-apple-darwin): > initTc: unsolved constraints > WC {wc_insol = [W] __awc :: t_awb[tau:1] (CHoleCan: _)} > }}} New description: The example is very simple, just: {{{ test :: Int -> Int test = _ }}} which produces the panic: {{{ [1 of 1] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] __awc :: t_awb[tau:1] (CHoleCan: _)} }}} I suspect that there might be a missing case when there is nothing else in scope. -- Comment (by Tritlo): Replying to [ticket:13461 Tritlo]: > The example is very simple, just: > > {{{ > test :: Int -> Int > test = _ > }}} > > which produces the panic: > > {{{ > [1 of 1] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-apple-darwin): > initTc: unsolved constraints > WC {wc_insol = [W] __awc :: t_awb[tau:1] (CHoleCan: _)} > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:11:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:11:33 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.db2ebbdd5c6547f31d2f56f0503412cb@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Tritlo: Old description: > The example is very simple, just: > > {{{ > test :: Int -> Int > test = _ > }}} > > which produces the panic: > > {{{ > [1 of 1] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-apple-darwin): > initTc: unsolved constraints > WC {wc_insol = [W] __awc :: t_awb[tau:1] (CHoleCan: _)} > }}} > > I suspect that there might be a missing case when there is nothing else > in scope. New description: The example is very simple, just: {{{ test :: Int -> Int test = _ }}} which produces the panic: {{{ [1 of 1] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] __awc :: t_awb[tau:1] (CHoleCan: _)} }}} I suspect that there might be a missing case when there is nothing else in scope, since {{{ test :: Int -> Int test = _ main :: IO () main = return () }}} compiles just fine (i.e. with no panic, but still reports the typed hole. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:14:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:14:55 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.e39ebb93ce8bbea159b960c97fd7461e@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could this be #13106? Try with HEAD? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:16:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:16:04 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.09544580b4d1b59eafd78e9314646ffd@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: 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): OK! Thanks for an exploitable test case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:20:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:20:04 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.cf4a06d368d3d4a44086305a3acfaf53@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: new => merge Comment: It works on HEAD! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:20:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:20:45 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.5f37db7c315abda6b5b5295ab9f3860c@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:21:28 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.c22e1a01ff069fb0a014c940580fdd2e@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:24:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:24:48 -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.e4761abab229dc6291a8e92f13254cb2@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I bisected and found out that the offending commit was none other than 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 "Join points". I didn't see this in my previous data because, ironically, `-dcore-lint` causes the large space usage to go away. So it seems likely to be a garden-variety thunk buildup in some field which is examined by core lint, but otherwise not examined until late in the compilation pipeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:24:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:24:52 -0000 Subject: [GHC] #13461: Panic on compile of file with a hole and nothing else In-Reply-To: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> References: <045.55b3e436e0c764143ef21ff918f2c67f@haskell.org> Message-ID: <060.487af74faac80f2b8103bd9fb577dc72@haskell.org> #13461: Panic on compile of file with a hole and nothing else -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:32:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:32: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.fcbad166d45c845d5abefc5685dd56e9@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:30 simonpj]: > BTW, do you withdraw comment:25? Well, the addition of that `ensureEqTys` did contribute a couple percent to the total compilation time (with `-dcore-lint`) in my test. If it's useful we can keep it; I don't understand what kind of substitution `le_subst` Core Lint is carrying around, so it's unclear to me whether this is actually testing something about the program being compiled or testing the consistency of Core Lint itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 17:42:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 17:42:22 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.76413380e50d570312626f5a153f50c4@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: 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): There is a counterargument to the need to find a ''sound'' solution. Assume `type family F`. In GHC 8.0, you can say {{{ type instance F Constraint = Int type instance F Type = Bool }}} In GHC 8.4, you will also be able to say this, as `Constraint` will be fully distinct from `Type`. But comment:69 and comment:70 propose to disallow these instances in 8.2. This is certainly quite strange from a user standpoint! Instead, perhaps we live with the unsoundness, as long as the user can't find out. My guess is that the user's only way of finding out is via `Typeable`, which would need to reinforced against such attacks. (Specifically, arrange to make sure that the rep for `Constraint` is distinct from that for `Type`.) But I think we can do this. I very much don't like the idea of unsoundness in Core, but it won't be the only way to implement `unsafeCoerce`, and continuing to allow those instances provides a smoother experience to the user. Credit to @yav, who provoked me into actually suggesting to live with unsoundness! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 18:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 18:22:19 -0000 Subject: [GHC] #13445: Fix 32 bit Windows build of GHC 8.2 In-Reply-To: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> References: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> Message-ID: <059.ed8df0112aaa6c1d2aa125cc1ea72a2b@haskell.org> #13445: Fix 32 bit Windows build of GHC 8.2 ----------------------------------------+---------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #13431 | Differential Rev(s): Phab:D3362 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by Phyx-): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 18:29:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 18:29:23 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.e339d96a118d70038863145aa94893b9@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3370 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3370 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 19:23:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 19:23:02 -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.1fec912637dbe5b2c152157908a4e93d@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => goldfire Comment: It looks like this is squarely in Richard's territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 19:32:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 19:32:35 -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.7b556c3fd69c0e738c67ce8ec2427149@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): One thought: we currently have a rule that no variable can have a levity- polymorphic type, but that doesn't seem quite strong enough in the presence of `unsafeCoerce`. One option might be to decree that a levity- polymorphic type can't occur in negative position in the signature of a binding. That is, I think we should likely reject the ''signature'' of `unsafeCoerce'` altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 19:39:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 19:39:24 -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.ee2f3d23a32350935a1141da73fa773d@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Reid thinks we should compile fine and just crash and burn at runtime. I'm fine with that too, but Richard will have to decide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 19:46:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 19:46:14 -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.ad42cd0725390b0624463a6944f42c2c@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): If you change the type signature to `unsafeCoerce' :: Int# -> Int#` then the generated core is {{{ unsafeCoerce' = (id @ Any) `cast` (UnsafeCo representational Any Int# -> UnsafeCo representational Any Int# :: ((Any -> Any) :: *) ~R# ((Int# -> Int#) :: *)) }}} Optimizing the coercion like this seems dubious when the new coercions are ill-kinded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 20 21:38:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Mar 2017 21:38:16 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.0d89818fbea01cff5ff1d27550b4a9dd@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: patch Priority: high | 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:D3369 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D3369 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 00:24:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 00:24:37 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.dd98d0e7404d12ad84cd9366866d5be4@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: GHCi | 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): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Operator fixity can be a source of bugs (even for experienced > users!),[#point1 ¹] [#point2 ²] precedence levels may vary between > languages and then there are user-defined operators. > > Attached is a patch for a ghci command allowing users to quickly > parenthesise expressions as a sanity check (and as an alternative to > using :info and parsing the result yourself). The command itself is > activated with `:paren`: > > {{{#!hs > ghci> :paren 2 + 10 * 4 / 3 > 2 + ((10 * 4) / 3) > ghci> :paren \a b → a == b || b && a == (b == a) || b > \ a b -> (a == b) || ((b && (a == (b == a))) || b) > ghci> :paren 5 + 1 `mod` 2 > 5 + (1 `mod` 2) > ghci> :paren 5 * 1 `mod` 2 > (5 * 1) `mod` 2 > }}} > > A friend of mine also pointed out that this could eventually be > integrated into `haskell-mode` where the user could temporarily replace > an expression with a parenthesised version or have different colours > indicate different levels of logical nesting. > > ---- > > An example that is tricky for me is `calculateBmi w h = w / h^2`. > > [=#point1 ¹] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs > about binary operator precedence] > > [=#point2 ²] > [http://ieeexplore.ieee.org/document/7548903/?platform=hootsuite Brace > Yourself] ([https://twitter.com/ieeesoftware/status/791882437295038464 > tweet]) New description: [https://www.reddit.com/r/haskell/comments/605o3b/add_a_describe_command_to_your_ghci_for_figuring/ reddit thread]. ---- Operator fixity can be a source of bugs (even for experienced users!),[#point1 ¹] [#point2 ²] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{#!hs ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. ---- An example that is tricky for me is `calculateBmi w h = w / h^2`. [=#point1 ¹] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] [=#point2 ²] [http://ieeexplore.ieee.org/document/7548903/?platform=hootsuite Brace Yourself] ([https://twitter.com/ieeesoftware/status/791882437295038464 tweet]) -- Comment (by Iceland_jack): Examples: {{{#!hs pattern (:=) :: [String] -> [String] -> [String] pattern xs:=ys <- (break (== "=") -> (xs, "=":ys)) splitArgs (words -> fn:args:=rest) = ... }}} Both `(fn:args):=rest` and `fn:(args:=rest)` parse, to see which one it is one either has to know the fixity rules, know `infixr 5 :`, know the default fixity (running the command `:info :=` currently does not divulge such secrets) or you could think of inputs (or have QuickCheck generate..) that give a different result.. neither ideal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 01:08:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 01:08:30 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.62c67eb0b3c01db1e33a9f131a30ab66@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | simplCore/should_compile/T13413 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 Tue Mar 21 01:18:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 01:18:14 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.cde4be68d679cf9528190e4e9ff7ff65@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: patch Priority: high | 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:D3369 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"e0eaea918c32b3aa445708656876d1e2aef94a13/ghc" e0eaea91/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0eaea918c32b3aa445708656876d1e2aef94a13" Correctly account for -package-db ordering when picking packages. Summary: When I originally implemented ABI-based shadowing as per ee4e1654c31b9c6f6ad9b19ece25f040bbbcbd72, I switched our strategy from pasting together lists to creating a map of all units first, and then selecting packages from this. However, what I did not realize when doing this was that we actually depended on the *ordering* of these lists later, when we selected a preferred package to use. The crux is if I have -package-db db1 -package-db db2 -package p-0.1, and p-0.1 is provided by both db1 and db2, which one does the -package flag select? Previously, this was undetermined; now we always select the instance from the LATEST package database. (If p-0.1 shows up multiple times in the same database, once again the chosen package is undefined.) The reason why cabal08 intermittently failed was that, in practice, we were sorting on the UnitId, so when we bumped version numbers, that often wibbled the UnitIds so that they compared oppositely. I've extended the test so that we check that the relation is antisymmetric. Fixes #13313 Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3369 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 03:26:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 03:26:23 -0000 Subject: [GHC] #13462: stack upgrade failed, version 1.0.4 at macosx Message-ID: <048.cf306d405b5cb7a84cd0553038558a52@haskell.org> #13462: stack upgrade failed, version 1.0.4 at macosx -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: panic | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- os: Darwin lambda-cat.local 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64 macOS sierra, 10.12.3 stack version: Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64 ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/79/l2kk9s8572gdvzc8r5jq2pf40000gn/T/ghc39735_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/79/l2kk9s8572gdvzc8r5jq2pf40000gn/T/ghc39735_0/libghc_68.dylib: malformed mach-o: load commands size (50048) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 28 action(s). -- While building package stack-1.4.0 using: /private/var/folders/79/l2kk9s8572gdvzc8r5jq2pf40000gn/T/stack- upgrade36593/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 04:22:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 04:22:42 -0000 Subject: [GHC] #13424: readMutVar# is marked can_fail In-Reply-To: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> References: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> Message-ID: <060.03cbf1126ae6a60a13e6f44592b70bd0@haskell.org> #13424: readMutVar# is marked can_fail -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch 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): Phab:D3340 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"2ac13c132d039438382baef6ce52c79b29725145/ghc" 2ac13c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2ac13c132d039438382baef6ce52c79b29725145" Let GHC know MutVar# ops can't fail The only way `readMutVar#` or `writeMutVar#` can fail is if its argument is not a valid pointer. I believe we ensure this by construction, and never test for pointer validity. So I think it should be safe to say that it can't fail. Fixes #13424 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3340 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 04:25:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 04:25:26 -0000 Subject: [GHC] #13424: readMutVar# is marked can_fail In-Reply-To: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> References: <045.a81f0ea2d9339462b9c5ad9620870076@haskell.org> Message-ID: <060.6bcc7408611458913f480cd5eb95b1f5@haskell.org> #13424: readMutVar# is marked can_fail -------------------------------------+------------------------------------- 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3340 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed Comment: Note that this change probably won't have any immediate effect, since these primops are both `has_side_effects`; it just tries to set the stage a bit for further ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 04:49:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 04:49:00 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.38a65198f1d26e35f2dae5c1a103990f@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: Is there a GHC proposal for this? I think it'd be pretty cool to get something similar, perhaps with an explicit separator between the arguments and the subpatterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 09:05:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 09:05:59 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.c506086ec80d30b83fcb21926742e22b@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Is this a matter of finding good syntax or is it something fundamental? I'll get the ball rolling, help me pick this apart {{{#!hs pattern Lookup \key val <- (lookup key -> Just val) pattern IsMember \val <- (member val -> True) -- and they get marked with $ when in pattern -- (I'm making this up on the tube) age (Lookup $"Alice" age) = ... -- Simon's f p (Lookup $p p) = p }}} If it helps we could impose a separation between "argument patterns" and patterns. I want this feature at least once a week ;) so I self-servingly remain +1 if this can be sorted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 10:06:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 10:06:15 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.6a630ee567429c4cded642d9060389d2@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:3 cactus]: > > The implementation is a straightforward desugaring into pattern synonyms and view patterns > > That's how I started the work on pattern synonyms in the first place... spoiler alert: it never is :) ;) > +1 to SPJ on distinguishing ''pat'' and ''expr'' arguments. In fact, I think they should be distinguished even when introducing them as formal arguments. Can you elaborate on last part -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 10:42:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 10:42:42 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.db461ab72316979c70b0c95d952fe4ed@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: GADTs, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) Comment: I agree with David here. It would be good to optimise cases like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 10:54:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 10:54:07 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.f234a3227006e747d7e4ab3388778be9@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: Inlining => Inlining, newcomer Comment: I think change the behaviour and update the test. Seems like an easy ticket for a newcomer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 13:09:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 13:09:53 -0000 Subject: [GHC] #13462: stack upgrade failed, version 1.0.4 at macosx In-Reply-To: <048.cf306d405b5cb7a84cd0553038558a52@haskell.org> References: <048.cf306d405b5cb7a84cd0553038558a52@haskell.org> Message-ID: <063.058e5f93236e9da56949ad31e9931252@haskell.org> #13462: stack upgrade failed, version 1.0.4 at macosx -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: panic Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * 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 Tue Mar 21 14:11:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 14:11:54 -0000 Subject: [GHC] #13463: Deriving Functor / Foldable / Traversable for co-pattern type Message-ID: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> #13463: Deriving Functor / Foldable / Traversable for co-pattern type -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- This is probably asking too much, but could GHC derive `Functor`, `Foldable` ... for this [https://www.reddit.com/r/haskell/comments/4aju8f/simple_example_of_emulating_copattern_matching_in/ co-pattern] data type? {{{#!hs data ListTag :: Type -> Type -> Type where HeadTag :: ListTag a a TailTag :: ListTag a (Stream a) newtype Stream a = S (forall res. ListTag a res -> res) instance Functor Stream where fmap :: (a -> a') -> (Stream a -> Stream a') fmap f (S stream) = S $ \case HeadTag -> f (stream HeadTag) TailTag -> fmap f (stream TailTag) instance Foldable Stream where foldMap :: Monoid m => (a -> m) -> (Stream a -> m) foldMap f (S stream) = f (stream HeadTag) <> foldMap f (stream TailTag) }}} I'm guessing it's not worth it in any case, but is it uniquely determined? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 14:12:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 14:12:18 -0000 Subject: [GHC] #13463: Deriving Functor / Foldable / Traversable for co-pattern type In-Reply-To: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> References: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> Message-ID: <066.fddcebe1c262c3892e2eab362660d8b3@haskell.org> #13463: Deriving Functor / Foldable / Traversable for co-pattern type -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > This is probably asking too much, but could GHC derive `Functor`, > `Foldable` ... for this > [https://www.reddit.com/r/haskell/comments/4aju8f/simple_example_of_emulating_copattern_matching_in/ > co-pattern] data type? > > {{{#!hs > data ListTag :: Type -> Type -> Type where > HeadTag :: ListTag a a > TailTag :: ListTag a (Stream a) > > newtype Stream a = S (forall res. ListTag a res -> res) > > instance Functor Stream where > fmap :: (a -> a') -> (Stream a -> Stream a') > fmap f (S stream) = S $ \case > HeadTag -> f (stream HeadTag) > TailTag -> fmap f (stream TailTag) > > instance Foldable Stream where > foldMap :: Monoid m => (a -> m) -> (Stream a -> m) > foldMap f (S stream) = f (stream HeadTag) <> foldMap f (stream TailTag) > }}} > > I'm guessing it's not worth it in any case, but is it uniquely > determined? New description: This is probably asking too much, but could GHC derive `Functor`, `Foldable` ... for this [https://www.reddit.com/r/haskell/comments/4aju8f/simple_example_of_emulating_copattern_matching_in/ co-pattern] data type? {{{#!hs data StreamTag :: Type -> Type -> Type where HeadTag :: StreamTag a a TailTag :: StreamTag a (Stream a) newtype Stream a = S (forall res. StreamTag a res -> res) instance Functor Stream where fmap :: (a -> a') -> (Stream a -> Stream a') fmap f (S stream) = S $ \case HeadTag -> f (stream HeadTag) TailTag -> fmap f (stream TailTag) instance Foldable Stream where foldMap :: Monoid m => (a -> m) -> (Stream a -> m) foldMap f (S stream) = f (stream HeadTag) <> foldMap f (stream TailTag) }}} I'm guessing it's not worth it in any case, but is it uniquely determined? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 15:37:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 15:37:05 -0000 Subject: [GHC] #13464: Pattern match checker runs even when not needed Message-ID: <048.7d561c8e5be458a92c64e2a38a75aadf@haskell.org> #13464: Pattern match checker runs even when not needed -------------------------------------+------------------------------------- Reporter: jstolarek | 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: -------------------------------------+------------------------------------- I have code that triggers pattern match checker warning: {{{ Pattern match checker exceeded (2000000) iterations in a case alternative. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I would like to silence that warning. Alas, `-Wno-incomplete-patterns` does nothing - the warning still appears. I would expect that if I do not want to check for incomplete patterns then pattern match checker is not run at all and thus does not exceed maximum number of iterations! I can only use `-w` to silence all the warnings but this is an overkill - definitely not what I want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 15:39:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 15:39:40 -0000 Subject: [GHC] #13464: Pattern match checker runs even when not needed In-Reply-To: <048.7d561c8e5be458a92c64e2a38a75aadf@haskell.org> References: <048.7d561c8e5be458a92c64e2a38a75aadf@haskell.org> Message-ID: <063.bd14e6e1f2d84be2ddbfb4f5fab654be@haskell.org> #13464: Pattern match checker runs even when not needed -------------------------------------+------------------------------------- Reporter: jstolarek | 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 mpickering): You also need to turn off `-Woverlapping-patterns` I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 15:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 15:47:51 -0000 Subject: [GHC] #13464: Pattern match checker runs even when not needed In-Reply-To: <048.7d561c8e5be458a92c64e2a38a75aadf@haskell.org> References: <048.7d561c8e5be458a92c64e2a38a75aadf@haskell.org> Message-ID: <063.3791abf527dfd0a65b681acd8abf90c2@haskell.org> #13464: Pattern match checker runs even when not needed -------------------------------------+------------------------------------- Reporter: jstolarek | 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: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => invalid Comment: Ah, indeed. I missed that flag when looking at flag reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 16:17:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 16:17:44 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.79f32eb019e69d305aedb3e6599f00d3@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I haven't seen this, it doesn't seem to be happening in Harbourmaster. If you could investigate more that would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 16:18:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 16:18:43 -0000 Subject: [GHC] #13413: GHC HEAD panic: collectNBinders In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org> Message-ID: <065.3f2c7c48613e57c9fd58bdd323b1f592@haskell.org> #13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj 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: GHC rejects | Test Case: valid program | simplCore/should_compile/T13413 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as ba293130a71662ded2f36ec902bc275b0adaa391. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 16:20:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 16:20:09 -0000 Subject: [GHC] #13202: Levity polymorphism panic in GHCi In-Reply-To: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> References: <046.aa104eb314af75cbcc5fbe153199623a@haskell.org> Message-ID: <061.886ebffdac006b1ad207c292a28f5502@haskell.org> #13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T13202{,a} 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 4c6a016900b0e9af382661efc4bb737e47d90d93. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 16:20:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 16:20:33 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.d7d202846e6103ab64dc8ffc08a8b75a@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- 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 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12709 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 ae6e63aa858d663952b67cc9969fd14782d307bb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 16:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 16:21:09 -0000 Subject: [GHC] #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar In-Reply-To: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> References: <050.d53d0a454980b5105fc2916b434ba30b@haskell.org> Message-ID: <065.a50d0ae28f94daed815c041e6a69b32a@haskell.org> #13343: Levity polymorphism-related GHC panic: expectJust zonkTcTyVarToVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.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/T13343 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 32c9abee8304d1ab86329bb24652b7232669def2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 16:21:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 16:21:53 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.6b47c5ede1bf8c8a2a6eb1614c7f270b@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | typecheck/should_run/T13435 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 d40d5e8b40a1a795fef43f0abdf7aaf143fca911. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 19:07:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 19:07:54 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.3aa831faf39d90d7efb6586c107bd514@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | typecheck/should_run/T13435 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I was just wrong, I believe. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 19:25:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 19:25:48 -0000 Subject: [GHC] #13463: Deriving Functor / Foldable / Traversable for co-pattern type In-Reply-To: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> References: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> Message-ID: <066.cca0e70770454479a2a7c5f4e39bd635@haskell.org> #13463: Deriving Functor / Foldable / Traversable for co-pattern type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => low * status: new => closed * resolution: => wontfix Comment: Valid `Functor` instances are always uniquely determined. Valid `Traversable` instances usually aren't, but are they're tightly constrained. `Foldable` is pretty wild; it could shuffle the stream however it liked. In this case, you'd have to come up with a general convention for ordering such things, which seems impractical. The biggest problem here, probably, is that the deriving mechanism only works with one type at a time (indeed, really one constructor at a time). It doesn't dig into other mentioned types at all, and it seems likely quite hard to do so in a consistent way. GADTs only compound the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 19:26:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 19:26:45 -0000 Subject: [GHC] #13463: Deriving Functor / Foldable / Traversable for co-pattern type In-Reply-To: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> References: <051.bdd59917acb72dccbbf0c10027f09e8b@haskell.org> Message-ID: <066.2bbdcf8361a8d6206eca9d9a5f815f53@haskell.org> #13463: Deriving Functor / Foldable / Traversable for co-pattern type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm closing this for now; feel free to reopen if you have some idea about implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 20:25:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 20:25:57 -0000 Subject: [GHC] #13465: Foldable deriving treatment of tuples is too surprising Message-ID: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> #13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- {{{ *> :set -XDeriveFoldable *> data Foo a = Foo ((a,a),a) deriving Foldable *> length ((1,1),1) 1 *> length $ Foo ((1,1),1) 3 }}} I think the right thing is probably to refuse to derive `Foldable` if components of a tuple other than the last one may contain the type variable we're looking for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 21:23:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 21:23:58 -0000 Subject: [GHC] #13465: Foldable deriving treatment of tuples is too surprising In-Reply-To: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> References: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> Message-ID: <060.b013a7a2843bfb49ccfea2b82ad9e45f@haskell.org> #13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- 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 hvr): Same goes for `-XDeriveFunctor` btw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 21 21:25:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Mar 2017 21:25:16 -0000 Subject: [GHC] #13465: Foldable deriving treatment of tuples is too surprising In-Reply-To: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> References: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> Message-ID: <060.c605e973187c36b972c817baabf5f920@haskell.org> #13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- 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 dfeuer): Replying to [comment:1 hvr]: > Same goes for `-XDeriveFunctor` btw `DeriveFunctor` will only surprise by succeeding when might not expect it to; it cannot really have surprising behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 01:10:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 01:10:22 -0000 Subject: [GHC] #13465: Foldable deriving treatment of tuples is too surprising In-Reply-To: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> References: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> Message-ID: <060.64b541f87816c8802e7805a93b24b5ee@haskell.org> #13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: twanvl (added) Comment: Ick. This is an eccentricity of `DeriveFunctor`/`DeriveFoldable`/`DeriveTraversable` that I've never been keen on fixing, but since folks are complaining about it, I suppose it should at least be addressed. It's a somewhat obscure piece of GHC trivia that `DeriveFunctor` //et al.// special-cases two type constructors: 1. `(->)` 2. Tuples The `(->)` special case is somewhat justifiable, as it's quite common to define `Functor` instances where the type parameter occurs to the left of an arrow. The tuples special-casing is more confusing to me, as I'm not sure what practical purpose it serves. I've cc'd twanvl, the original author of these `deriving` extensions, in case he can share some insight on why he chose to implement it that way. I too think the Right Thing™ to do here is to change the behavior so that we just call `fmap`/`foldMap`/`traverse` on occurrences of tuple types, and reject things like `data Foo a = Foo (a, a) deriving (Functor, Foldable, Traversable)`. But there's one thorny corner case to watch out for: unboxed tuples. An even more obscure piece of GHC trivia is that you can do this: {{{#!hs data Foo a = Foo (# a, a #) deriving (Functor, Foldable) }}} This is only possible because of special-casing, as calling `fmap`/`foldMap` on an entire unboxed tuple is ill-kinded (unless we were to adopt [https://ghc.haskell.org/trac/ghc/ticket/12708 levity-polymorphic versions] of `Functor` and `Foldable`, I suppose). Moreover, it would feel weird to allow `data Foo a = Foo (# a, a #)` but not `data Foo a = Foo (a, a)`. I suppose we could tweak the special-casing so that we reject unboxed tuples where the type parameter occurs somewhere other than the last field, which would at least make its behavior consistent with that of boxed tuples. But the biggest roadblock by far is that this would (1) make fewer programs compile than before, and (2) change the behavior of existing programs. I think we should definitely get some kind of community consensus (i.e., a GHC proposal) before marching forth with this, although I have a funny feeling that discussing the behavior of `deriving Foldable` on tuple types is not going to go well... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 05:35:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 05:35:06 -0000 Subject: [GHC] #13280: Consider deriving more Foldable methods In-Reply-To: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> References: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> Message-ID: <060.d58e4997f1bf0998cae121432c7aeed1@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 dfeuer): Note about `length`, so I don't forget: For the nested case, {{{#!hs Con ... f (g a) ... }}} the way to make sure we never do worse than the default `length` definition (assuming the recursively called `length` is good) is to use {{{#!hs length (Con ... fga ...) = ... + foldl' (\acc x -> acc + length x) 0 fga + ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 09:58:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 09:58:19 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.50fd5e429dbd00dbc731ea1f5bc5a6fb@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{ > GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help > Prelude> :set -XTypeApplications -fprint-explicit-foralls > Prelude> :t 42 > 42 :: forall {a}. Num a => a > Prelude> 42 @Int > > :3:1: error: > • Cannot not apply expression of type ‘a0’ > to a visible type argument ‘Int’ > • In the expression: 42 @Int > In an equation for ‘it’: it = 42 @Int > }}} > > (Also, "cannot not" looks like a typo.) New description: Relevant [https://www.reddit.com/r/haskell/comments/60seia/type_application_on_literals/ reddit post]. ---- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int :3:1: error: • Cannot not apply expression of type ‘a0’ to a visible type argument ‘Int’ • In the expression: 42 @Int In an equation for ‘it’: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 10:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 10:22:50 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.5ceb6ee6f846d4c7a641c36b6290076d@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > There's a test (profinline001) that assumes INLINABLE functions don't get cost centers. So it seems like this was intentional. Should I still make this change? Yes, I think still make the change. Make sure the user manual documents the behaviour. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 10:35:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 10:35:31 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.94b50d80ca235ede6b0167d501779795@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 10:58:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 10:58:37 -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.3b9bf0d5f7e43f8c1ac5d870ea14166c@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great work. There is definitely a space leak here and it should not be to hard to find. Some ideas * In `CoreLint.lintSingleBinding` you'll find a series of tests. If you comment then out one by one, you'll find when the space leak comes back. That test must be forcing the offending bit of `IdInfo`. * Does the leak happen when you use `-dshow-passes`? That shows the size of eac intermediate, and `exprSize` is deliberately strict (see `CoreStats.bndrSize`). You could try making `CoreSeq.megaSeqidInfo` actually force the unfolding info (currently commented out) and see if that helps. (I'm not sure WHY it is commented out, incidentally.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 11:03:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 11:03:12 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.bee9973cfd60e7662fe78b4d41062dfe@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK so there are two separate things * Error messages. You say "_x is a named wildcard and GHC is not detecting it". So perhaps, with `NamedWildCards` we should complain about `_x` in any `LHsSigType`, rather than treating it as an ordinary type variable. Good plan: that would nail the error message issue. * Extending instance declarations to support wildcards. You want to do this in two steps. I'd prefer to take the second step (getting the payoff) before committing the first. Step 2 may turn out to influence Step 1. (E.g. the only wildcard we want to allow is in the context.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 11:07:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 11:07:45 -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.d8073cef7a304bd4e787aa5e35d4333b@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, fine. Reid, will you remove the offending Lint call, and pick up the perf benefits (I hope)? That may still leave comment:31 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 11:09:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 11:09:50 -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.c4b0798b4fd9933ccdaf63b121523540@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 11:12:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 11:12:33 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.d207b40c922efad64bb40a36f91e8d9e@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I think the correct way forward here is changing how `-XTypeApplications` works with partially applied functions. If I can write `fromInteger @t n`, shouldn't `fromInteger n @t` behave the same? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 11:14:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 11:14:57 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.f675b72eb3aacd62e3fea6c6af65f128@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 12:40:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 12:40:51 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions Message-ID: <047.5414232b40be6201b11861058f159173@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 haven't investigated further, but I stumbled upon the following: {{{ Prelude> :set -XTypeApplications Prelude> :t nonexistant @[] ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] nonexistant_a2YB :: t_a2YA[tau:3] (CHoleCan: nonexistant)} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 12:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 12:57:32 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions In-Reply-To: <047.5414232b40be6201b11861058f159173@haskell.org> References: <047.5414232b40be6201b11861058f159173@haskell.org> Message-ID: <062.49c9889ce6e2ffc19c7279bac2b414ff@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could this be #13106? Try with HEAD? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 13:22:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 13:22:15 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions In-Reply-To: <047.5414232b40be6201b11861058f159173@haskell.org> References: <047.5414232b40be6201b11861058f159173@haskell.org> Message-ID: <062.dc1abee87142b3a9d91bf22b69515581@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeApplications Comment: Actually, it's not #13106 for once! I can reproduce this on GHC HEAD as well: {{{ GHCi, version 8.3.20170322: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeApplications λ> :t nonexistant @[] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170322 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [WD] nonexistant_a1tE {0}:: t1_a1tD[tau:2] (CHoleCan: nonexistant)} Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcRnMonad.hs:343:17 in ghc:TcRnMonad }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 13:31:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 13:31:28 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.8cfc781edbdca6e8de13618637697815@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.1 => 8.0.1 Comment: Oh dear, there's actually a distinction between the attached program and the program in comment:4. The attached program compiles without issue on GHC 8.0.2 and earlier, but panics on GHC HEAD (post–join points). The program in comment:4, however, compiles without issue on GHC 7.10.3 and earlier, but panics on GHC 8.0.1, 8.0.2, //and// HEAD. This isn't terribly surprising, as [https://github.com/ekmett/hybrid- vectors/issues/7#issue-133619382 others have reported] seeing this error on earlier versions of GHC, but AFAICT, no one was able to minimize the panic down to a single file until now. So the issue likely predates join points, but join points have made it easier to trigger in GHC HEAD. I'll see if I can figure out what commit lead to the panic surfacing in the program in comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 13:40:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 13:40:24 -0000 Subject: [GHC] #13465: Foldable deriving treatment of tuples is too surprising In-Reply-To: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> References: <045.cb2178fb95349a41533e1243de9cad08@haskell.org> Message-ID: <060.22f5bfedb009528ba3accc063e2b32ed@haskell.org> #13465: Foldable deriving treatment of tuples is too surprising -------------------------------------+------------------------------------- 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 RyanGlScott): Sorry, the claim that the behavior of existing programs would change is false—it would only cause some existing programs that currently compile to no longer compile, which I think is acceptable. Also, here's the [https://mail.haskell.org/pipermail/ghc- devs/2017-March/013995.html ghc-devs mailing list] discussion on the matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 14:01:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 14:01:30 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.f1687f7bfe6c791114510d51385b8882@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Huh, the commit which caused the regression in comment:4 is 6746549772c5cc0ac66c0fce562f297f4d4b80a2 (Add kind equalities to GHC). What this means, I have no idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 14:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 14:15:04 -0000 Subject: [GHC] #13467: ghc: panic! (the 'impossible' happened), initTc: unsolved constraints Message-ID: <048.1ad32161a71717ab0f1d3a7a703634e4@haskell.org> #13467: ghc: panic! (the 'impossible' happened), initTc: unsolved constraints ----------------------------------------+--------------------------------- Reporter: jhjonsson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- NB! I'm no expert on the compiler and have not used GHC/GHCi very much. I have istaller the Haskell Platform and then run GHCi from within Aquamacs (emacs) using tthe Haskell mode already available there. I should say that everything worked fine and I could both load and run code. But then this happend when I started with the type Char and the functions ord and chr, so maybe the error has to do with them(?) Please change the subject to something relevant; I really have no clue what has happened here. Just like to help. /Håkan --- This is the error message: "GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load "/Users/hj/Downloads/d7012e-vt17/test.hs" [1 of 1] Compiling Main ( /Users/hj/Downloads/d7012e- vt17/test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] –_a2n2 :: t_a2n1[tau:1] (CHoleCan: –)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > " --- This is my Haskell code (putting together examples for a first lecture on declarative languages/functional languages): module Main (main) where import Data.Char (ord,chr) square :: Int -> Int square n = n * n primes :: [Int] primes = filterPrime [2..] where filterPrime (p:xs) = p : filterPrime [x | x <- xs, x `mod` p /= 0] -- take :: Int -> [a] -> [a] double :: Int -> Int double n = 2*n dubSq1 :: Int -> Int dubSq1 n = double (square n) dubSq2 :: Int -> Int dubSq2 = double . square -- Bool nAnd :: Bool -> Bool -> Bool nAnd x y = not (x && y) nAnd2 :: Bool -> Bool -> Bool nAnd2 True True = False nAnd2 False False = False nAnd2 x y = True -- if, the, else max2 :: Int -> Int -> Int max2 x y = if x >= y then x else y -- Int max3 :: Int -> Int -> Int -> Int max3 a b c = max2 (max2 a b) c f :: Int -> Int f 1 = 0 f n = if n `mod` 2 == 0 then n `div` 2 else 3*n + 1 isDigit :: Char -> Bool isDigit ch = ('0' <= ch) && (ch <= '9') isLower :: Char -> Bool isLower ch = ('a' <= ch) && (ch <= 'z') -- no åäö in ASCII offset :: Int offset = ord 'A' – ord 'a' toUpper :: Char -> Char toUpper ch = chr (ord ch + offset) f' 1 = 0 f' n | n `mod` 2 == 0 = n `div` 2 | otherwise = 3*n + 1 life_length x | x == 1 = 0 | otherwise = 1 + life_length(f' x) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 14:47:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 14:47:59 -0000 Subject: [GHC] #13467: ghc: panic! (the 'impossible' happened), initTc: unsolved constraints In-Reply-To: <048.1ad32161a71717ab0f1d3a7a703634e4@haskell.org> References: <048.1ad32161a71717ab0f1d3a7a703634e4@haskell.org> Message-ID: <063.aae9b5250927b0920da884f531da2b02@haskell.org> #13467: ghc: panic! (the 'impossible' happened), initTc: unsolved constraints ---------------------------------+---------------------------------------- Reporter: jhjonsson | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by RyanGlScott: Old description: > NB! I'm no expert on the compiler and have not used GHC/GHCi very much. I > have istaller the Haskell Platform and then run GHCi from within Aquamacs > (emacs) using tthe Haskell mode already available there. I should say > that everything worked fine and I could both load and run code. But then > this happend when I started with the type Char and the functions ord and > chr, so maybe the error has to do with them(?) Please change the subject > to something relevant; I really have no clue what has happened here. Just > like to help. /Håkan > --- > This is the error message: > > "GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help > Prelude> :load "/Users/hj/Downloads/d7012e-vt17/test.hs" > [1 of 1] Compiling Main ( /Users/hj/Downloads/d7012e- > vt17/test.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-apple-darwin): > initTc: unsolved constraints > WC {wc_insol = [W] –_a2n2 :: t_a2n1[tau:1] (CHoleCan: –)} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > " > > --- > > This is my Haskell code (putting together examples for a first lecture on > declarative languages/functional languages): > > module Main (main) where > import Data.Char (ord,chr) > > square :: Int -> Int > square n = n * n > > primes :: [Int] > primes = filterPrime [2..] > where > filterPrime (p:xs) = > p : filterPrime [x | x <- xs, x `mod` p /= 0] > > -- take :: Int -> [a] -> [a] > > double :: Int -> Int > double n = 2*n > > dubSq1 :: Int -> Int > dubSq1 n = double (square n) > > dubSq2 :: Int -> Int > dubSq2 = double . square > > -- Bool > > nAnd :: Bool -> Bool -> Bool > nAnd x y = not (x && y) > > nAnd2 :: Bool -> Bool -> Bool > nAnd2 True True = False > nAnd2 False False = False > nAnd2 x y = True > > -- if, the, else > > max2 :: Int -> Int -> Int > max2 x y = > if x >= y then x else y > > -- Int > > max3 :: Int -> Int -> Int -> Int > max3 a b c = max2 (max2 a b) c > > f :: Int -> Int > f 1 = 0 > f n = if n `mod` 2 == 0 then n `div` 2 else 3*n + 1 > > > isDigit :: Char -> Bool > isDigit ch = ('0' <= ch) && (ch <= '9') > > isLower :: Char -> Bool > isLower ch = ('a' <= ch) && (ch <= 'z') -- no åäö in ASCII > > offset :: Int > offset = ord 'A' – ord 'a' > > toUpper :: Char -> Char > toUpper ch = chr (ord ch + offset) > > > > > f' 1 = 0 > f' n > | n `mod` 2 == 0 = n `div` 2 > | otherwise = 3*n + 1 > > life_length x > | x == 1 = 0 > | otherwise = 1 + life_length(f' x) New description: NB! I'm no expert on the compiler and have not used GHC/GHCi very much. I have istaller the Haskell Platform and then run GHCi from within Aquamacs (emacs) using tthe Haskell mode already available there. I should say that everything worked fine and I could both load and run code. But then this happend when I started with the type Char and the functions ord and chr, so maybe the error has to do with them(?) Please change the subject to something relevant; I really have no clue what has happened here. Just like to help. /Håkan --- This is the error message: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :load "/Users/hj/Downloads/d7012e-vt17/test.hs" [1 of 1] Compiling Main ( /Users/hj/Downloads/d7012e- vt17/test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] –_a2n2 :: t_a2n1[tau:1] (CHoleCan: –)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} --- This is my Haskell code (putting together examples for a first lecture on declarative languages/functional languages): {{{#!hs module Main (main) where import Data.Char (ord,chr) square :: Int -> Int square n = n * n primes :: [Int] primes = filterPrime [2..] where filterPrime (p:xs) = p : filterPrime [x | x <- xs, x `mod` p /= 0] -- take :: Int -> [a] -> [a] double :: Int -> Int double n = 2*n dubSq1 :: Int -> Int dubSq1 n = double (square n) dubSq2 :: Int -> Int dubSq2 = double . square -- Bool nAnd :: Bool -> Bool -> Bool nAnd x y = not (x && y) nAnd2 :: Bool -> Bool -> Bool nAnd2 True True = False nAnd2 False False = False nAnd2 x y = True -- if, the, else max2 :: Int -> Int -> Int max2 x y = if x >= y then x else y -- Int max3 :: Int -> Int -> Int -> Int max3 a b c = max2 (max2 a b) c f :: Int -> Int f 1 = 0 f n = if n `mod` 2 == 0 then n `div` 2 else 3*n + 1 isDigit :: Char -> Bool isDigit ch = ('0' <= ch) && (ch <= '9') isLower :: Char -> Bool isLower ch = ('a' <= ch) && (ch <= 'z') -- no åäö in ASCII offset :: Int offset = ord 'A' – ord 'a' toUpper :: Char -> Char toUpper ch = chr (ord ch + offset) f' 1 = 0 f' n | n `mod` 2 == 0 = n `div` 2 | otherwise = 3*n + 1 life_length x | x == 1 = 0 | otherwise = 1 + life_length(f' x) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 14:50:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 14:50:58 -0000 Subject: [GHC] #13467: ghc: panic! (the 'impossible' happened), initTc: unsolved constraints In-Reply-To: <048.1ad32161a71717ab0f1d3a7a703634e4@haskell.org> References: <048.1ad32161a71717ab0f1d3a7a703634e4@haskell.org> Message-ID: <063.47dcfa42fa54bd8a7956db6fb07bd9a7@haskell.org> #13467: ghc: panic! (the 'impossible' happened), initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jhjonsson | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * os: MacOS X => Unknown/Multiple * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, which will be fixed in GHC 8.2. The issue arises because you're using functions that aren't defined. Here's the error message you get in GHC 8.2: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | module Main (main) where | ^ Bug.hs:58:18: error: Variable not in scope: (–) :: Int -> Int -> Int | 58 | offset = ord 'A' – ord 'a' | ^ }}} So define `(–)` and `main`, and the panic should go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 15:02:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 15:02:49 -0000 Subject: [GHC] #13415: Instance declarations don't recognize named wildcards In-Reply-To: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> References: <050.2259a5a0e085d8320b34d03ac7e0d8a8@haskell.org> Message-ID: <065.e11029cd4ecf4159dbcf86a1afac3e72@haskell.org> #13415: Instance declarations don't recognize named wildcards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13324 | Differential Rev(s): Phab:D3332 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => invalid Comment: Very well, I'll stop pursuing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 16:13:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 16:13:47 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.7cb44d411f8e6f3cc770f90ef7e91599@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.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 varosi): Is there a chance that issue to enter GHC 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 17:40:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 17:40:02 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.ffa53462baa3a296a1389b1fdea43f20@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @Awson. I have `-Wa,-mbig-objs` setup in every call, and I'm using binutils 2.28 which should have your patched included and I'm using a linker script to merge the sections back together. But I'm still getting an invalid exec format error from Windows when I try to run the exe. My assumption is that `-gc-sections` is removing a section it shouldn't be. Before I dive too much into this, did I miss a step? Since you seem to have a working version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 19:17:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 19:17:50 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.1cde104b602d1c5c279a057c0b6041a0@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 19:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 19:42:34 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.8bb90ad131c6d797932bf08dfb556159@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * Attachment "latest.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 19:43:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 19:43:08 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.5439aa9133127a01ad60198525559ad9@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): 1. Binutils 2.28 includes only non-essential part of my patch, the part that is important wasn't put there, so you need the whole patch; 2. Recent GHC string literals handling changes had required yet another tweak to binutils which I didn't bother to publish because of apparent lack of interest. Nonetheless, I attach the patch which, I believe, should do the thing for you. It is made against the current HEAD, but I think it works against 2.28 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 19:54:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 19:54:47 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.62c78b822316785fded6aeec14a091e5@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * Attachment "lscripts.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 19:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 19:55:02 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.24f1b45d25ba59e2bca3caaea0e41575@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Ah, and if you want already processed linker scripts here they are. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 19:59:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 19:59:40 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.e0d5ffc4595b98823652efb1f6c9e9c2@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks! I thought based on the timing that 2.28 contained them :) thought they were checked in, but probably after the branch? ABout the string literals I assume you mean string merging? GHC now generates a lot more string literals that are identical and should be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 20:19:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 20:19:27 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.2bc2f498f8eecbdb950846af4ce184b7@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:13 varosi]: > Is there a chance that issue to enter GHC 8.2? 8.2 has already branched, so I don't think there is any chance of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 20:24:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 20:24:32 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.47eaab08333c55372d576befa460b93c@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Nope, they were only partially checked in. If you follow the commit link in the last post of the [https://sourceware.org/bugzilla/show_bug.cgi?id=19254 discussion] you will understand that only 32-bit bugfix (no new features at all) was landed. The essential part was abandoned because of Simon Brenner's idea that we should fix things on the GHC side making section name generation scheme more "windowsish" which `binutils` already has support for. And yes, I meant string merging when writing about string literals handling. At least my patch solves **sections** merging problem here. To make proper string merging we should, I believe, go entirely different way. AFAIR Walter Bright had met exactly the same problem when developing his `D` compiler and he used `COMDAT` to solve it. He blogged about this a couple of months ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 20:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 20:30:27 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.ad33aa02cf9ad0601acd1fbdd9451bf6@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints, | SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: JoinPoints => JoinPoints, SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 20:31:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 20:31:59 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.daf72cc9f935142142d2455b2fc77bdb@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ah, great thanks for the info, this saves me a lot of time! Yes I see now what you mean. I can certainly change GHC to output the right section names, that at least lessens the maintenance burden a bit. both it and string merging are on my list for 8.4 (along with dynamic linking). I'll take a look at his blog post and see! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 20:58:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 20:58:24 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.7be1fc6ee0e752357459968e2e543507@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `f n @t` can already be valid and different from `f @t n` though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 21:12:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 21:12:42 -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.c305d39e5ee7684f7c0fbf7d37d18421@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:7 simonpj]: > Great work. There is definitely a space leak here and it should not be to hard to find. Some ideas > > * In `CoreLint.lintSingleBinding` you'll find a series of tests. If you comment then out one by one, you'll find when the space leak comes back. That test must be forcing the offending bit of `IdInfo`. I commented out `lintIdUnfolding` and then the leak came back with `-dcore-lint` enabled. > * Does the leak happen when you use `-dshow-passes`? That shows the size of eac intermediate, and `exprSize` is deliberately strict (see `CoreStats.bndrSize`). I've been using `-v`, which I think shows the same information, and it doesn't eliminate the leak. > You could try making `CoreSeq.megaSeqidInfo` actually force the unfolding info (currently commented out) and see if that helps. (I'm not sure WHY it is commented out, incidentally.) Instead I defined a new version of `seqUnfolding`, based on `lintIdUnfolding`, and added it to `megaSeqIdInfo`: {{{#!hs miniSeqUnfolding :: Unfolding -> () miniSeqUnfolding (CoreUnfolding { uf_tmpl = e, uf_src = src }) | isStableSource src = seqExpr e miniSeqUnfolding (DFunUnfolding { df_con = con, df_bndrs = bndrs , df_args = args }) = seqExprs args miniSeqUnfolding _ = () }}} This was enough to make the leak go away, even without using `-dcore- lint`. Both the `CoreUnfolding` and `DFunUnfolding` cases are needed to make the leak go away; or perhaps there are two leaks. (Without the `isStableSource` guard, the runtime exploded.) So there are thunks in the expressions inside unfoldings which, I believe, point to old versions of the Core program. I'm going to continue invesigating but I'm out of time for today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 21:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 21:29:26 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.243e50bba79bf9d233c431270cc43686@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3370 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"30d68d630c1685bb81ec4afdaf6d483ba8aafd38/ghc" 30d68d63/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30d68d630c1685bb81ec4afdaf6d483ba8aafd38" Make unsafeInterleaveST less unsafe * Make `unsafeInterleaveST` use `noDuplicate#` like `unsafeInterleaveIO` does to prevent the suspended action from being run in two threads. * In order to accomplish this without `unsafeCoerce#`, generalize the type of `noDuplicate#`. * Add `unsafeDupableInterleaveST` to get the old behavior. * Document unsafe `ST` functions and clean up some related documentation. Fixes #13457 Reviewers: austin, hvr, bgamari, ekmett Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3370 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 22 21:37:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Mar 2017 21:37:24 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.643775f3385f929e070e05271cbb4588@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3370 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 01:21:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 01:21:15 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.1a032f783e203a199a5e2b965517c5a3@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The question always is: what type variable is being instantiated? Perhaps `f` has the type `forall a. a -> forall b. b -> (a, b)`. Then `f @t n` will be different from `f t @n`. And, as Stephanie and I describe in [http://cs.brynmawr.edu/~rae/papers/2016/type-app/visible-type-app.pdf our paper], there doesn't seem to be a way to add in extra flexibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:14:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:14:21 -0000 Subject: [GHC] #13219: CSE for join points In-Reply-To: <049.356ff616fe8ea0d0d5220b9d68f67a02@haskell.org> References: <049.356ff616fe8ea0d0d5220b9d68f67a02@haskell.org> Message-ID: <064.c5febcbcb4e4bbe75cd348055da7c39d@haskell.org> #13219: CSE for join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints, | 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 ezyang): * keywords: JoinPoints => JoinPoints, CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:14:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:14:33 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.fc0909a3d394d7b92a0fa63bd03969ef@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | 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: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:15:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:15:15 -0000 Subject: [GHC] #701: Better CSE optimisation In-Reply-To: <047.e2c9c1769e87443e2852b517c052804c@haskell.org> References: <047.e2c9c1769e87443e2852b517c052804c@haskell.org> Message-ID: <062.96133814dfb6b24ba39c336870f11358@haskell.org> #701: Better CSE optimisation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.1 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:16:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:16:13 -0000 Subject: [GHC] #5344: CSE should look through coercions In-Reply-To: <046.337028ce6bbff67a50874240336d3596@haskell.org> References: <046.337028ce6bbff67a50874240336d3596@haskell.org> Message-ID: <061.1def8186a960c82ed7dbdc86522d947f@haskell.org> #5344: CSE should look through coercions -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.0.3 Resolution: | Keywords: CSE 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 ezyang): * keywords: cse => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:18:28 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.762fc981d9a994a19d0416116e18452c@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: | Keywords: CSE 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 ezyang): * keywords: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:18:47 -0000 Subject: [GHC] #7596: Opportunity to improve CSE In-Reply-To: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> References: <046.cff0215a26be1de4993e285f1d4ab495@haskell.org> Message-ID: <061.1338a8af8974ccc79fc76831a6a3bbce@haskell.org> #7596: Opportunity to improve CSE -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: CSE 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 ezyang): * keywords: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 02:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 02:42:34 -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.d82759b1472c2ce34a51c994577ca5dd@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | 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): I'm on it. Indeed, I believe I've fixed this, but need to rebuild to be sure. The problem is the checks from #9122 that try to make sure we're not `unsafeCoerce`ing between types with incompatible representations. But when we look to see about the representations involved here, the types don't have representations, so GHC falls over. What's annoying is that the user-written program is safe in this regard. It's the coercion optimizer that rewrites an `unsafeCoerce` from a lifted type to a lifted type (`Any -> Any` to `a -> b`) to two `unsafeCoerce`s involving `a` and `b` separately. Thus, an alternate fix would be to have the coercion optimizer look for precisely this scenario and avoid pushing the unsafe coercion through the `->`. I haven't done this for two reasons: 1. Failing the checks from #9122 (which I've never fully agreed with) is a sometimes-unavoidable consequence of a sketchy `unsafeCoerce`. The workaround if you're in this scenario is not to use `-dcore-lint`. The original program is pretty sketchy here, and so requiring that user to avoid `-dcore-lint` may be reasonable. 2. It's quite annoying (and potentially computationally expensive) to do this check in the coercion optimizer. The check is necessary only when the user is willfully misbehaving, and the better citizens shouldn't have to pay for it every time. Regardless, GHC shouldn't panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 03:43:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 03:43:10 -0000 Subject: [GHC] #13456: GHCi run commands that are not documented in Users Guide Documentation In-Reply-To: <044.bd64a38557199b0514ccf5021317207d@haskell.org> References: <044.bd64a38557199b0514ccf5021317207d@haskell.org> Message-ID: <059.4c8abc90d3a46084fc33a054a8ef8d99@haskell.org> #13456: GHCi run commands that are not documented in Users Guide Documentation -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MarcelineVQ): Interesting:\\ From a little testing it seems that commands that begin with a letter can be run with `::command` instead of `:command`\\ Some other commands like `:! :{ :` do not allow `::! ::{ ::`\\ Oddly `::?` is accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 05:05:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 05:05:59 -0000 Subject: [GHC] #13430: Can't scope type variables when pattern matching on GADTs In-Reply-To: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> References: <047.850e915aac2b6c1a93b3608b6102c94b@haskell.org> Message-ID: <062.c0d145fcf5967578c8ad3f0229a3b110@haskell.org> #13430: Can't scope type variables when pattern matching on GADTs -------------------------------------+------------------------------------- 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): > the type signature is matched before we get to the A part That may be the case, but it's quite strange that I wrote `A :: Foo Bool` in the GADT definition, but I can't write `A :: Foo Bool` in the pattern. `A` certainly does have that type. I think the notation is natural enough that it should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 05:29:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 05:29:06 -0000 Subject: [GHC] #13468: GHC stubbornly produces dead code for empty case with type family Message-ID: <045.25c4bffd8ac85aad2b0082017a4952a2@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following instance: {{{#!hs data Void instance Generic Void where type Rep Void = V1 from x = case x of to x = case x of }}} The pattern checker, when enabled, correctly determines that both `from` and `to` cover all cases. Yay! In order to do this, it has to reduce the `Rep Void` type family application. The optimizer, on the other hand, does not perform this reduction, presumably because it is not known to terminate. Unfortunate in this case, but fine, I suppose. Here's where it gets really unfortunate. If I write {{{#!hs to (x :: V1 r) = case x of }}} then the type checker already has to do the work of unifying `Rep Void` with `V1 r`, but the optimizer doesn't take advantage of it! With `-O2 -ddump-simpl ...`, I get {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} lvl_r2IT :: Addr# lvl_r2IT = "Phantom.hs:18:20-23|case"# -- RHS size: {terms: 2, types: 2, coercions: 0, joins: 0/0} $fGenericVoid1 :: Void $fGenericVoid1 = patError lvl_r2IT -- RHS size: {terms: 6, types: 7, coercions: 0, joins: 0/0} $fGenericVoid_$cto :: forall x. Rep Void x -> Void $fGenericVoid_$cto = \ (@ x_a2HT) (ds_d2J8 :: Rep Void x_a2HT) -> case ds_d2J8 of { __DEFAULT -> $fGenericVoid1 } }}} That seems rather unfortunate. The only workaround I've found so far is to actually write a function just to constrain the type: {{{#!hs absV :: V1 r -> a absV x = case x of instance Generic Void where ... to = absV }}} Finally, this is clean: {{{ -- RHS size: {terms: 5, types: 12, coercions: 0, joins: 0/0} absV :: forall r a. V1 r -> a absV = \ (@ r_a2Hy) (@ a_a2Hz) (x_a1fi :: V1 r_a2Hy) -> case x_a1fi of { } -- RHS size: {terms: 4, types: 7, coercions: 0, joins: 0/0} lvl_r2IF :: forall x. V1 x -> Void lvl_r2IF = \ (@ x_a2HP) (eta_B1 :: V1 x_a2HP) -> absV eta_B1 }}} I suppose I could add `GHC.Generics.Absurd` just to write the `absV` function for `Generic` and `Generic1` deriving, but that seems more than a little silly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 06:19:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 06:19:09 -0000 Subject: [GHC] #13460: StandardTargets wiki page is out of date In-Reply-To: <043.971d9ccd865651dc554f6b0f52e79710@haskell.org> References: <043.971d9ccd865651dc554f6b0f52e79710@haskell.org> Message-ID: <058.64b8ea98625557c0bc979b2af54d17f7@haskell.org> #13460: StandardTargets wiki page is out of date -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MarcelineVQ): I had the same issue recently, it turns out that this is most commonly due to document building flags being switched off from the flavor chosen in mk/build.mk Check your mk/config.mk for {{{ BUILD_SPHINX_HTML = YES BUILD_SPHINX_PDF = YES }}} If these are YES instead of NO in config.mk then you can add them to the end of your build.mk to over-ride the NO that is likely set in your current build flavour. If that's too vague check out https://ghc.haskell.org/trac/ghc/wiki/Building/Docs which should be clearer. This should work for html and pdf, I'm not sure ps is made anymore since I don't see rules for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 06:40:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 06:40:05 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.1c567488df8f231ba33bd8d37d02a39f@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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 ezyang): It's been two years since I last poked this, and since then Richard Eisenberg merged kind equalities. This means that the match implementation I prototyped no longer works: matching has been rolled up with a very general unification algorithm, which keeps track of kind coercions so that the resulting substitutions are well typed. So I am uncertain whether or not we can still carve out the "matching" portion of the algorithm without having to handle all of this extra logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 08:10:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 08:10:31 -0000 Subject: [GHC] #13469: -fdefer-type-errors for Backpack Message-ID: <045.82608267e88ca7118e8fcc4f7b65d970@haskell.org> #13469: -fdefer-type-errors for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be great if `-fdefer-type-errors` worked with Backpack. There are two senses in which it could work: 1. When matching signatures, if the instantiating module didn't provide a required function, we could just create one out of thin air so we can continue building. 2. When matching signature, if the implementation doesn't match the signature, we instead create a deferred type error. (2) is more difficult because it basically requires us to solve #12703. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 08:58:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 08:58:22 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.dbb5cb68e9c9665eae1f382b460ccc4a@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I still haven't been able to repro this. I used exactly the `build.mk` above, and I've built all of nofib with {{{ make NoFibRuns=0 EXTRA_HC_OPTS="+RTS -p -RTS" }}} without a single segfault, and I have a pile of `.prof` files. This is Linux/x86_64, my tree is master @ bf3952e. Is there anything that might be different about my environment compared to yours that might account for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 09:02:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 09:02:47 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.dffa467617781f88ffba72cfb41f343d@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'll try building exactly from 6ebfbdfb64cb8bb5c2ddaf2ad3ad350755c5eb2b as in the description. Also presumably your `build.mk` also has this: {{{ ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif }}} otherwise `BuildFlavour` has no effect, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 09:14:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 09:14:35 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.76081f03dd14214824757a6222af8cda@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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 ezyang): There is a more up-to-date version of the code at https://github.com/ezyang/triemap/blob/master/TrieMap.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 09:51:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 09:51:45 -0000 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> References: <045.82dbf1ade5f39047db873a9122708a49@haskell.org> Message-ID: <060.649f6d5df25aa9f99b3c1c7238fe6e7b@haskell.org> #149: missed CSE opportunity -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: | optimisations, CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: optimisations => optimisations, CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 09:52:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 09:52:03 -0000 Subject: [GHC] #947: ghc -O space leak: CSE between different CAFs In-Reply-To: <051.1df58c16aae1e728225d8b97c614f4ea@haskell.org> References: <051.1df58c16aae1e728225d8b97c614f4ea@haskell.org> Message-ID: <066.99d385291dfd183880553aa084d6317f@haskell.org> #947: ghc -O space leak: CSE between different CAFs ---------------------------------+------------------------------ Reporter: int-e@… | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.5 Resolution: | Keywords: CSE Operating System: Linux | Architecture: x86 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 Mar 23 09:52:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 09:52:42 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.7e38fb1f05a39de8aa60078488764a26@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 10:31:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 10:31:06 -0000 Subject: [GHC] #13470: Pattern synonyms bind variables out of scope Message-ID: <051.2f4dd426cb769effcd9b2e38f2ab45c1@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Wasn't sure what to call this ticket: {{{#!hs {-# Language PatternSynonyms #-} pattern XInstrProxy :: (Bool -> Bool) -> a pattern XInstrProxy not <- _ }}} This works fine, is it intended? It came as some surprise to me when I was renaming type variables only to find it still working even though I hadn't changed the variable in the `ViewPattern` {{{#!hs import Data.Tagged pattern XInstrProxy proxy <- ((\(Proxy::Proxy descr) -> Proxy::Proxy (XInstr descr)) -> ty) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 13:21:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 13:21:40 -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.faaebdc5174493c8a860dff71de0102e@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => GHC accepts invalid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 13:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 13:46:29 -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.e5502803633dbf41fd2ff535fbfacb52@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 13:58:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 13:58:24 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.b0edc08c17dabd2a40cf90384302da92@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints, | SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 14:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 14:21:09 -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.c17fcf91b9a9ecc9f5171fa7ce5d9735@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3377 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D3377 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 14:58:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 14:58:51 -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.692a6d8d2b13fa9304dee01cef3457f0@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, here is a much easier way to trigger this panic that doesn't require profiling: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedTuples #-} module Bug where import GHC.Exts (TYPE) class Foo (a :: TYPE rep) where bar :: forall (b :: TYPE rep2). (a -> a -> b) -> a -> a -> b baz :: forall (a :: TYPE rep). Foo a => a -> a -> (# a, a #) baz = bar (#,#) }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170322 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_12 :: TYPE k0_10) k0_10 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 16:47:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 16:47:02 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.030aa80c60d2827637b25eec5f7fb51c@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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): The new algorithm should be just as amenable to this new implementation as the old one. Yes, it's all tied in with unification (and there are kind equalities) but don't let that scare you. In particular, the kind coercion passed down through the algorithm is only important in the `TyVar` case (and, perhaps, in the `ForAllTy` case, where it's propagated. Does this ever actually trigger? Who knows). So I believe this shouldn't cause any undue difficulty in realizing your idea (which I think is great). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 16:55:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 16:55:08 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC Message-ID: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi,\\ I tried to compile GHC on my computer.\\ by compiling GHC under Linux I got this error message.\\ {{{ compiler/ghc.mk:588: recipe for target 'compiler/stage2/build/DynFlags.o' failed make[1]: *** [compiler/stage2/build/DynFlags.o] segmentation fault Makefile:122: recipe for target 'install' failed make: *** [install] Error 2 }}} on my computer Linux runs on VirtualBox.\\ the problem is probably with my hardware but as I know nothing I tell you this issue.\\ {{{ ~/ghc/inplace/bin$ /ghc-stage1 --version The Glorious Glasgow Haskell Compilation System, version 8.3.20170322 }}} Hope this help\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 18:03:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 18:03:42 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) Message-ID: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | 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: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently, GHC stopped working for me on my Windows 10 machine. I strongly reckon this has to do with my recent switch to the Windows Insider Fast-Ring builds: I'm currently on version 1703, build 15058. Here's what I got in a mingw shell (ghc 8.0.2 from the core HP, same output with PowerShell): {{{#!hs $ cat << EOF > hw.hs > main = putStrLn "hi" > EOF $ ghc hw.hs [1 of 1] Compiling Main ( hw.hs, hw.o ) `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) }}} This seems to be independent of the GHC version, as I tried `stack setup` with different stack LTSs, which hit the same error when compiling some sanity checks. Currently I'm about to reverting back to Slow-Ring, but when the actual switch is to happen is only known to Bill Gates himself it seems. I believe it will then work again, but this is something to look out for when/if the Fast-Ring changes eventually make it into Windows stable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 18:06:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 18:06:22 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.e00d7029f13630ccbb17ef0d08a8ce37@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | 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: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This seems to be related: https://github.com/commercialhaskell/stack/issues/2998 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 18:11:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 18:11:11 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.b56376890609677b70b473a2d49987d4@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | 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: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: 13411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => 13411 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 19:23:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 19:23:17 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound Message-ID: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | 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: -------------------------------------+------------------------------------- In GHCi 8.0.2 {{{ >>> import Language.Haskell.TH >>> import Language.Haskell.TH.Quote >>> :set -XQuasiQuotes >>> quoter = QuasiQuoter { quotePat = varP . mkName } >>> [quoter|x|] = 1 >>> x error: Variable not in scope: x }}} I think "x" ought to be 1. Previous versions of GHCi don't let me be so free about defining and using quasiquotes, so here is a minimal example with modules: {{{ -- In QQ.hs module QQ where import Language.Haskell.TH import Language.Haskell.TH.Quote quoter :: QuasiQuoter quoter = QuasiQuoter { quotePat = varP . mkName } }}} and {{{ -- In Main1.hs module Main1 where import QQ [quoter|x|] = 1 main = print x }}} With GHC 7.10.3 this compiles (and prints "1" when run), but in GHC 8.0.2 this complains "x" is not in scope. The same problem manifests itself when the pattern quasi quote is used in a "let" binding. Peculiarly, this appears ''not'' to affect cases where the pattern is a function argument. The following compiles and runs (printing "1") on both 7.10.3 and 8.0.2. {{{ -- In Main2.hs module Main2 where import QQ f [quoter|x|] = x main = print (f 1) }}} I understand there were some changes around splices and declaration groups (which presumably are part of why GHCi plays with quasi quotes), so I'm not sure this is really a bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 19:24:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 19:24:16 -0000 Subject: [GHC] #13474: GHC HEAD regression: Prelude.!!: index too large Message-ID: <050.a141e95defa8fbf6040db0fc9540e547@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 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: -------------------------------------+------------------------------------- `git-annex-6.20170321` from Hackage currently fails to build with GHC 8.2.1 and HEAD because it triggers this panic. Here's a simplified example that exhibits the issue: {{{#!hs {-# LANGUAGE BangPatterns #-} module Command.Vicfg where import qualified Data.Map as M class Default a where def :: a instance Default Int where def = 0 data Cfg = Cfg { cfgTrustMap :: M.Map Int Int , cfgGroupMap :: M.Map Int Int } defCfg :: Cfg -> Cfg defCfg curcfg = Cfg { cfgTrustMap = mapdef $ cfgTrustMap curcfg , cfgGroupMap = mapdef $ cfgGroupMap curcfg } where mapdef :: Default v => M.Map k v -> M.Map k v mapdef = M.map (const def) }}} {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs -O1 [1 of 1] Compiling Command.Vicfg ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170321 for x86_64-unknown-linux): Prelude.!!: index too large }}} Note: * You need optimization (`-O1` or `-O2`) enabled. * You need to import `Map`/`map` for this panic to trigger, it seems, as redefining `Map`/`map` locally makes it work again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 20:01:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 20:01:44 -0000 Subject: [GHC] #13475: Possible missing case in ghc-pkg Message-ID: <044.0e768d0d4ad3740af2f27e17216ccc78@haskell.org> #13475: Possible missing case in ghc-pkg -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.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: -------------------------------------+------------------------------------- I saw this while compiling {{{ utils\ghc-pkg\Main.hs:761:25: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly }}} I don't know if this is indicative of a bug in the implementation or not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 21:47:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 21:47:03 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC In-Reply-To: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> References: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> Message-ID: <059.beb85f1dc10e6f90d51904392ec1a5a7@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: The fact that this is `DynFlags` is suspicious. That module in particular takes quite a bit of memory to compile (especially at the moment, due to a known bug). Moreover, we have seen reports of segfaults on running out of memory. How much memory does your guest have available to it? Is this crash reproducible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 21:47:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 21:47:10 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC In-Reply-To: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> References: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> Message-ID: <059.7a338f6e01043c13903ed56bcbbe0aa8@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 22:21:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 22:21:11 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.9cdad0e1a0628d7e57d4f45f129b323e@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, I should have been more specific: essentially I appended the cited snippet to `build.mk`. Very odd that you have been unable to reproduce this. I'm looking in to what might differ in our environments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 22:21:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 22:21:30 -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.848447e7ea32440af05debedd195c8d8@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I now suspect this leak doesn't really have anything to do with unfoldings in particular. It just shows up that way as a result of the fact that the evaluation of `coreBindsSize` in the simplifier loop forces most parts of the Core program, but does not force unfoldings (as mentioned in comment:7). It seems that the simplifier repeatedly traverses these stable `Core` and `DFun` unfoldings but there is some part of the new unfolding that the next simplifier iteration does not look at that retains a reference to the old version of the program. I also suspect that the evaluation of `coreBindsSize` in the simplifier loop should be unnecessary if there weren't space leaks in the simplifier, and if we got rid of it we would see this space leak not just in unfoldings but everywhere, and possibly in more programs, which might make it easier to track down. I spent a lot of time using some RTS functions to dump heap representations and in particular to look for thunks and (using DWARF information) find where they were coming from. But it turned out not to be a good approach because of how the simplifier is structured. Basically, the output of each simplifier iteration contains a large number of thunks, of which most (but apparently not all) will be forced by the next simplifier iteration, and replaced by a large number of new thunks. I don't know how to find only the thunks that aren't getting forced by this process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 22:34:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 22:34:49 -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.267b5fc4c5abc5ce9ffab775e810b737@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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > `git-annex-6.20170321` from Hackage currently fails to build with GHC > 8.2.1 and HEAD because it triggers this panic. Here's a simplified > example that exhibits the issue: > > {{{#!hs > {-# LANGUAGE BangPatterns #-} > module Command.Vicfg where > > import qualified Data.Map as M > > class Default a where > def :: a > > instance Default Int where > def = 0 > > data Cfg = Cfg > { cfgTrustMap :: M.Map Int Int > , cfgGroupMap :: M.Map Int Int > } > > defCfg :: Cfg -> Cfg > defCfg curcfg = Cfg > { cfgTrustMap = mapdef $ cfgTrustMap curcfg > , cfgGroupMap = mapdef $ cfgGroupMap curcfg > } > where > mapdef :: Default v => M.Map k v -> M.Map k v > mapdef = M.map (const def) > }}} > > {{{ > $ /opt/ghc/8.2.1/bin/ghc Bug.hs -O1 > [1 of 1] Compiling Command.Vicfg ( Bug.hs, Bug.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.0.20170321 for x86_64-unknown-linux): > Prelude.!!: index too large > }}} > > Note: > > * You need optimization (`-O1` or `-O2`) enabled. > * You need to import `Map`/`map` for this panic to trigger, it seems, as > redefining `Map`/`map` locally makes it work again. New description: `git-annex-6.20170321` from Hackage currently fails to build with GHC 8.2.1 and HEAD because it triggers this panic. Here's a simplified example that exhibits the issue: {{{#!hs module Command.Vicfg where import qualified Data.Map as M class Default a where def :: a instance Default Int where def = 0 data Cfg = Cfg { cfgTrustMap :: M.Map Int Int , cfgGroupMap :: M.Map Int Int } defCfg :: Cfg -> Cfg defCfg curcfg = Cfg { cfgTrustMap = mapdef $ cfgTrustMap curcfg , cfgGroupMap = mapdef $ cfgGroupMap curcfg } where mapdef :: Default v => M.Map k v -> M.Map k v mapdef = M.map (const def) }}} {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs -O1 [1 of 1] Compiling Command.Vicfg ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170321 for x86_64-unknown-linux): Prelude.!!: index too large }}} Note: * You need optimization (`-O1` or `-O2`) enabled. * You need to import `Map`/`map` for this panic to trigger, it seems, as redefining `Map`/`map` locally makes it work again. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 22:45:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 22:45:46 -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.0e6071806f5698c465d8a5557fc37cff@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very useful to know that the stable unfoldings alone are enough. I have an idea. Consider `Simplify` line 1005 {{{ simplExprF1 env (Type ty) cont = ASSERT( contIsRhsOrArg cont ) rebuild env (Type (substTy env ty)) cont }}} Yikes! That `(substTy env ty)` is a thunk that the simplifier may not force; and that'll hold onto `env` which is disater. Replace the RHS by {{{ = do { ty' <- simplType env ty ; retbuild env (Type ty') cont } }}} You'll see that `simplType` is careful to `seq` on substituted type; and `TyCoRep.substTy` has the property (I think, though it is sadly not documented) that `seq`ing on the result is enough to push the substitution right through the type (see the `$!` calls in `subst_ty`. It is very unsatisfactory that this kind of leak is SO hard to find. But finding it will help ALL programs! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 23:10:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 23:10:56 -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.8612d8dfd61ead6172cc3971b04e2e72@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 simonpj): Stunning. Here's an even small test case {{{ module T13474 where import qualified Data.Map as M class Default a where def :: a foo :: Default a => b -> a foo x = def mapdef :: Default v => M.Map k v -> M.Map k v mapdef = M.map foo }}} With a debug compiler I get {{{ matchN map/coerce [TYPE: a_a1eq, TYPE: b_a1er, TYPE: k_a1ep, (\ (v_a1et :: a_a1eq) -> v_a1et) `cast` (_R -> $r$dCoercible_a1es :: ((a_a1eq -> a_a1eq) :: *) ~R# ((a_a1eq -> b_a1er) :: *))] [TYPE: v_aJ1, TYPE: v_aJ1, TYPE: k_aJ2, (\ _ [Occ=Dead] -> $dDefault_aJ4) `cast` (_R -> N:Default[0] _N :: ((v_aJ1 -> Default v_aJ1) :: *) ~R# ((v_aJ1 -> v_aJ1) :: *))] ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 8.3.20170316 for x86_64-unknown-mingw32): ASSERT failed! 0 Constraint Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1246:22 in ghc:Outputable assertPprPanic, called at compiler\types\Coercion.hs:898:49 in ghc:Coercion mkNthCo, called at compiler\types\Coercion.hs:430:5 in ghc:Coercion mkRuntimeRepCo, called at compiler\types\Coercion.hs:343:36 in ghc:Coercion splitTyConAppCo_maybe, called at compiler\specialise\Rules.hs:806:10 in ghc:Rules Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler\utils\Outputable.hs:1244:5 in ghc:Outputable assertPprPanic, called at compiler\types\Coercion.hs:898:49 in ghc:Coercion mkNthCo, called at compiler\types\Coercion.hs:430:5 in ghc:Coercion mkRuntimeRepCo, called at compiler\types\Coercion.hs:343:36 in ghc:Coercion splitTyConAppCo_maybe, called at compiler\specialise\Rules.hs:806:10 in ghc:Rules }}} I'm still not sure what's actually wrong, but something is very wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 23:58:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 23:58:06 -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.4a2f15518420ac21c4d05cafb38340c5@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: The commit that caused this regression is somewhat surprising. It's d2f48495ebe79b5ef5808a4891b3d03dfd297d35: {{{ From d2f48495ebe79b5ef5808a4891b3d03dfd297d35 Mon Sep 17 00:00:00 2001 From: Ben Gamari Date: Sun, 26 Feb 2017 15:33:54 -0500 Subject: [PATCH] Coercion: Try dropping constraintIsLifted axiom While working through the FunCo patch I encountered some lint issues which suggested that `Constraint` wasn't being considered equal to `TYPE 'LiftedRep`. Consequently I introduced this axiom and associated messy ball of logic to explicitly coerce `Constraint`. However, as @goldfire points out on D3208 this really shouldn't be necessary. Indeed, I tried ripping out the axiom and things appear to just work. I suspect the issue motivating the axiom was a bug elsewhere in the FunCo branch that I fixed during development. }}} Thoughts, Ben? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 23 23:58:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Mar 2017 23:58:15 -0000 Subject: [GHC] #13445: Fix 32 bit Windows build of GHC 8.2 In-Reply-To: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> References: <044.2d709fafb72d200c5d2215d6497ffe71@haskell.org> Message-ID: <059.f51e0e98baac127659e0871179f8a296@haskell.org> #13445: Fix 32 bit Windows build of GHC 8.2 ----------------------------------------+---------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #13431 | Differential Rev(s): Phab:D3362 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged in 4a0b1dd8fe165a3f869824ad3e63fb0a5a1eb99f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 00:16:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 00:16:30 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.a1e8da1d18fd23ceee5f86eb35e917fa@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Actually, it looks like this is equivalent to a more general TH issue (with a smaller minimal example). The following compiles in 7.10.3 but not 8.0.2 {{{ {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH main = let $(varP $ mkName "x") = 1 in print x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 00:51:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 00:51:09 -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.a8c59594a085ab565744011dee20c01e@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 goldfire): Just took a look. The problem is that we're trying to make a `NthCo 0 g` where one of `g`'s types is `Constraint`. Of course, `Constraint` is identical to `TYPE LiftedRep`, so using `NthCo` is sensible, but GHC gets confused. I haven't tested it, but I'm nearly positive that merging Phab:D3316 would fix this. That patch is held up on discussions in #11715. It all boils down to a design question, and I don't feel like the discussion there has settled toward any consensus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 01:01:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 01:01:15 -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.1b6816a19ec6b524810174fefe171129@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3377 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 Mar 24 01:20:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 01:20:54 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.4a15cb1f737fd95e9116b36b25aff564@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 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: facundominguez (added) * component: Compiler => Template Haskell Comment: This regression appeared between GHC 8.0.1 and 8.0.2. I tracked it down to commit 8d63419478074728eb03082787ea51d498b3e62e: {{{ From 8d63419478074728eb03082787ea51d498b3e62e Mon Sep 17 00:00:00 2001 From: =?utf8?q?Facundo=20Dom=C3=ADnguez?= Date: Wed, 6 Jul 2016 06:48:27 -0300 Subject: [PATCH] Have addModFinalizer expose the local type environment. Summary: This annotates the splice point with 'HsSpliced ref e' where 'e' is the result of the splice. 'ref' is a reference that the typechecker will fill with the local type environment. The finalizer then reads the ref and uses the local type environment, which causes 'reify' to find local variables when run in the finalizer. }}} Thoughts, Facundo? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 02:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 02:07:42 -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.ca73ba3f26248d5e776f9e0b4f8182a0@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 bgamari): Ahh yes. I **knew** there was a reason why we needed that logic. I'm about to merge Phab:d3316 and after I do so I'll add a test and confirm that this is fixed. If not I'll likely just revert the commit mentioned in comment:3 on `ghc-8.2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 02:22:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 02:22:48 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.e158b41eb2d4748e23edb9b1d300b2c6@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: 13411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * milestone: => 8.2.1 Comment: Phyx, does this look like #13411 to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 02:40:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 02:40:30 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.f754f74c0e9eb03948de9594b07d3e01@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3370 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 02:52:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 02:52: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.b51dac756505e5875e83dd3aae21371a@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Regarding comment:24, Interesting. This is certainly the same panic, but the cause here is much different. Previously we were falling victim to ticks getting put between an unboxed tuple type constructor and its applied `RuntimeRep`s. In contrast, here we are seeing a call to `runtimeRepPrimRep` while generating code for, {{{#!hs Bug.baz :: forall a_a2DY. Bug.Foo a_a2DY => a_a2DY -> a_a2DY -> (# a_a2DY, a_a2DY #) [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] Bug.baz = \ (@ (rep_a2F2 :: GHC.Types.RuntimeRep)) (@ (a_a2F3 :: TYPE rep_a2F2)) ($dFoo_s2P9 [Occ=Once] :: Bug.Foo a_a2F3) -> let { sat_s2Pa [Occ=Once] :: a_a2F3 -> a_a2F3 -> (# a_a2F3, a_a2F3 #) [LclId, Str=DmdType] sat_s2Pa = \ (eta_B2 [Occ=Once] :: a_a2F3) (eta_B1 [Occ=Once] :: a_a2F3) -> (# eta_B2, eta_B1 #) } in ($dFoo_s2P9 `cast` (Bug.N:Foo[0] _N _N :: (Bug.Foo a_a2F3 :: GHC.Types.Constraint) ~R# ((forall b_a2DW[sk]. (a_a2F3 -> a_a2F3 -> b_a2DW[sk]) -> a_a2F3 -> a_a2F3 -> b_a2DW[sk]) :: *))) @ 'GHC.Types.UnboxedTupleRep @ (# a_a2F3, a_a2F3 #) sat_s2Pa }}} I suspect the issue here is the cast, Great testsuite material, Ryan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 04:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 04:13:50 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.4c806d9d2c946f1500f233697a936c70@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I have once again reproduced this. Unfortunately I realized that you actually need to cherry-pick a few patches on top of 6ebfbd as it doesn't build on its own. One of these patches fixes a silly typo. The other is my rather crude fix to #13233 (Phab:D3063) ensuring we don't attempt to tick string literals. I'm a bit suspicious of the latter, but the build doesn't build any lint warnings so I've been operating under the assumption that it's safe. Without further ado, here is a full repro, {{{ #!/bin/bash -e git clone git://git.haskell.org/ghc --recursive ghc-T13433 cd ghc-T13433 cat >mk/build.mk <<'EOF' BuildFlavour = prof ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcStage2HcOpts += -dcore-lint -dcmm-lint define add_mods_flag = $(foreach mod,$(2),$(eval $(basename $(mod))_HC_OPTS += $(1))) endef $(call add_mods_flag,-fprof-auto,$(wildcard compiler/typecheck/*.hs)) STRIP_CMD = : EOF ./boot ./configure make -j8 wget https://ghc.haskell.org/trac/ghc/raw-attachment/ticket/13387/Main.hs inplace/bin/ghc-stage2 -O2 -fforce-recomp Main.hs +RTS -p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 05:34:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 05:34:38 -0000 Subject: [GHC] #13457: unsafeInterleaveST is too unsafe In-Reply-To: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> References: <045.d822adfc6fd234c5c5c422c4c0af65b3@haskell.org> Message-ID: <060.c9f8d8d6ce6f59a7fe3073ae0a6bfa62@haskell.org> #13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.1 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:D3370 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 167548f4cd087535a6c4c9fc642b60669b4dc019. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 05:36:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 05:36:01 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.c5e57fda53d50de2e563b82d704921e9@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3364 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to GHC 8.2 with 7141a183a968b3418c113b234de9f75a0a735766. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 05:36:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 05:36:29 -0000 Subject: [GHC] #13444: Disable diagnostic coloring by default In-Reply-To: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> References: <042.4014621dfe6bc045d2011dc58a4b88b7@haskell.org> Message-ID: <057.ee3bd609ea5b8f88ed280ffc62152750@haskell.org> #13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | 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: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3364 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: And to master with adf27d614f8a48d8dcf2d4e2e7872f7b3f818364. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 05:57:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 05:57:36 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.dd560b79a1b1e1828909304eef589ef1@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: 13411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate Comment: Yup, this is a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 09:11:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 09:11:04 -0000 Subject: [GHC] #13476: Coercion maching in RULES is fragile Message-ID: <046.2180d876ae517bd592cf11998da3e15c@haskell.org> #13476: Coercion maching in RULES is fragile -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- If we have a cast or coercion in the LHS of a rule, matching against is is very fragile. This came up in #13474. Consider the `map/coerce` rule in `GHC.Base`. (There is a similar one in `containers:Data.Map.Internal`.) Initially it looks like this: {{{ RULE "map/coerce" forall a b (x::a) (c::a~b) (xs::[a]). map (\x. x |> c) xs = xs |> [c] }}} In typechecking and desugaring rules we are careful only to use coercion ''variables'' in a cast on the LHS, so that matching is more likely to succeed. After all, we never want to match on ''the way a proof is done'', only on the ''result of the proof''. However, suppose some target expression (to which we would like to apply the rule) looks like {{{ map (\(y::ty). y |> ec) exs }}} The simplifier (see `Note [Casts and lambdas]` in `SimplUtils`) swizzles the cast outside the lambda, thus {{{ map ((\ (y::ty). y) |> ( -> ec)) exs }}} Now it's not so easy to match the rule, becuase in one the cast is outside the lambda and in the other it is inside. The casts are making matching fragile. What to do? == Plan A (current) == Currently, we run the simplifier on the rule LHS, so that the same simplifications apply. But now we get {{{ RULE "map/coerce" forall a b (x::a) (c::a~b) (xs::[a]). map ((\x. x) |> ( -> c) xs = xs |> [c] }}} And now the coercion on the LHS has structure; ''and'' we must decompose that structure to bind the `c` to use it on the RHS. So `Rules.match_co` actually matches the structure of coercions (sigh); but is only partially implemented (a) because it is tedious and (b) because it should not be necessary. Pragmatic but unsatisfactory. == Plan B (possible) == Do not simplify the LHS of rules, so that casts always have a simple coercion variable. But make matching work "modulo casts". Something like this: {{{ match :: PatternExpr -> TargetExpr -> Coercion -> ...result... -- Invariant: match pat e c == match pat (e |> c) Refl -- That is, the coercion wraps the TargetExpr }}} Now when we find a cast in the target expr we can push it into the coercion {{{ match pat (Cast e c1) c2 = match pat e1 (c1 ; c2) }}} And a cast in the pattern just binds the variable {{{ match (Cast p v) e c = match p e Refl + {v :-> c} }}} This isn't quite right because we must make sure the types match, but it's close. The decomposition rules become more interesting: {{{ match (\x.p) (\x.e) c = match p e[x -> x |> arg_co] res_co where (arg_co, res_co) = decomposeFunCo c }}} or something like that. In effect we do the swizzling on the fly. This is all similar to the coercion swizzling in `Unify` when unifying types. I cannot fathom all the details and I'm not sure it's worth the work. But somehow it ought to be possible to make casts NOT impede matching in a systematic way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 09:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 09:14:16 -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.5e00e71968eede9259209f1a9511da36@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 simonpj): I'm pretty sure Phab:D3316 will fix. I thought it was merged already. As a side comment, Richard, we were discussing yesterday why we meed `match_co` in rule matching. Here we do! See #13476! Also: '''Ben''', once you have merged Phab:D3316, and checked that it works, can you also swap the order of these two equations in `Rules.match_co`? {{{ match_co renv subst co1 co2 | Just (tc1, cos1) <- splitTyConAppCo_maybe co1 = case splitTyConAppCo_maybe co2 of Just (tc2, cos2) | tc1 == tc2 -> match_cos renv subst cos1 cos2 _ -> Nothing match_co renv subst co1 co2 | Just (arg1, res1) <- splitFunCo_maybe co1 = case splitFunCo_maybe co2 of Just (arg2, res2) -> match_cos renv subst [arg1, res1] [arg2, res2] _ -> Nothing }}} Currently the second will never match because `splitTyConAppCo_maybe` succeeds (inefficiently) on `FunCo`. Swapping them will make it more efficient. Swapping them will probably conceal the bug, so test the fix first! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:16:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:16:53 -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.5853c0982216c01db3f07a0b84edd156@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | 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 simonpj): Another thought. The current `unsafeCoerce#` (defined in `MkId`) has type {{{ -- unsafeCoerce# :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) -- (a :: TYPE r1) (b :: TYPE r2). -- a -> b }}}` But it's super-dangerous to coerce from (say) a pointer type to a `Word#` and back. Perhaps the slightly more restrictive type {{{ -- unsafeCoerce# :: forall (r :: RuntimeRep) -- (a :: TYPE r) (b :: TYPE r). -- a -> b }}} would correctly capture many the "rule" specified in the documentation for `unsafeCoerce`? Regardless, a crash is bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:30:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:30:32 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag Message-ID: <046.1be05c5fa445155bed193903c2e35749@haskell.org> #13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- Currently, at configure time we tell GHC whether integers are built using `integer-gmp` or `integer-simple`, and this gets baked in via the global constant `cIntegerLibraryType`. This is all fine for normal use of GHC (the program), but users of ghc (the library) might want to have more leeway here. A good solution seems to be turn this into a dynflag setting, so that users of the GHC API can adjust that as fit. From a cursory glance at the code, this does not seem to be a big problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:31:10 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag In-Reply-To: <046.1be05c5fa445155bed193903c2e35749@haskell.org> References: <046.1be05c5fa445155bed193903c2e35749@haskell.org> Message-ID: <061.c8fa502f9e10e2f16304c1e7c7ebc0ce@haskell.org> #13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | 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): Unfortunately (as usually with GHC API issues) even if we fix it in HEAD now it will take a long time until it reaches the user’s installation, so I have to work around it somehow anyways. And once I have a work-around, the need to get this fixed is lowered. Hence the low priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:31:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:31:27 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC In-Reply-To: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> References: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> Message-ID: <059.8b4dcd0f1909a18d6995576f09a38958@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Reply to [[span(style=color: #FF0000, bgamari )]].\\ >Is this crash reproducible?\\ Yes the crash is reproducible on my computer every time I run "make" or "make install"\\\\ >How much memory does your guest have available to it?\\ my computer has 4 Go of RAM\\ Windows is 32 bit and use 3 Go of RAM. Linux is 64 bit on virtualBox as guest.\\ Linux use 1024 Mo of RAM.\\ in Linux, I looked at the task manager.\\ the memory in use does not exceed 83% when the compilation is active\\ {{{ vanto at debian:~/ghc$ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all- packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id filepath-1.4.1.1 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id hoopl-3.10.2.2 -package-id unix-2.7.2.1 -package-id terminfo-0.4.0.2 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/main/DynFlags.hs -o compiler/stage2/build/DynFlags.o -dyno compiler/stage2/build/DynFlags.dyn_o }}} When the {{{DynFlags}}} file is compiled I noticed this behavior (of memory) in the task manager of Linux:\\ throughout the process, which takes about 20 minutes, the memory that is used varies between 88% and 93% of the total memory.\\ suddenly the percentage of memory stops at 93% and does not vary thereafter for about 2 minutes.\\ then after this time elapsed the file stops to compile and an error appears.\\ {{{ compiler/ghc.mk:588: recipe for target 'compiler/stage2/build/DynFlags.o' failed make[1]: *** [compiler/stage2/build/DynFlags.o] Erreur de segmentation Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 vanto at debian:~/ghc$ }}} the memory down to 7% after stopping compilation.\\ \\ In Windows, throughout the process in the guest I can read in the task manager that the memory in use is 2.08 GB of RAM all the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:54:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:54:28 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.b6484920da95e4c61c7f6ee9dab4094b@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 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): Phab:D3359 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"caf94b062a0e37ffa7048e51447fc9486b658917/ghc" caf94b06/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="caf94b062a0e37ffa7048e51447fc9486b658917" x86 nativeGen: Fix test with mask in range [128,255] (#13425) My commit bdb0c43c7 optimized the encoding of instructions to test tag bits, but it did not always set exactly the same condition codes since the testb instruction does a single-byte comparison, rather than a full-word comparison. It would be correct to optimize the expression `x .&. 128 > 0` to the sequence testb $128, %al seta %al ; note: 'a' for unsigned comparison, ; not 'g' for signed comparison but the pretty-printer is not the right place to make this kind of context-sensitive optimization. Test Plan: harbormaster Reviewers: trofi, austin, bgamari, dfeuer Reviewed By: trofi, dfeuer Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:54:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:54:29 -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.ec1d318287a85519f863adcdf969e4b6@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"27c9a7d095d2383a7822d317dc7acfe579a4815b/ghc" 27c9a7d0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27c9a7d095d2383a7822d317dc7acfe579a4815b" testsuite: Add failing testcase for #13233 Thanks to Ryan Scott for the example. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:54:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:54:29 -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.56d14c12ba3ba1e0a596f07014fe2cbb@haskell.org> #13429: Optimizer produces Core with an infinite <> -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: merge 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 Ben Gamari ): In [changeset:"be8122ab72aeec509b5ce4b4f05fbc5cdb77bf5a/ghc" be8122ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be8122ab72aeec509b5ce4b4f05fbc5cdb77bf5a" testsuite: Add testcase for #13429 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 14:56:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 14:56:08 -0000 Subject: [GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1 In-Reply-To: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> References: <045.f167d99af02576cca92d6c9c9fd044d6@haskell.org> Message-ID: <060.edefe5755f825975b17c4ac02b9cd1f9@haskell.org> #13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | 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:D3359 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * priority: normal => high * resolution: => fixed Comment: Merged to `ghc-8.2` as bdb0c43c7991da3856e3a89db57c9ea78d61f55f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 17:43:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 17:43:40 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.70624eb9475a2ef91c5a13e8b8eceb9b@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints, | SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => simonpj Comment: I know exactly what is happening here. Just starved of time to fix it -- and next week looks little better. In brief: `TyCoRep.substCoVarBndr` is replacing occurrences of the binder with `Refl` in the LHS of a rule. Solution: `mkCoVarCo` should not replace varaibles with `Refl`; but `optCoercion` should do so instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 17:44:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 17:44:39 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.8a9f212fddaa5a27af7be96cb1f73560@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on it; but stuck for time. Monday I hope -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 20:01:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 20:01:17 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC In-Reply-To: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> References: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> Message-ID: <059.0641aeef0116584b9d1519478be336fe@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): I just did another test.\\ I increased the memory of Linux in VirtualBox, 1514 Mo\\ during compilation the percentage of memory usage has reached 95%, and has never been beyond\\ I noticed a new fact.\\ compiling failed when the swap file has reached 100% with the same error message.\\ \\ Hope this help -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 24 22:47:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Mar 2017 22:47:53 -0000 Subject: [GHC] #13454: Operators not allowed as fields in Record Pattern Synonyms In-Reply-To: <051.27085269b67e022e580ad0a1da270800@haskell.org> References: <051.27085269b67e022e580ad0a1da270800@haskell.org> Message-ID: <066.426649cc8fa404d92bb5b6565a046b19@haskell.org> #13454: Operators not allowed as fields in Record Pattern Synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D3379 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 02:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 02:42:51 -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.d4cb02d076226c0e08c710ceb0ba628c@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | 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): I'm uncomfortable with restricting the type of `unsafeCoerce#`. What if someone wants to do something really dirty, like cast a `Float#` into a `Word#` just to see the bits? This would be prohibited by comment:10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 02:50:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 02:50:36 -0000 Subject: [GHC] #13476: Coercion maching in RULES is fragile In-Reply-To: <046.2180d876ae517bd592cf11998da3e15c@haskell.org> References: <046.2180d876ae517bd592cf11998da3e15c@haskell.org> Message-ID: <061.357916b01ba3c6243ec740625071987c@haskell.org> #13476: Coercion maching in RULES is fragile -------------------------------------+------------------------------------- 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 goldfire): Your Plan B means to take the `kco` parameter to `unify_ty` and do the same thing at the term level. Perhaps the precise code in `unify_ty` could be improved, but the idea is a good one, and you're propose to replicate this action on coercions. I think it's all the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 10:23:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 10:23:30 -0000 Subject: [GHC] #13478: Data.List.NonEmpty.{unfold,unfoldr} differences Message-ID: <051.590c176aaffd03dbe3b3bab1fc9c1a26@haskell.org> #13478: Data.List.NonEmpty.{unfold,unfoldr} differences -------------------------------------+------------------------------------- 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 Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is there a difference between [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List- NonEmpty.html#v:unfoldr Data.List.NonEmpty.unfoldr] and [https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-List- NonEmpty.html#v:unfold Data.List.NonEmpty.unfold]? If there is a difference it would be nice to have that clarified in the docs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 15:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 15:03:00 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest Message-ID: <046.86fc8bb754ac201bb49f9ebcb50a495e@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm am seeing Core Lint failurse from the `T5626` test, {{{ *** Core Lint errors : in result of Simplifier *** : warning: [RHS of go_s54c :: [Int] -> (Int, Int, Int, Int)] idArity 2 exceeds typeArity 1: go_s54c }}} The relevant bits of the program are, {{{#!hs Rec { go_s54c [Occ=LoopBreaker] :: [Int] -> (Int, Int, Int, Int) [LclId, Arity=2, CallArity=2, Str=b, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=NEVER}] go_s54c = \ (ds_X35o :: [Int]) -> case ds_X35o of { [] -> case lvl_s4Vm of wild_00 { }; : y_a34y [Dmd=] ys_a34z [Dmd=] -> go_s54c ys_a34z } end Rec } lvl_s54d :: (Int, Int, Int, Int) [LclId, Arity=1, Str=x, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=NEVER}] lvl_s54d = go_s54c ([] @ Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 15:15:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 15:15: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.6aa8927695592d6094602967eca394df@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: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #10181 Comment: This is very strange since it seems that `go_s54c` is certainly arity one. Moreover, note how `lvl_s54d`'s IdInfo thinks that it has arity 1 (which is presumably why `go_s54c` has call arity 2. It looks like this is related to #1018, which is interesting since I also see some unexpected passes from tests marked as broken due to that ticket (e.g. `read029`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 15:24:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 15:24:46 -0000 Subject: [GHC] #13480: GHCi display visible type application Message-ID: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> #13480: GHCi display visible type application -------------------------------------+------------------------------------- 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: #8751 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to #8751, have a way to get GHCi to dump which types an expression is applied to: {{{ ghci> :tyapp length [1,2,3] length @[] @Integer [1,2,3] }}} It could also function as the [https://downloads.haskell.org/~ghc/master /users-guide/ghci.html#ghci-cmd-:all-types :all-types], [https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd -:type-at :type-at] commands where we can specify a region of code (from [https://www.researchgate.net/publication /282487445_Combining_Deep_and_Shallow_Embedding_of_Domain- Specific_Languages?ev=pubitem-pub_cit_inc Combining Deep and Shallow Embedding of Domain-Specific Languages]) {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M $ \k -> fromFunC Bind m k }}} displays {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M @m @a $ \(k :: a -> FunC (m b)) -> fromFunC @(FunC (m (Internal a)) -> (a -> FunC (m b)) -> FunC (m b)) (Bind @m @(Internal a) @b) m k }}} Would be great to get this feature as an IDE support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 15:25:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 15:25:17 -0000 Subject: [GHC] #13480: GHCi display visible type application In-Reply-To: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> References: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> Message-ID: <066.4109c5d66b0b606d81be59c1af52cdfe@haskell.org> #13480: GHCi display visible type application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8751 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: (none) => Iceland_jack Old description: > Similar to #8751, have a way to get GHCi to dump which types an > expression is applied to: > > {{{ > ghci> :tyapp length [1,2,3] > length @[] @Integer [1,2,3] > }}} > > It could also function as the [https://downloads.haskell.org/~ghc/master > /users-guide/ghci.html#ghci-cmd-:all-types :all-types], > [https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd > -:type-at :type-at] commands where we can specify a region of code (from > [https://www.researchgate.net/publication > /282487445_Combining_Deep_and_Shallow_Embedding_of_Domain- > Specific_Languages?ev=pubitem-pub_cit_inc Combining Deep and Shallow > Embedding of Domain-Specific Languages]) > > {{{#!hs > fromFunC :: FunC (m (Internal a)) -> Mon m a > fromFunC m = M $ \k -> fromFunC Bind m k > }}} > > displays > > {{{#!hs > fromFunC :: FunC (m (Internal a)) -> Mon m a > fromFunC m = M @m @a $ \(k :: a -> FunC (m b)) -> fromFunC @(FunC (m > (Internal a)) -> (a -> FunC (m b)) -> FunC (m b)) (Bind @m @(Internal a) > @b) m k > }}} > > Would be great to get this feature as an IDE support. New description: Similar to #8751, have a way to get GHCi to dump which types an expression is applied to: {{{ ghci> :tyapp length [1,2,3] length @[] @Integer [1,2,3] }}} It could also function as the [https://downloads.haskell.org/~ghc/master /users-guide/ghci.html#ghci-cmd-:all-types :all-types], [https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd -:type-at :type-at] commands where we can specify a region of code (from [https://www.researchgate.net/publication /282487445_Combining_Deep_and_Shallow_Embedding_of_Domain- Specific_Languages?ev=pubitem-pub_cit_inc Combining Deep and Shallow Embedding of Domain-Specific Languages]) {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M $ \k -> fromFunC Bind m k }}} displays {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M @m @a $ \(k :: a -> FunC (m b)) -> fromFunC @(FunC (m (Internal a)) -> (a -> FunC (m b)) -> FunC (m b)) (Bind @m @(Internal a) @b) m k }}} Would be great to get this feature as an IDE support. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 16:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 16:03:16 -0000 Subject: [GHC] #13480: GHCi display visible type application In-Reply-To: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> References: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> Message-ID: <066.22fc21564ddfdadfbe0723d05df0d1b8@haskell.org> #13480: GHCi display visible type application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8751 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): TODO See if you can easily generate a dependency tree of type class instances used for an expression. Quite often I delete instances to check which instance they make use of (especially with indirect dependencies). A famous case where this would help is `view _Just Nothing` which has a `Monoid` constraint and the connection is contrived (I haven't considered how this could be visualised): {{{ ghci> :whichInst view _Just Nothing instance Monoid m => Applicative (Const m) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 16:27:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 16:27:15 -0000 Subject: [GHC] #13481: T12622 fails in ghci way Message-ID: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | 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: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `T12622`, which is intended to test StaticPointers, fails in the GHCi way with a core lint warning, {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** : warning: In the expression: >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a1DF) lvl_s3bD) lvl_s3bE s_a1DF :: StaticPtr (Bool -> Bool) [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] is out of scope *** Offending Program *** g :: Bool [LclIdX] g = break<15>() True $trModule_s3b7 :: Addr# [LclId] $trModule_s3b7 = "main"# $trModule_s3b6 :: TrName [LclId] $trModule_s3b6 = TrNameS $trModule_s3b7 $trModule_s3b9 :: Addr# [LclId] $trModule_s3b9 = "Main"# $trModule_s3b8 :: TrName [LclId] $trModule_s3b8 = TrNameS $trModule_s3b9 $trModule :: Module [LclIdX] $trModule = Module $trModule_s3b6 $trModule_s3b8 lvl_s3bj :: Addr# [LclId] lvl_s3bj = "error"# lvl_s3bk :: [Char] [LclId] lvl_s3bk = unpackCString# lvl_s3bj lvl_s3bl :: Addr# [LclId] lvl_s3bl = "main"# lvl_s3bm :: [Char] [LclId] lvl_s3bm = unpackCString# lvl_s3bl lvl_s3bn :: Addr# [LclId] lvl_s3bn = "Main"# lvl_s3bo :: [Char] [LclId] lvl_s3bo = unpackCString# lvl_s3bn lvl_s3bp :: Addr# [LclId] lvl_s3bp = "T12622.hs"# lvl_s3bq :: [Char] [LclId] lvl_s3bq = unpackCString# lvl_s3bp lvl_s3br :: Int [LclId] lvl_s3br = I# 21# lvl_s3bs :: Int [LclId] lvl_s3bs = I# 14# lvl_s3bt :: Int [LclId] lvl_s3bt = I# 21# lvl_s3bu :: Int [LclId] lvl_s3bu = I# 64# lvl_s3bv :: SrcLoc [LclId] lvl_s3bv = SrcLoc lvl_s3bm lvl_s3bo lvl_s3bq lvl_s3br lvl_s3bs lvl_s3bt lvl_s3bu lvl_s3bw :: ([Char], SrcLoc) [LclId] lvl_s3bw = (lvl_s3bk, lvl_s3bv) $dIP_s3bc :: CallStack [LclId] $dIP_s3bc = pushCallStack lvl_s3bw emptyCallStack lvl_s3bx :: Addr# [LclId] lvl_s3bx = "couldn't find "# lvl_s3by :: [Char] [LclId] lvl_s3by = unpackCString# lvl_s3bx lookupKey :: forall a. StaticPtr a -> IO a [LclIdX, Arity=1] lookupKey = \ (@ a_a23X) (p_X1DX :: StaticPtr a_a23X) -> break<8>(p_X1DX) >>= @ IO $fMonadIO @ (Maybe (StaticPtr a_a23X)) @ a_a23X (break<1>(p_X1DX) unsafeLookupStaticPtr @ a_a23X (break<0>(p_X1DX) staticKey @ a_a23X p_X1DX)) (\ (ds_d3as :: Maybe (StaticPtr a_a23X)) -> case ds_d3as of { Nothing -> break<7>(p_X1DX) error @ 'LiftedRep @ (IO a_a23X) ($dIP_s3bc `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) (break<6>(p_X1DX) ++ @ Char lvl_s3by (break<5>(p_X1DX) show @ StaticPtrInfo $fShowStaticPtrInfo (break<4>(p_X1DX) staticPtrInfo @ a_a23X p_X1DX))); Just p_a1DI -> break<3>(p_a1DI) return @ IO $fMonadIO @ a_a23X (break<2>(p_a1DI) deRefStaticPtr @ a_a23X p_a1DI) }) $dTypeable_s3bA :: TypeRep Bool [LclId] $dTypeable_s3bA = mkTrCon @ * @ Bool $tcBool ([] @ SomeTypeRep) s_s3bC :: StaticPtr (Bool -> Bool) [LclId] s_s3bC = case break<9>() sg @ Bool ($dTypeable_s3bA `cast` (Sym N:Typeable[0] <*>_N _N :: (TypeRep Bool :: *) ~R# (Typeable Bool :: Constraint))) of { T s_a38b -> s_a38b } lvl_s3bD :: IO (Bool -> Bool) [LclId] lvl_s3bD = lookupKey @ (Bool -> Bool) s_s3bC lvl_s3bE :: (Bool -> Bool) -> IO () [LclId] lvl_s3bE = \ (f_a1DG :: Bool -> Bool) -> break<12>(f_a1DG) print @ Bool $fShowBool (break<11>(f_a1DG) f_a1DG True) main :: IO () [LclIdX] main = break<14>() break<13>(s_s3bC) >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a1DF) lvl_s3bD) lvl_s3bE main :: IO () [LclIdX] main = runMainIO @ () main *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 ===== program output begins here ===== program output begins here T12622:6:30: error: Not in scope: ‘Main.main’ No module named ‘Main’ is imported. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 16:37:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 16:37:15 -0000 Subject: [GHC] #13482: PartialTypeSignatures, AllowAmbiguousTypes and ScopedTypeVariables don't play nicely together Message-ID: <050.32ff9ffcd456d5039c2557ae9a212950@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 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **Motivation**: I was playing with [http://lpaste.net/353915 something like this] when I found this great confusion. I was able to produce a minimal example. In each declaration/definition, the function body is the same, but the signature varies. I expect every single one of them to compile, resulting in the same type as `minimal4`. The actual results are shown in-line. I think this sufficiently shows that this behavior is a bug. (The line numbers in the following code aren't useful; I pasted them in after compiling) (The question marks are there because CMD wasn't able to display bullets, I think.) {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} minimal1_noksig :: forall m. _ => Bool minimal1_noksig = (mempty :: m) == (mempty :: m) {- ambi.hs:17:30: error: ? Expected a type, but ‘m’ has kind ‘k0’ ? In an expression type signature: m In the first argument of ‘(==)’, namely ‘(mempty :: m)’ In the expression: (mempty :: m) == (mempty :: m) -} minimal1 :: forall (m :: *). _ => Bool minimal1 = (mempty :: m) == (mempty :: m) {- ambi.hs:11:1: error: ? Ambiguous type variable ‘m0’ prevents the constraint ‘(Monoid m0)’ from being solved. ? When checking that the inferred type minimal1 :: forall m. (Monoid m, Eq m) => Bool is as general as its (partial) signature minimal1 :: Bool -} minimal2 :: forall m. (Eq m, _) => Bool minimal2 = (mempty :: m) == (mempty :: m) {- ambi.hs:14:1: error: ? Could not deduce (Monoid m1) from the context: (Eq m, Monoid m) bound by the inferred type for ‘minimal2’: (Eq m, Monoid m) => Bool at ambi.hs:14:1-33 The type variable ‘m1’ is ambiguous ? When checking that the inferred type minimal2 :: forall m. (Monoid m, Eq m) => Bool is as general as its (partial) signature minimal2 :: forall m. (Eq m, Monoid m) => Bool -} minimal3 :: forall m. (Monoid m, _) => Bool minimal3 = (mempty :: m) == (mempty :: m) -- Compiles minimal4 :: forall m. (Monoid m, Eq m) => Bool minimal4 = (mempty :: m) == (mempty :: m) -- Compiles }}} The code was run in GHCi. GHC version is 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 17:25:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 17:25:47 -0000 Subject: [GHC] #13483: Can't allocate thunk for wcslen Message-ID: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> #13483: Can't allocate thunk for wcslen -------------------------------------+------------------------------------- Reporter: NickSeagull | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (FFI) | 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: -------------------------------------+------------------------------------- Hello, I'm trying to use the [https://sourceforge.net/projects/tinyfiledialogs tinyfiledialogs] library through the FFI, I've put the .h and .c files in a folder called "foreign" in the root of my project and configured cabal so it looks in this folder. The code for calling this function is as: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Escri where import Foreign.C.String foreign import ccall "tinyfiledialogs.h tinyfd_messageBox" c_messageBox :: CString -> CString -> CString -> CString -> Int -> IO Int messageBox :: String -> String -> String -> String -> Int -> IO Bool messageBox title message dialogType iconType defaultButton = do cTitle <- newCString title cMessage <- newCString message cDialogType <- newCString dialogType cIconType <- newCString iconType result <- c_messageBox cTitle cMessage cDialogType cIconType defaultButton return (result == 1) }}} When trying to run GHCi for this project, I get the following error {{{ Configuring GHCi with the following packages: escri GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.EXE: internal error: Can't allocate thunk for wcslen (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This only happens in Windows. In OSX I just get a linker error. If I try to make a call with stdcall, it tells: {{{ C:\Users\Nick\Development\escri\src\Escri.hs:6:1: warning: [-Wunsupported- calling-conventions] * the 'stdcall' calling convention is unsupported on this platform, treating as ccall * When checking declaration: foreign import stdcall safe "static tinyfiledialogs.h tinyfd_messageBox" c_messageBox :: CString -> CString -> CString -> CString -> Int -> IO Int }}} Which is strange, because I'm on Windows. Thanks in advance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 17:26:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 17:26:14 -0000 Subject: [GHC] #13483: Can't allocate thunk for wcslen In-Reply-To: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> References: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> Message-ID: <065.3891189504ed813cae5b34f0584f7728@haskell.org> #13483: Can't allocate thunk for wcslen -------------------------------------+------------------------------------- Reporter: NickSeagull | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | 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 NickSeagull): * Attachment "Escri.hs" added. Haskell file with the FFI call -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 17:26:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 17:26:37 -0000 Subject: [GHC] #13483: Can't allocate thunk for wcslen In-Reply-To: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> References: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> Message-ID: <065.f55266995b1c9ed101283df7efeabd27@haskell.org> #13483: Can't allocate thunk for wcslen -------------------------------------+------------------------------------- Reporter: NickSeagull | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | 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 NickSeagull): * Attachment "tinyfiledialogs.c" added. C file for tinyfiledialogs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 17:27:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 17:27:00 -0000 Subject: [GHC] #13483: Can't allocate thunk for wcslen In-Reply-To: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> References: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> Message-ID: <065.c34f4c55063d3feca3fefc969744660d@haskell.org> #13483: Can't allocate thunk for wcslen -------------------------------------+------------------------------------- Reporter: NickSeagull | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | 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 NickSeagull): * Attachment "tinyfiledialogs.h" added. H file for tinyfiledialogs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 17:41:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 17:41:29 -0000 Subject: [GHC] #13483: Can't allocate thunk for wcslen In-Reply-To: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> References: <050.eba0430fc344358ef3fa3ed9c1b3d150@haskell.org> Message-ID: <065.bbf59728d97f43860555e7f2a38e7c33@haskell.org> #13483: Can't allocate thunk for wcslen -------------------------------------+------------------------------------- Reporter: NickSeagull | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (FFI) | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * status: new => closed * resolution: => duplicate Comment: #13428 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 19:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 19:18:16 -0000 Subject: [GHC] #13484: Incorrect Exhaustivity Checking Message-ID: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> #13484: Incorrect Exhaustivity Checking -------------------------------------+------------------------------------- Reporter: andrewthad | 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: -------------------------------------+------------------------------------- Small example: {{{ {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# OPTIONS_GHC -Werror -fwarn-incomplete-patterns #-} data Chunk (f :: k -> *) (xs :: [k]) where ChunkCons :: f a -> f b -> f c -> f d -> Chunk f xs -> Chunk f (a ': b ': c ': d ': xs) ChunkNil :: Chunk f '[] impossibleChunk01 :: Chunk f as -> Chunk f (a ': as) -> b impossibleChunk01 (ChunkCons _ _ _ _ c1) (ChunkCons _ _ _ _ c2) = impossibleChunk01 c1 c2 }}} This fails with: {{{ fast_records.hs:32:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘impossibleChunk01’: Patterns not matched: ChunkNil _ }}} Obviously a Chunk and a Chunk that's one element bigger cannot both exist. They must each be a multiple of 4. The impossibleChunk01 function is supposed to prove this. However, GHC doesn't currently figure out that neither data constructor can pair up with ChunkNil. This may be a moot point. The EmptyCase extension is currently sort of broken (because it currently never warns), but in GHC 8.2, it does some exhaustivity checking to ensure that you aren't shooting yourself in the foot. So, I might be able to write: {{{ impossibleChunk01 :: Chunk f as -> Chunk f (a ': as) -> b impossibleChunk01 (ChunkCons _ _ _ _ c1) (ChunkCons _ _ _ _ c2) = impossibleChunk01 c1 c2 impossibleChunk01 ChunkNill x = case x of {} }}} If that's the case (no pun intended), then I don't mind having to manually help out the exhaustivity checker in that way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 21:54:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 21:54:01 -0000 Subject: [GHC] #13485: Doesn't warn about variable not in scope Message-ID: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> #13485: Doesn't warn about variable not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running this works fine {{{#!hs {-# Language GADTs, TypeFamilies, InstanceSigs #-} data FunC a where (:$) :: FunC (a -> b) -> FunC a -> FunC b Lam :: (FunC a -> FunC b) -> FunC (a -> b) Add :: Num a => FunC (a -> a -> a) class Syntactic a where type Internal a toFunC :: a -> FunC (Internal a) fromFunC :: FunC (Internal a) -> a instance Syntactic (FunC a) where type Internal (FunC a) = a toFunC, fromFunC :: FunC a -> FunC a toFunC ast = ast fromFunC ast = ast instance (Syntactic a, Syntactic b) => Syntactic (a -> b) where type Internal (a -> b) = Internal a -> Internal b toFunC :: (a -> b) -> FunC (Internal a -> Internal b) toFunC f = Lam (toFunC . f . fromFunC) fromFunC :: FunC (Internal a -> Internal b) -> (a -> b) fromFunC f = fromFunC . (f :$) . toFunC add :: Num a => FunC a -> FunC a -> FunC a add = fromFunC Add }}} A folklore for infix expressions is writing `expr a b` as `a &expr$ b`, if I try that '''without''' importing `(Data.Function.&)` I get {{{#!hs -- tghl.hs:29:23-25: error: … -- • Couldn't match type ‘Internal t0’ with ‘a0 -> a0 -> a0’ -- Expected type: FunC (Internal t0) -- Actual type: FunC (a0 -> a0 -> a0) -- The type variables ‘t0’, ‘a0’ are ambiguous -- • In the first argument of ‘fromFunC’, namely ‘Add’ -- In the second argument of ‘(&)’, namely ‘fromFunC Add’ -- In the expression: (&) a fromFunC Add add :: Num a => FunC a -> FunC a -> FunC a add a b = a &fromFunC Add$ b }}} I would expect a `Variable not in scope: (&)` error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 22:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 22:03:09 -0000 Subject: [GHC] #13485: Doesn't warn about variable not in scope In-Reply-To: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> References: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> Message-ID: <066.4b178290a58783fd136c793c76adf576@haskell.org> #13485: Doesn't warn about variable not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | Keywords: GADTs Operating System: 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: => worksforme Comment: Erm, GHC //does// give you a `Variable not in scope: (&)` error in GHC 8.0.1, 8.0.2 and 8.2. {{{ $ /opt/ghc/8.0.2/bin/ghci Bug2.hs -Wall GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:29:13: error: Variable not in scope: (&) :: FunC a -> t0 -> FunC a -> FunC a Bug2.hs:29:23: error: • Couldn't match type ‘Internal t0’ with ‘a0 -> a0 -> a0’ Expected type: FunC (Internal t0) Actual type: FunC (a0 -> a0 -> a0) The type variables ‘t0’, ‘a0’ are ambiguous • In the first argument of ‘fromFunC’, namely ‘Add’ In the second argument of ‘(&)’, namely ‘fromFunC Add’ In the expression: (&) a fromFunC Add }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug2.hs -Wall GHCi, version 8.2.0.20170321: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug2.hs, interpreted ) Bug2.hs:29:13: error: Variable not in scope: (&) :: FunC a -> t0 -> FunC a -> FunC a | 29 | add a b = a &fromFunC Add$ b | ^ Bug2.hs:29:23: error: • Couldn't match type ‘Internal t0’ with ‘a0 -> a0 -> a0’ Expected type: FunC (Internal t0) Actual type: FunC (a0 -> a0 -> a0) The type variables ‘t0’, ‘a0’ are ambiguous • In the first argument of ‘fromFunC’, namely ‘Add’ In the second argument of ‘(&)’, namely ‘fromFunC Add’ In the expression: (&) a fromFunC Add | 29 | add a b = a &fromFunC Add$ b | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 22:29:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 22:29:08 -0000 Subject: [GHC] #13484: Incorrect Exhaustivity Checking In-Reply-To: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> References: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> Message-ID: <064.15c8d702655d2d4f8d2bc3f0c32d3219@haskell.org> #13484: Incorrect Exhaustivity Checking -------------------------------------+------------------------------------- Reporter: andrewthad | 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 RyanGlScott): This is expected behavior. The first implementation of `impossibleChunk01` you gave is not exhaustive because the second argument might be `⊥`, which may involve neither constructor! If you don't believe me, try evaluating `impossibleChunk01 ChunkNil (let x = x in x)`. So the most correct solution is to adopt your suggestion and write this second case: {{{#!hs impossibleChunk01 ChunkNill x = case x of {} }}} And, as you noted, GHC 8.2 will verify that that empty-case on `x` really is exhaustive, so you can be assured that `x` isn't inhabited by a (terminating) `Chunk` value. Is that a satisfying answer? If so, please feel free to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 22:45:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 22:45:23 -0000 Subject: [GHC] #13485: Doesn't warn about variable not in scope In-Reply-To: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> References: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> Message-ID: <066.9449deeec3e347ea6e019cd59d924b52@haskell.org> #13485: Doesn't warn about variable not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | Keywords: GADTs Operating System: 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): Ah you need to add {{{#!hs {-# OPTIONS_GHC -fdefer-typed-holes #-} }}} I have it in my `.ghci` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 25 22:50:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Mar 2017 22:50:14 -0000 Subject: [GHC] #13485: Doesn't warn about variable not in scope In-Reply-To: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> References: <051.3418082011c476bdfc0bf73c43a14221@haskell.org> Message-ID: <066.8a10f0066657209965ada20100353b90@haskell.org> #13485: Doesn't warn about variable not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | Keywords: GADTs Operating System: 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 still not reproducing the error, even with `-fdefer-typed-holes`. {{{ $ ghci Bug.hs -fdefer-typed-holes GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:29:13: error: Variable not in scope: (&) :: FunC a -> t0 -> FunC a -> FunC a Bug.hs:29:23: error: • Couldn't match type ‘Internal t0’ with ‘a0 -> a0 -> a0’ Expected type: FunC (Internal t0) Actual type: FunC (a0 -> a0 -> a0) The type variables ‘t0’, ‘a0’ are ambiguous • In the first argument of ‘fromFunC’, namely ‘Add’ In the second argument of ‘(&)’, namely ‘fromFunC Add’ In the expression: (&) a fromFunC Add }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 10:02:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 10:02:55 -0000 Subject: [GHC] #13486: inconsistency in handling the BOM Byte-order-mark in reading and putStrLn Message-ID: <051.ca911afc496192412d6a1ba78621943c@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 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: -------------------------------------+------------------------------------- this is a very annoying issue and has been discussed already (e.g. #1744) and https://mail.haskell.org/pipermail/haskell- cafe/2011-January/088021.html. i think it is ok that the BOM character is not automatically removed when reading a file, but it is INCONSISTENT then to not show the BOM character when printing the file content. a minimal test: v <- readFile "fileWithBOM" putStrLn "the file content" putStrLn v putStrLn (show v) return () the first line does not indicate that there is a BOM character in the input and not removed from the result - only the second putStrLn (with the incorrect show on the result string) demonstrates the presence of the BOM character: "\65279\r\n.sprache English\r\n\..... consistency here is important to warn the programmer early on (after reading and checking file content) because other tools (e.g. parsec) see the BOM character and fail. i recommend that the BOM character is read but shown in printStrLn - i guess this is preferably over automatic (silent) removal. reading in and not showing, however, leads to misguided searches for strange errors caused by the BOM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 10:04:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 10:04:06 -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.0d2104993ffc842f44076f6b0112e22a@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: | -------------------------------------+------------------------------------- Description changed by andrewufrank: Old description: > this is a very annoying issue and has been discussed already (e.g. #1744) > and https://mail.haskell.org/pipermail/haskell- > cafe/2011-January/088021.html. > > i think it is ok that the BOM character is not automatically removed when > reading a file, but it is INCONSISTENT then to not show the BOM character > when printing the file content. > > a minimal test: > > v <- readFile "fileWithBOM" > putStrLn "the file content" > putStrLn v > putStrLn (show v) > > return () > > the first line does not indicate that there is a BOM character in the > input and not removed from the result - only the second putStrLn (with > the incorrect show on the result string) demonstrates the presence of the > BOM character: > > "\65279\r\n.sprache English\r\n\..... > > consistency here is important to warn the programmer early on (after > reading and checking file content) because other tools (e.g. parsec) see > the BOM character and fail. > > i recommend that the BOM character is read but shown in printStrLn - i > guess this is preferably over automatic (silent) removal. reading in and > not showing, however, leads to misguided searches for strange errors > caused by the BOM. New description: this is a very annoying issue and has been discussed already (e.g. #1744) and https://mail.haskell.org/pipermail/haskell- cafe/2011-January/088021.html. i think it is ok that the BOM character is not automatically removed when reading a file, but it is INCONSISTENT then to not show the BOM character when printing the file content. a minimal test: {{{ v <- readFile "fileWithBOM" putStrLn "the file content" putStrLn v putStrLn (show v) return () }}} the first line does not indicate that there is a BOM character in the input and not removed from the result - only the second putStrLn (with the incorrect show on the result string) demonstrates the presence of the BOM character: "\65279\r\n.sprache English\r\n\..... consistency here is important to warn the programmer early on (after reading and checking file content) because other tools (e.g. parsec) see the BOM character and fail. i recommend that the BOM character is read but shown in printStrLn - i guess this is preferably over automatic (silent) removal. reading in and not showing, however, leads to misguided searches for strange errors caused by the BOM. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 10:59:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 10:59:37 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.5a65d3d00c946d5627fa310ed255ed68@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * priority: high => normal Comment: The testsuite deals with this error internally now by removing it from the output. It is no longer a blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 11:25:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 11:25:10 -0000 Subject: [GHC] #13487: GHC panic with deferred custom type errors Message-ID: <048.bd49c7ea99276e8a478bec618b768f03@haskell.org> #13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- I'm working on a music composition library that enforces composition rules at the type level. It makes heavy use of TypeInType and custom compiler errors. For example, it disallows dissonant major seventh intervals (e.g., a C and a B) in harmonic composition. While testing the library, I encountered a GHC panic which I haven't seen anywhere – unfortunately I don't know enough about GHC to understand what is causing the panic and couldn't reproduce it in simpler examples. I was hoping that you could point me in the right direction so that I can find a smaller program that reproduces the error. In GHCi, with the -fdefer-type-errors flag set, the following code (which should throw a custom type error as it describes composing a B quarter note with a C quarter note) produces a panic: {{{ λ: let t = c qn :-: b qn :21:9: warning: [-Wdeferred-type-errors] • Can't have major sevenths in chords: C and B • In the expression: c qn :-: b qn In an equation for ‘t’: t = c qn :-: b qn ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): nameModule system irred_aCeG Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This does not appear when loading a source file, or when -fdefer-type- errors is disabled, and only happens when the expression is assigned to a new value. A lot of the literals in the library are generated by TemplateHaskell, but the error happens without them as well: {{{ λ: let s = Note (Root :: Root (PitchRoot (Pitch B Natural Oct4))) (Dur :: Dur Quarter ) λ: let t = Note (Root :: Root (PitchRoot (Pitch C Natural Oct4))) (Dur :: Dur Quarter ) λ: let v = s :-: t :27:9: warning: [-Wdeferred-type-errors] • Can't have major sevenths in chords: B and C • In the expression: s :-: t In an equation for ‘v’: v = s :-: t ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): nameModule system irred_aCnF Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The library is available on Hackage (https://hackage.haskell.org/package/mezzo) and the error is reproducible as soon as the main module is loaded. I'd happily try to find a smaller example which gives the same error, so I was hoping that you might have some ideas about what could be going wrong. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 12:38:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 12:38:17 -0000 Subject: [GHC] #13484: Incorrect Exhaustivity Checking In-Reply-To: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> References: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> Message-ID: <064.838d6d36ba4b2cbe43ba541304e26439@haskell.org> #13484: Incorrect Exhaustivity Checking -------------------------------------+------------------------------------- Reporter: andrewthad | 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 andrewthad): Thanks. That makes sense, and it addresses my concerns. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 12:39:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 12:39:13 -0000 Subject: [GHC] #13484: Incorrect Exhaustivity Checking In-Reply-To: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> References: <049.2520f3d45761f5f6d0c1387e1837012a@haskell.org> Message-ID: <064.20bbc6b2e4ae5dbf117f78df83a49ee8@haskell.org> #13484: Incorrect Exhaustivity Checking -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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 andrewthad): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 15:22:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 15:22:23 -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.d39dbbb87a70f533d955e425935b165a@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: MacOS X => Unknown/Multiple * component: Compiler => GHCi * milestone: => 8.4.1 Comment: Thanks for the bug report! Here is a minimal file which exhibits the issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Mezzo where import Data.Kind (Constraint) import GHC.TypeLits data Foo a b where (:-:) :: Error a b => a -> b -> Foo a b type family Error a b :: Constraint where Error Int Int = () Error _ _ = TypeError ('Text "GHC panic in 3... 2... 1...") }}} Now load this into GHCi like so: {{{ $ /opt/ghc/8.2.1/bin/ghci Mezzo.hs -fdefer-type-errors GHCi, version 8.2.0.20170321: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Mezzo ( Mezzo.hs, interpreted ) Ok, modules loaded: Mezzo. λ> let v = 'a' :-: 'b' :1:9: warning: [-Wdeferred-type-errors] • GHC panic in 3... 2... 1... • In the expression: 'a' :-: 'b' In an equation for ‘v’: v = 'a' :-: 'b' ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170321 for x86_64-unknown-linux): nameModule system irred_a2AK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:239:3 in ghc:Name }}} I can reproduce this with 8.0.1, 8.0.2, 8.2.1, and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 15:38:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 15:38:23 -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.11e5f593a1283c4fffe94d74c370560c@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 DimaSamoz): Thank you! Yes, that looks similar to my definition of `:-:`: {{{ #!haskell data Music :: forall n l. Partiture n l -> Type where -- | Parallel or harmonic composition of music. (:-:) :: ValidHarm m1 m2 => Music m1 -> Music m2 -> Music (m1 +-+ m2) ... }}} `ValidHarm` checks whether the two pieces of music can be composed and returns a `TypeError` if there is a composition mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 16:41:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 16:41:41 -0000 Subject: [GHC] #13488: man page says "see foo" without having chapter "foo" Message-ID: <048.cea5b7bd92628007c870617e40b999fb@haskell.org> #13488: man page says "see foo" without having chapter "foo" -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- the first instance is the reference to the manual itself: "Extensive documentation is available in various other formats including PDF and HTML; see below." where "below" is the rest of the document, which does not seem to contain any further mentioning/linking to the proper documentation. I think all other instances of "see ..." are similarly empty promises. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 17:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 17:49:28 -0000 Subject: [GHC] #10542: Incorrect Unicode input on Windows Console In-Reply-To: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> References: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> Message-ID: <060.4c2ff8a772b2f9df7aa47323a853d7b7@haskell.org> #10542: Incorrect Unicode input on Windows Console -------------------------------------+------------------------------------- Reporter: ptroev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: windows stdin | utf-8 cmd chcp 65001 getLine Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11394, #4471 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * priority: high => normal * milestone: => 8.4.1 Comment: I don't think anything is going to happen here until the new I/O manager is ready. So demoting priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 20:29:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 20:29:12 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.f64d75d38aa4616e1d893c591027c403@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3384 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * differential: => Phab:D3384 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 20:29:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 20:29:51 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.8d98c99165d849bdc14a223652dc4fc1@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 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3382 Phab:D3383 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 20:30:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 20:30:00 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.3049deff0978d99b3efa2f583061490b@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3384 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: upstream => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 22:29:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 22:29:17 -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.d1945302541e308263f719bc0850cb9e@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 duog): I have not contributed to GHC before, and I would like to work on resolving this issue. Both haddock and flycheck should be able to use -fno-code to do a lot less work. Currently, haddock essentially turns off no-code when any modules use template haskell and flycheck uses no-link to work around both this issue and #10600. I think this can be resolved by having ghc itself enable codegen on home modules depended on by modules that use template haskell. I have a patch here [https://github.com/duog/ghc/tree/wip-nocode-th] which I just rebased onto your master. Note that the haddock submodule points to my github fork. downsweep is changed to do an additional pass over the modules, targetting any ModSummaries transitively depended on by a module that has LangExt.TemplateHaskell enabled. Those targeted modules have hscTarget changed from HscNothing to the default target of the platform. There are two shell scripts in the root of my fork which boot and run an ad-hoc benchmark of cabal haddock on the wreq library. This library uses template haskell to generate lenses, and imports home modules from modules that use template haskell. However, most modules are not imported from modules that use template haskell. With this patch, cabal haddock runs in about half the time. At least two points that need to be addressed: * Should this behaviour require an additional flag? It doesn't seem good for -fno-code to sometimes generate code. * Is the default target of the platform the correct choice? I would require some guidance to get this into a mergable state, if you are interested in taking this fix please let me know the next step. I am happy to use your phabricator if that is appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 26 22:44:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Mar 2017 22:44:30 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.4914ff66c1a1d86c3e2323cf3178ba85@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I was able to reproduce on a 64-bit Ubuntu machine. Here were my steps: 1. Download ghc-head from hvr's PPA https://launchpad.net/~hvr/+archive/ubuntu/ghc 2. Build the test case: `ghc-head -c hs_try_putmvar003.hs` and then ` ghc- head hs_try_putmvar003_c.c hs_try_putmvar003.o -debug` 3. Repeatedly run `./a.out 1 1 1 1 +RTS -DS` until it hangs or segfaults. In 25 runs, 4 failed in various different ways (assert fail, segfault, or deadlock.) It's a bit annoying because the C stub uses pthreads whether or not the threaded runtime is linked, so I don't have something that's deterministic. Scanning over the code, I didn't see anything obviously wrong, so I'm going to do some bisecting and see if this always failed or if it's a regression introduced by an unrelated change (levity polymorphism causing the unsafeCoerce to be bad, maybe?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 02:28:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 02:28:40 -0000 Subject: [GHC] #13480: GHCi display visible type application In-Reply-To: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> References: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> Message-ID: <066.00d8af723015208c4a6cbf08765d2095@haskell.org> #13480: GHCi display visible type application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8751 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I really like this idea. But please submit as a [https://github.com/ghc- proposals/ghc-proposals ghc-proposal]. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 02:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 02:33:45 -0000 Subject: [GHC] #13488: man page says "see foo" without having chapter "foo" In-Reply-To: <048.cea5b7bd92628007c870617e40b999fb@haskell.org> References: <048.cea5b7bd92628007c870617e40b999fb@haskell.org> Message-ID: <063.b3f24535290f1899c3ccf99c9f176c05@haskell.org> #13488: man page says "see foo" without having chapter "foo" -------------------------------------+------------------------------------- Reporter: lspitzner | 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: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #3351 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate * related: => #3351 Comment: Thanks for reporting. That is a known problem, see #3351. It would be nice if there was a good solution here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 02:37:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 02:37:16 -0000 Subject: [GHC] #3351: Generated ghc man page missing xrefs In-Reply-To: <043.e70675efe6c1e6fb67be6a4568f6dd0d@haskell.org> References: <043.e70675efe6c1e6fb67be6a4568f6dd0d@haskell.org> Message-ID: <058.3b40b90cf6edc14405767e4209e23549@haskell.org> #3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------- Reporter: kaol | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 6.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: This was just reported again (#13488). It might be low priority, but it certainly is not good enough. Ideally, it would say > details in section “Name of the section” in the user manual, possibly with a link to some canonical online location. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 02:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 02:59:49 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.2bb47f43b50d4cbadb2cb5a3e3981ac2@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3368 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"14b46a556dde8a2795ff5ede46ba8ee63368ae93/ghc" 14b46a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14b46a556dde8a2795ff5ede46ba8ee63368ae93" Recompile if -fhpc is added or removed (#11798) Test Plan: validate Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3368 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 02:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 02:59:49 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.e8471c33b46b583f0d77f04513760da9@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"140a2d1c463bd314c9afbeb8d60e739163ce576a/ghc" 140a2d1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="140a2d1c463bd314c9afbeb8d60e739163ce576a" testsuite: Mark T12622 as broken in ghci way See #13481. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 03:10:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 03:10:10 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.4531eadc09ecdcf0d1de2307ad16aec9@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.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): * owner: (none) => dfeuer Comment: David, could you provide some more quantitative performance evaluation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 03:10:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 03:10:53 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.fea0829480bc3a2f20ffd1f3d1028397@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12622 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12622 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 03:16:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 03:16:47 -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.b013718d1031336bef17ffcc21b2655f@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 bgamari): I would be happy to. Unfortunately there are some testsuite issues in Phab:D3316 which will need to be resolved before it can be merged. Namely, `T11480b` fails with, {{{ T11480b.hs:131:10: error: • Couldn't match kind ‘*’ with ‘Constraint’ arising from a use of ‘T11480b.$dmop’ • In the expression: T11480b.$dmop @Constraint @(:-) In an equation for ‘op’: op = T11480b.$dmop @Constraint @(:-) In the instance declaration for ‘Category (:-)’ }}} which I'm reasonably confident will break user code (namely Edward Kmetts's `constraints` library). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 03:20:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 03:20:32 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.7cc5293b9211dc5c04468bc37e103520@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have also seen this occasionally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:38:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:38:00 -0000 Subject: [GHC] #13313: cabal08 broken In-Reply-To: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> References: <046.21a750f7dc7d8f9aef8581050795a2af@haskell.org> Message-ID: <061.c819f6054e58bcdae672e2058687db9c@haskell.org> #13313: cabal08 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: bug | Status: closed Priority: high | 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:D3369 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 1682980d7f5262fb42c0d11e8366bde6bc98c792. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:39:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:39:04 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.43c210eec23d3a070eb63ea19f64f98d@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 109a2429493c2a2d5481b67f5b0c1086a959813e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:39:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:39:46 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.78f44f8996853050f47c487ce4276dd2@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Alright, bumping off to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:44:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:44:46 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.ebc4239d8010f9fab0ae74f88dcc3c8b@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:45:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:45:01 -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.c6bd5cdad4e5561c6779be3c9369ba01@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3377 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: mpickering => (none) * status: merge => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:45:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:45:11 -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.05073b52bc32417594bbc6c60853c486@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3377 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:46:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:46:35 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.a2b124c3fc1bdcc06088ceb98cde1666@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.2.2 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.2.2 Comment: Then perhaps we can just bump further work off to 8.2.2 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 04:52:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 04:52:45 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.ad221d3e1830f985183a0b6c5a14a9bd@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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 05:02:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 05:02:22 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.6f1a1d9f3383d3e71c3bd2f0e93e8f43@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Looking at `-ddump-tc-trace` from the program in the ticket description, it seems that we are failing to solve for this, {{{ WC {wc_simple = [WD] $dTypeable_a29a {0}:: Typeable (T |> Trans (Sym cobox ->_N <*>_N) (cobox ->_N <*>_N)) (CDictCan)} }}} I believe the reason for this is that we don't handle casts in the `Typeable` solver. I'll need to think about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 08:17:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 08:17:02 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.d03a51099d0d09299ac736453cbeb13f@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I made a wiki page with a few specific examples: [wiki:NestedCPR/Akio2017]. I think I'm now done with updating `extendSigsWithLam`. I'm going to run nofib again and look for more improvements to make. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 08:43:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 08:43:56 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.a26996b7f74c1a30d6b8669422931ded@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge Comment: Modified by {{{ commit 3cfee57abf00f794e7962e2a60efd9d7d8baf06f Author: Richard Eisenberg Date: Thu Mar 16 15:56:37 2017 -0400 Remove solveSomeEqualities I had thought that it was necessary to solve kind-level equalities before validity-checking a type, but I was wrong. This patch simply deletes code. Hooray! }}} Has this been merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 09:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 09:21:54 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.92fe17aba18d4671864c8781df0eefbd@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: 13411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): What would be required to push point releases to existing GHC versions? I imagine this will make all past GHC versions unusable on Windows in the near future. Since one (me) seemingly can't roll back from Fast-Ring Insider builds to Release Preview other than letting Stable versions slowly catch up (WTF, Microsoft?!), this seems like the more sustainable course of actions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 10:19:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 10:19:01 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEzNzogV2FybmluZyBhYm91dCDigJxJTkxJ?= =?utf-8?q?NE_binder_is_=28non-rule=29_loop_breaker=E2=80=9D_with?= =?utf-8?q?_=60-dcore-lint=60?= In-Reply-To: <051.4a9a2dbe0c20bdb18f0b6695483f466f@haskell.org> References: <051.4a9a2dbe0c20bdb18f0b6695483f466f@haskell.org> Message-ID: <066.a6bc6e56093ff303efc79b9ea8a65bdf@haskell.org> #12137: Warning about “INLINE binder is (non-rule) loop breaker” with `-dcore-lint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 10:21:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 10:21:06 -0000 Subject: [GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker" In-Reply-To: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> References: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> Message-ID: <061.c0dfe464fa538a0a07ac83cd3526f1dd@haskell.org> #9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12137, #3073 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See [https://mail.haskell.org/pipermail/ghc-devs/2017-March/013993.html this thread], where Mikolaj wants the inline-loop-breaker warning to happen when not in a debug build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 10:28:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 10:28:16 -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.c539ba038c869886ca3c90576eb642da@haskell.org> #13470: Pattern synonyms bind variables out of scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3377 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"d819e416a2a537b78b2698dfe753aa68dfb8b837/ghc" d819e41/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d819e416a2a537b78b2698dfe753aa68dfb8b837" Only use locally bound variables in pattern synonym declarations Summary: We were using the unconstrainted `lookupOccRn` function which looked up any variable in scope. Instead we only want to consider variables brought into scope by renaming the pattern on the RHS. A few more changes to make reporting of unbound names suggest the correct things. Fixes #13470 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3377 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 10:34:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 10:34:05 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.bce05be5702478f2279af06954df814d@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK great, thank you! Neither example on your status page use I/O, and I think it may be there that the main gains are to be found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 10:42:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 10:42:12 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.4295e645d8f4dfd29c35aa97676d606c@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that if we have `t :: k1` and `c :: k1 ~ k2` and {{{ Constraints: [W] c :: Typeable k2 (t |> c) }}} then we can simplify the wanted constraint to {{{ Bindings: c = c1 |> Typeable ?? c Constraints: [W] c1 :: Typeable k1 t }}} Richard do you agree? What is the `??`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 12:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 12:17:19 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.31cc510f46a9edaaa50643be8b4d000d@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D3386 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 12:37:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 12:37:58 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.5192d916c8d5f988af8a9b73f96de593@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: It's unlikely this will be fixed for 8.2; de-milestoning until someone picks it up. Moreover, we will hopefully have Hadrian soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 12:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 12:43:34 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.df741483101cc45681fd187b23aa3143@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: There is general agreement that we want to do something along these lines. However, it will probably only happen for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 13:51:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 13:51:47 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.93d06a144aed126880d236b73e7a555a@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12622 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => facundo.dominguez * keywords: => StaticPointers Comment: Facundo, any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 14:00:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 14:00:53 -0000 Subject: [GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound In-Reply-To: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> References: <050.2af5d95ca53a0f78ff1e49631a43a659@haskell.org> Message-ID: <065.6f90946d9fa5d0f20439c192c3ee21fb@haskell.org> #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 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: facundominguez (removed) * cc: facundo.dominguez (added) Comment: Oops, I cc'd the wrong username, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 14:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 14:36:31 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.f8f1298fc1d30f1d9c020356969633c5@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also what if we have {{{ Eq (t |> c) }}} Can we solve that, or do we get stuck? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 14:38:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 14:38:04 -0000 Subject: [GHC] #13434: hs_try_putmvar003 is timing out / segfaulting In-Reply-To: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> References: <045.a8ba4ff49dee16c0019e5f315e9937ac@haskell.org> Message-ID: <060.5819ad1874fa5614a9c05a763b458384@haskell.org> #13434: hs_try_putmvar003 is timing out / segfaulting -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): So that repro compiles the test without `-threaded`, but `-threaded` is required because the test calls into the RTS using multiple threads. I'll fix the test so that it fails when linked without `-threaded` rather than randomly crashing. There could still be an issue, but this isn't it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 14:55:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 14:55:32 -0000 Subject: [GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores In-Reply-To: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> References: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> Message-ID: <060.daa64a29544e6ab1f978923d09c80dab@haskell.org> #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores --------------------------------------------+------------------------------ Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by varosi): Will that issue enter 8.2 or 8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:18:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:18:25 -0000 Subject: [GHC] #13489: openTempFile fails when the template parameter contain a path separator Message-ID: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> #13489: openTempFile fails when the template parameter contain a path separator -------------------------------------+------------------------------------- Reporter: harendra | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If the template string contains a path separator, for example "a/b" then openTempFile just fails with a message which does not even indicate what the problem might be. It displays the following message: {{{ mod: /tmp/: openTempFile: does not exist (No such file or directory) }}} It can either provide a better error message, saying that path separator is not allowed or if it is legal to allow a path separator then it should create that path in the temp dir. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:29:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:29:01 -0000 Subject: [GHC] #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores In-Reply-To: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> References: <045.62ec1d1031a2707c97a15db7c0ee2c82@haskell.org> Message-ID: <060.e197c2d8b5367aab167af7c80db55704@haskell.org> #12181: Multi-threaded code on ARM64 GHC runtime doesn't use all available cores --------------------------------------------+------------------------------ Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by bgamari): At the moment there is no milestone meaning we aren't targetting any particular release for a fix. I will say that I'm not terribly keen on the idea of polling to get CPU information. I tend to agree with Reid that this is a distribution issue: bringing CPUs entirely offline for the sake of power management seems a bit crazy. Don't the Linux `cpufreq`, `cpuidle`, and clock management, and runtime PM subsystems exist precise to avoid this sort of heavy-weight power management? Why not just implement the RTS's `-N` logic yourself, but using at `_SC_NPROCESSORS_CONF` instead of `_SC_NPROCESSORS_ONLN`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:30:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:30:55 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.97db45d10888a4d3e005f382eb77e2e6@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Indeed, that was merged to `ghc-8.2` as 6c41ed6e7994451f78af87bff43d6baef19b8f0f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:31:38 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions In-Reply-To: <047.5414232b40be6201b11861058f159173@haskell.org> References: <047.5414232b40be6201b11861058f159173@haskell.org> Message-ID: <062.649bfe7a766cb52b0b316f58431e3479@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"feca929b8f7a7dfe96d06c27d405ce331cdcdb41/ghc" feca929b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feca929b8f7a7dfe96d06c27d405ce331cdcdb41" Fix 'unsolved constraints' in GHCi In initTc, if the computation fails with an exception, we should not complain about unsolved constraints. Fixes Trac #13466. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:31:38 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.108970ef2a21f3e56bc9c647a4ef40d1@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1e06d8b8f2aea0a06d40618c296a034f3e408ae2/ghc" 1e06d8b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e06d8b8f2aea0a06d40618c296a034f3e408ae2" Simplify the logic for tc_hs_sig_type In fixing Trac #13337, and introducing solveSomeEqualities, Richard introduce the higher-order function tc_hs_sig_type_x, with a solver as its argument. It turned out that there was a much simpler way to do the same thing, which this patch implements. Less code, easier to grok. No change in behaviour though. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:31:38 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.8586ebf3e539e5f0211089ae450f77c1@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7c7479d047113a0cbf237c864d403bb638ca0241/ghc" 7c7479d0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7c7479d047113a0cbf237c864d403bb638ca0241" Fix explicitly-bidirectional pattern synonyms This partly fixes Trac #13441, at least for the explicitly bidirectional case. See Note [Checking against a pattern signature], the part about "Existential type variables". Alas, the implicitly-bidirectional case is still not quite right, but at least there is a workaround by making it explicitly bidirectional. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:34:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:34:19 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.5408386832863fc20cbd199dc40290b0@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Yay Simon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:35:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:35:07 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions In-Reply-To: <047.5414232b40be6201b11861058f159173@haskell.org> References: <047.5414232b40be6201b11861058f159173@haskell.org> Message-ID: <062.7be9081e9325792ce818406b9530c6cb@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T13466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => ghci/scripts/T13466 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:35:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:35:23 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions In-Reply-To: <047.5414232b40be6201b11861058f159173@haskell.org> References: <047.5414232b40be6201b11861058f159173@haskell.org> Message-ID: <062.eef1cc6aaf18e1bd801e327dd463347b@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T13466 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 Mon Mar 27 15:36:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:36:17 -0000 Subject: [GHC] #13337: GHC doesn't think a type is of kind *, despite having evidence for it In-Reply-To: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> References: <050.78a537abfa1766ba08f13e5953dd97d8@haskell.org> Message-ID: <065.4a2b47d87f468ba8b1d996e4273ecb40@haskell.org> #13337: GHC doesn't think a type is of kind *, despite having evidence for it -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 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:D3315 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Not worth merging this to the 8.2 branch, I think. It's just refactoring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:36:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:36:39 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.2ede73fa5b1c4b189d1245f7b8e670dd@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Also not happening for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:46:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:46:34 -0000 Subject: [GHC] #13466: Ghci panics with type applications to unknown functions In-Reply-To: <047.5414232b40be6201b11861058f159173@haskell.org> References: <047.5414232b40be6201b11861058f159173@haskell.org> Message-ID: <062.37e57d73f35ae0a1681470caa2662cea@haskell.org> #13466: Ghci panics with type applications to unknown functions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.2 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T13466 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 a260938a30192b6bf159fd1a646455d982184d84. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:49:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:49:19 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.2fb6472169fec30b518de0c17ca29d73@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.1 Comment: It seems like this should probably be merged, yes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 15:59:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 15:59: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.c077750a7baddc7918fd72c9725f31d1@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:04:50 -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.d1fdf64b9b18b9c9536f9dc99164ed94@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:09:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:09:10 -0000 Subject: [GHC] #13489: openTempFile fails when the template parameter contain a path separator In-Reply-To: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> References: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> Message-ID: <062.4c4fda3d5ccfd1c97d56ccbaddd798ac@haskell.org> #13489: openTempFile fails when the template parameter contain a path separator -------------------------------------+------------------------------------- Reporter: harendra | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I don't think we want to create any directories in `openTempFile`. Afterall, it would then be unclear whether the user should cleanup the parent directories or just the file. Consequently, I think the right solution here is to simply disallow path separators in the template: if the user wants to specify a directory component then they can provide it in the first argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:10:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:10: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.fd571136560464f329812ce6b11b0547@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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 simonpj): Since `(#,#)` replies `True` to `hasNoBinding` it must be eta-expanded; so it's equivalent to {{{ baz = bar (\x y -> (# x, y #)) }}} and now it'd be rejected by the levity tests. So the levity tests should account for `hasNoBinding`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:18:12 -0000 Subject: [GHC] #13489: openTempFile fails when the template parameter contain a path separator In-Reply-To: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> References: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> Message-ID: <062.ff5e580d6aee147ecc31baafa0332152@haskell.org> #13489: openTempFile fails when the template parameter contain a path separator -------------------------------------+------------------------------------- Reporter: harendra | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I agree, that sounds like the right solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:23:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:23:09 -0000 Subject: [GHC] #13346: Run nofib with -fspec-constr-keen In-Reply-To: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> References: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> Message-ID: <060.a5ddc430180995be1149a33e784251f5@haskell.org> #13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I quickly gave this a shot (testing with 140a2d1c463bd314c9afbeb8d60e739163ce576a). On the whole the results were surprisingly poor. In particular, allocations of several testcases increased markedly. It's Here are the results, {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +5.5% +3.5% 0.070 0.070 0.0% ansi +0.2% -0.0% 0.000 0.000 0.0% atom +0.1% +0.0% 0.147 0.147 0.0% awards +0.4% -0.0% 0.000 0.000 0.0% banner +0.0% 0.0% 0.000 0.000 0.0% bernouilli -0.0% -0.0% 0.093 0.093 0.0% binary-trees 0.0% 0.0% -0.2% -0.2% 0.0% boyer +0.6% -2.1% 0.027 0.027 0.0% boyer2 +1.7% +2.2% 0.006 0.006 0.0% bspt +0.7% +0.0% 0.007 0.007 0.0% cacheprof +3.2% +0.8% +1.4% +1.4% +6.4% calendar 0.0% 0.0% 0.000 0.000 0.0% cichelli +0.4% +3.0% 0.052 0.052 +11.4% circsim +0.3% +0.7% +0.3% +0.3% 0.0% clausify +0.0% -3.8% 0.027 0.027 0.0% comp_lab_zift -0.0% -0.2% 0.112 0.112 0.0% compress -0.1% -0.0% 0.076 0.076 0.0% compress2 -0.0% -0.0% 0.086 0.087 +3.8% constraints +0.1% -0.0% -1.8% -1.8% 0.0% cryptarithm1 0.0% 0.0% +5.7% +5.6% 0.0% cryptarithm2 +2.5% +18.1% 0.008 0.008 0.0% cse 0.0% 0.0% 0.001 0.001 0.0% digits-of-e1 0.0% 0.0% -0.1% -0.1% 0.0% digits-of-e2 0.0% 0.0% -2.3% -2.2% 0.0% eliza +0.5% +0.0% 0.001 0.001 0.0% event -0.0% +0.1% 0.093 0.093 0.0% exp3_8 -0.0% 0.0% 0.102 0.102 0.0% expert +1.0% +0.2% 0.000 0.000 0.0% fannkuch-redux +0.1% 0.0% -0.8% -0.8% 0.0% fasta +0.1% +1.6% 0.184 0.184 0.0% fem +0.9% +1.7% 0.016 0.016 0.0% fft +0.0% -0.1% 0.023 0.023 0.0% fft2 0.0% 0.0% 0.032 0.032 0.0% fibheaps +0.5% +4.0% 0.019 0.019 0.0% fish -0.0% -1.7% 0.008 0.008 0.0% fluid +4.1% +0.2% 0.006 0.006 0.0% fulsom +1.4% +0.1% 0.180 0.180 0.0% gamteb -0.4% +0.3% 0.024 0.024 0.0% gcd 0.0% 0.0% 0.028 0.028 0.0% gen_regexps +0.2% 0.0% 0.000 0.000 0.0% genfft +0.1% +0.9% 0.021 0.021 0.0% gg +1.3% +1.7% 0.008 0.008 0.0% grep -0.4% -0.0% 0.000 0.000 0.0% hidden +0.2% +0.0% +1.3% +1.2% 0.0% hpg +0.6% -0.0% 0.076 0.076 0.0% ida +0.8% +0.7% 0.070 0.070 +166.7% infer -0.3% +4.1% 0.043 0.043 +27.3% integer +0.1% +6.6% -1.3% -1.3% 0.0% integrate -0.0% -0.0% 0.066 0.066 0.0% k-nucleotide +0.6% +0.0% -1.6% -1.6% 0.0% kahan 0.0% 0.0% 0.181 0.181 0.0% knights +0.3% 0.0% 0.005 0.005 0.0% lambda -0.0% 0.0% -0.1% -0.1% 0.0% last-piece +1.4% -1.4% -2.0% -2.0% 0.0% lcss +0.3% +0.0% -4.7% -4.8% 0.0% life -0.0% +0.0% 0.131 0.131 0.0% lift +2.2% +0.4% 0.001 0.001 0.0% linear +0.3% +0.0% -0.1% -0.1% 0.0% listcompr +0.5% -0.3% 0.061 0.061 0.0% listcopy +0.5% -0.3% 0.071 0.071 0.0% maillist 0.0% 0.0% 0.029 0.029 -0.4% mandel +0.1% -0.2% 0.049 0.049 0.0% mandel2 0.0% 0.0% 0.002 0.002 0.0% mate +0.0% -0.8% -1.4% -1.4% 0.0% minimax +0.2% 0.0% 0.002 0.002 0.0% mkhprog 0.0% 0.0% 0.001 0.001 0.0% multiplier +0.1% +0.6% 0.070 0.070 0.0% n-body -0.0% 0.0% -0.0% -0.1% 0.0% nucleic2 +0.1% +0.1% 0.053 0.053 0.0% para -0.3% -0.7% 0.194 0.194 0.0% paraffins 0.0% 0.0% 0.065 0.065 0.0% parser +4.7% +0.0% 0.021 0.021 0.0% parstof +0.9% +10.6% 0.006 0.006 0.0% pic +0.0% +0.0% 0.005 0.005 0.0% pidigits +0.2% +0.0% -1.5% -1.7% -20.0% power +0.4% +0.6% -2.3% -2.4% 0.0% pretty +0.1% +0.0% 0.000 0.000 0.0% primes 0.0% 0.0% 0.034 0.034 0.0% primetest +0.1% -0.2% 0.058 0.058 0.0% prolog +0.3% +0.0% 0.001 0.001 0.0% puzzle +0.0% -0.0% 0.097 0.097 0.0% queens 0.0% 0.0% 0.012 0.012 0.0% reptile +0.2% +0.0% 0.008 0.008 0.0% reverse-complem 0.0% 0.0% 0.082 0.082 0.0% rewrite +0.5% -0.8% 0.016 0.016 0.0% rfib 0.0% 0.0% 0.013 0.013 0.0% rsa 0.0% 0.0% 0.016 0.016 0.0% scc +0.6% +0.7% 0.000 0.000 0.0% sched +0.0% -1.5% 0.018 0.018 0.0% scs -0.1% -0.0% +1.0% +1.0% 0.0% simple +0.4% +0.5% 0.102 0.102 0.0% solid +0.2% +0.0% 0.078 0.078 0.0% sorting +0.3% 0.0% 0.001 0.001 0.0% spectral-norm 0.0% 0.0% +0.2% +0.2% 0.0% sphere +0.2% +0.4% 0.033 0.033 0.0% symalg +0.2% 0.0% 0.007 0.007 0.0% tak 0.0% 0.0% 0.012 0.012 0.0% transform -0.2% +1.9% -1.3% -1.5% 0.0% treejoin +0.3% -1.1% 0.077 0.077 0.0% typecheck -0.4% +0.4% 0.161 0.161 0.0% veritas +4.2% -0.0% 0.001 0.001 0.0% wang +0.0% -0.5% 0.054 0.054 0.0% wave4main +0.8% -0.0% 0.191 0.191 0.0% wheel-sieve1 +0.0% +0.0% 0.118 0.118 0.0% wheel-sieve2 0.0% 0.0% 0.105 0.105 0.0% x2n1 0.0% 0.0% 0.002 0.002 0.0% -------------------------------------------------------------------------------- Min -0.4% -3.8% -4.7% -4.8% -20.0% Max +5.5% +18.1% +5.7% +5.6% +166.7% Geometric Mean +0.4% +0.5% -0.5% -0.6% +1.1% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:36:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:36:55 -0000 Subject: [GHC] #13346: Run nofib with -fspec-constr-keen In-Reply-To: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> References: <045.dd33dfb272bb36064a8022d93fb903e2@haskell.org> Message-ID: <060.ea491482022f91ed2558b5842102bedf@haskell.org> #13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I had a brief look at the Core and ticky profiles for one of the larger regressors, `cryptarithm2`, but unfortunately the differences are quite great so it's hard to tell precisely what is going wrong. I'm going to put this aside for now; at least we have characterized the situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 16:44:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 16:44:26 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.764cd86f1b9dbdf3f7a6e7bca75d3f09@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 19:05:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 19:05: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.045d7933ed70b9d1128bfc24de8872f5@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | 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 Richard Eisenberg ): In [changeset:"cea7141851ce653cb20207da3591d09e73fa396d/ghc" cea71418/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cea7141851ce653cb20207da3591d09e73fa396d" Fix #13458 Core Lint shouldn't check representations of types that don't have representations. test case: typecheck/should_compile/T13458 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 19:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 19:07:01 -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.438407fc8ab22999405f7e4131dcb0dc@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: merge Priority: normal | 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T13458 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:06:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:06:57 -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.97839ec6320248bceb03110fb2b45a63@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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: bgamari => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:09:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:09:59 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.fef35a8c29225c7f30feaeda8f740263@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T13446 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T13446 * milestone: => 8.2.1 Comment: Done by {{{ commit e0ad55f894a8d85dcc099c33c63cfe3d4515d464 Author: Simon Peyton Jones Date: Mon Mar 27 10:32:08 2017 +0100 Fix error-message suppress on given equalities I'd got the logic slightly wrong when reporting type errors for insoluble 'given' equalities. We suppress insoluble givens under some circumstances (see Note [Given errors]), but we then suppressed subsequent 'wanted' errors because the (suppressed) 'given' error "won". Result: no errors at all :-(. This patch fixes it and - Renames TcType.isTyVarUnderDatatype to the more perspicuous TcType.isInsolubleOccursCheck In doing this I realise that I don't understand why we need to keep the insolubles partitioned out separately at all... but that is for another day. }}} Worth merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:11:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:11: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.99d7928efc291d463865dd1b7cefce8d@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: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: bgamari => nomeata Comment: Joachim is going to look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:26:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:26:39 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.909e8ba4c22126ef9f296ebe5770d01b@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3316 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D3316 Comment: OK, so Phab:D3316 is a compromise fix for GHC 8.2. It re-introduces the `tcView`/`coreView` split, making `Type` and `Constraint` distinct in the typechecker and the same there after. We regard this as a stop-gap solution, pending making `Type` and `Constraint` distinct througout the compiler. However, `T11480b` currently fails with Phab:D3316: see comment:69 for why. The plan: * Make the pure unifier use `tcView` not `coreView`. That should fix `T11480b`. * Ensure that `Typeable Type` and `Typeable Constraint` produce different representations; that will fix comment:71 opf #11715 * Accept that a Core program can be unsound, in an obscure way, so long as the stop-gap solution holds. (We don't know any way to exploit this unsoundness from Haskell though.) We should get on with the real solution for 8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:27:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:27:09 -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.b34696a92c8e8b6e26abb4b295ef4387@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 simonpj): Richard is on this. See #11715, comment:74 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:27:54 -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.1b881f1d65e93b686e76f1ec2f887b41@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 goldfire): Actually, Ben is on this. Ben and I spoke this morning, and he agreed to make this change. After he does, I'll go in and add the commentary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 21:29:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 21:29:20 -0000 Subject: [GHC] #13333: Typeable regression in GHC HEAD In-Reply-To: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> References: <050.c38036a6cbd234fe6d52b8fe2010d9db@haskell.org> Message-ID: <065.e73f0f3fd946e92e2794cf13888235c8@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have a solution in progress. But no time to finish now. Soon. It involves adding a case for casts in `matchTypeable`. Not hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 22:03:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 22:03:43 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.a3ca89539b1011cfa53d15c4cd209a66@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Oh, it seems I pasted the link above wrong. I meant to paste [https://perf.haskell.org/ghc/#revision/7b087aeba45a7a70a5553ef4c116ee67660423e8 a link to the perf dashboard for that commit]. There were two significant changes in nofib runtimes. {{{ test old change new nofib/time/k-nucleotide 5.338 + 4.95% 5.602 seconds nofib/time/lambda 1.095 - 3.2% 1.06 seconds }}} There was also an unfortunate increase in nofib sizes that I didn't notice before (gipeda did not flag it for some reason). The sizes went up by a little over 1% across the board. Ouch. I'm guessing this is because we lost the dead code elimination we previously had for {{{#!hs case raiseIO# e s of ... }}} Could we recover that by using some sort of special rule somewhere that rewrites {{{#!hs case raiseIO# e s of p -> ... }}} to `raiseIO# e s`? I could give it a shot if someone tells me where to put it. There were a few test suite allocation regressions, the largest of which were {{{ tests/alloc/T10547 33561264 + 1.36% 34019072 bytes tests/alloc/T5837 51419384 + 1.27% 52074608 bytes tests/alloc/T12425 134735944 + 0.52% 135441336 bytes tests/alloc/T10858 267909584 + 0.49% 269215800 bytes tests/alloc/T13035 93847840 + 0.44% 94264440 bytes tests/alloc/T6048 109461504 + 0.38% 109873560 bytes tests/alloc/T13056 420744984 + 0.37% 422320424 bytes }}} I believe the right way to fix these is to go through any code in `base` that uses `throwIO` and make sure we manually force everything we want to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 22:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 22:59:43 -0000 Subject: [GHC] #13490: Ambiguous types with constraints on new variables Message-ID: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> #13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- 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 fails to compile: {{{ {-# LANGUAGE FlexibleContexts, TypeFamilies #-} import Data.Typeable type family Foo a data C a foo :: (Typeable (C z), z ~ Foo zp) => C zp foo = undefined }}} with the error {{{ • Could not deduce (Typeable z) from the context: (Typeable (C z), z ~ Foo zp) bound by the type signature for: foo :: (Typeable (C z), z ~ Foo zp) => C zp at Bug.hs:(9,8)-(10,9) • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: (Typeable (C z), z ~ Foo zp) => C zp }}} It's quite unclear why GHC feels thta it needs `Typeable z`. The code compiles if I change the `Typeable` constraint to `Typeable (C (Foo zp))`, which should be identical to what I wrote. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 23:23:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 23:23:56 -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.3a434634ffca11965ec183bb746362d5@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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:10 simonpj]: > I have an idea. Consider `Simplify` line 1005 > {{{ > simplExprF1 env (Type ty) cont = ASSERT( contIsRhsOrArg cont ) > rebuild env (Type (substTy env ty)) cont > }}} This wasn't enough unfortunately. Some more RTS/profiling hackery led me to... the next case of the same function: {{{ simplExprF1 env (App fun arg) cont = simplExprF env fun $ case arg of Type ty -> ApplyToTy { sc_arg_ty = substTy env ty , sc_hole_ty = substTy env (exprType fun) , sc_cont = cont } _ -> ApplyToVal { sc_arg = arg, sc_env = env , sc_dup = NoDup, sc_cont = cont } }}} Here `sc_arg_ty` and `sc_hole_ty` apparently need a similar treatment. And with that the space leak seems to be gone! I'll confirm with a clean rebuild. What I still don't understand is why this wasn't always a problem, since those lines have not changed in a long time. I guess there is some new code that manipulates `ApplyToTy`, so maybe the old version of that code did enough evaluation to avoid the space leak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 27 23:25:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Mar 2017 23:25:32 -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.6828778e5f96a44613b11b9aa47197ec@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: merge Priority: normal | 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 rwbarton): This is causing a large number of warnings to be printed while building GHC, of the form {{{ : warning: In the expression: byteArrayContents# (ipv3_s9ST `cast` (UnsafeCo representational (MutableByteArray# RealWorld) ByteArray# :: (MutableByteArray# RealWorld :: TYPE 'UnliftedRep) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: left-hand type is levity-polymorphic From: MutableByteArray# RealWorld To: ByteArray# : warning: In the expression: byteArrayContents# (ipv3_s9ST `cast` (UnsafeCo representational (MutableByteArray# RealWorld) ByteArray# :: (MutableByteArray# RealWorld :: TYPE 'UnliftedRep) ~R# (ByteArray# :: TYPE 'UnliftedRep))) Unsafe coercion: right-hand type is levity-polymorphic From: MutableByteArray# RealWorld To: ByteArray# }}} and these statements do not appear to be correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 00:26:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 00:26:30 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation In-Reply-To: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> References: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> Message-ID: <064.98039c8d766ac6ce529adc14b00a4c06@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template | haskell, recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Yep, it looks like we are not recompiling even though the module dependencies of a module we import have changed. BTW, this looks similar to #7277 but it's not; the module which uses TH is correctly recompiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 02:16:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 02:16:52 -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.cff7140cb57223d9a42779e233b3afc4@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: (none) => rwbarton -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:42:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:42:44 -0000 Subject: [GHC] #13490: Ambiguous types with constraints on new variables In-Reply-To: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> References: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> Message-ID: <062.b740d76b4181978357c272511fe8d595@haskell.org> #13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- 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: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You are walking on thin ice. Consider {{{ f :: Eq [a] => [a] -> [a] f x = [x] == [x] }}} From the RHS we need `Eq [a]` which is provided by the type signature. But GHC could ''also'' solve `Eq [a]` by using `instance Eq a => Eq [a]` (which is usually the right thing to do). Then it would need `Eq a`, ''which it cannot get from `Eq a`''. To avoid this dead end GHC tries to solve "wanted" constraints from "givens" first. But what if it was {{{ f :: (Eq b, b ~ [a]) => [a] -> [a] f x = [x] == [x] }}} Now it's not quite so obvious. I would have expected this still to work, just, because equalities are always solved first. But the ice is a bit thinner. I would have expected your example to work too, just. And so it does in HEAD, and hence in 8.2. But it'd be much more robust to put `(Typeable z)` in the context. Is there some reason you can't do that? I'll add your example as a regression test and close as 'worksforme'. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:50:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:50:20 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.02cb05bddd4330e29843f76aea780b74@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b5c81203d047293f54c4e89ac70d505197968cb3/ghc" b5c81203/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5c81203d047293f54c4e89ac70d505197968cb3" Complete the fix for #13441 (pattern synonyms) Do not attempt to typecheck both directions of an implicitly-bidirectional pattern synonym simultanously, as we were before. Instead, the builder is typechecked when we typecheck the code for the builder, which was of course happening already, even in both bidirectional cases. See Note [Checking against a pattern signature], under "Existential type variables". }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:50:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:50:20 -0000 Subject: [GHC] #13490: Ambiguous types with constraints on new variables In-Reply-To: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> References: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> Message-ID: <062.614256ee5beab3922ae78e9115bfcb04@haskell.org> #13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- 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: 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:"eb6ccb7cd8751cd027ee9913e47f1371bfa62289/ghc" eb6ccb7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb6ccb7cd8751cd027ee9913e47f1371bfa62289" Test Trac #13490 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:52:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:52:34 -0000 Subject: [GHC] #13491: UNIQUE_BITS is not crosscompiler-friendly Message-ID: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> #13491: UNIQUE_BITS is not crosscompiler-friendly -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Things break when I try to build crosscompiler from 32-bit system to 64-bit system. For example i386-linux -> powerpc64-linux: {{{ $ ./configure --target=powerpc64-unknown-linux-gnu --with-system-libffi --with-libffi-includes=/usr/lib/libffi-3.2.1/include/ $ make "inplace/bin/ghc-stage1" -static -H32m -O -optc-I/usr/lib/libffi-3.2.1/include -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wno ncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghc19687_0/ghc_4.s: Assembler messages: /tmp/ghc19687_0/ghc_4.s:11:0: error: Error: unknown pseudo-op: `.l' | 11 | .L�4: | ^ }}} The problem here comes from definition of `UNIQUE_BITS`: {{{#!hs # cat compiler/Unique.h #include "../includes/MachDeps.h" #define UNIQUE_BITS (WORD_SIZE_IN_BITS - 8) }}} Here `WORD_SIZE_IN_BITS` is a target platform size (64) while `stage1` is still running on host platform (32). As a result uniques truncate down to zero: {{{#!hs compiler/basicTypes/Unique.hs: tag = ord c `shiftL` UNIQUE_BITS compiler/basicTypes/Unique.hs: tag = chr (u `shiftR` UNIQUE_BITS) }}} As we operate on host '''Int'''s we could use the following: {{{#!hs #define UNIQUE_BITS sizeof(HsInt) * 8 -- C code #define UNIQUE_BITS (finiteBitSize (undefined :: Int) * 8) -- Haskell code }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:52:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:52:57 -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.6fd9c795dac72fd9b59cebbb73efd50b@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well done! Yes, use `simplType`! Can you add a Note to `simplType` explaining why it is so important to use it rather than naked `substTy` calls; and pointing to this ticket? I suspect that it has been a problem for a long time; just that no one has noticed. It's very uncomfortable that this is so delicate; and even when recognised is so hard to find. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:54:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:54:32 -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.1917c4af2e4322edeb43c86e49a4b921@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: you may then be able to get rid of the call to `coreBindsSize` in `SimplCore`. If so, that would be good: faster compilation! Worth trying... it might I suppose show up another leak currently patched by `coreBindsSize`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:55:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:55:09 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.3f60b009066f9eb724c6a93f08f9547b@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: merge => new Comment: Probably worth merging this too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:55:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:55:20 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.6ce1a7fa88c5c352dc8975dc64289fd6@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 07:55:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 07:55:41 -0000 Subject: [GHC] #13490: Ambiguous types with constraints on new variables In-Reply-To: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> References: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> Message-ID: <062.902eb9741bec88395045bc317a97729e@haskell.org> #13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 10:31:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 10:31:34 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.5913b1ebd9d734eff496f6e3d21aa377@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3386 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"074d13eb3b6489e8b2f555f61496761614a3e207/ghc" 074d13eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="074d13eb3b6489e8b2f555f61496761614a3e207" Fix #13433 Summary: See comments for details. Test Plan: validate Reviewers: mpickering, bgamari, austin, erikd Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3386 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 12:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 12:59:27 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application Message-ID: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Proprietary application is ran on 44 cores (88 with HT) machine (same problem on 12 core). It is Haskell between wxHaskell (wxWidgets for UI) and C API. It is doing FFI calls most of the time. Calls are not so many, but possibly not so fast. I'm trying to profile where is the problem, in which calls. But very strange behaviour is there. "total time" of application that is running 30secs to 1min is showing 0.33secs. Even MAIN function is not 100%. Please, see first part of .prof file: Tue Mar 28 15:38 2017 Time and Allocation Profiling Report (Final) app.exe +RTS -N -A40m -qb0 -p -RTS total time = 0.33 secs (325 ticks @ 1000 us, 1 processor) total alloc = 86,317,264 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc MAIN MAIN 12.6 2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 13:14:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 13:14:18 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.3b60041f7d67e734ab9a8a62c6c2ac8c@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: 13411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The GHC maintainers generally aren't in the business of keeping old GHC releases afloat forever. That being said, many OS distributions do ship versions of GHC with critical patches included to make them work. For instance, I believe hvr's [https://launchpad.net/~hvr/+archive/ubuntu/ghc Ubuntu PPA for GHC] includes a patch (see #12759) needed to make GHC work with recent versions of GCC. Considering that this patch isn't much work to apply, we might be able to convince Phyx- to apply it to his [https://github.com/Mistuke/GhcChoco Chocolatey GHC packages] if we ask him nicely :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 13:37:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 13:37:56 -0000 Subject: [GHC] #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) In-Reply-To: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> References: <044.52ca76c6bc8fea6c718d1dcbf9a776e9@haskell.org> Message-ID: <059.61d3a17e326d8e8b89e77b72b215e76e@haskell.org> #13472: `gcc.exe' failed in phase `Assembler'. (Exit code: -1073741502) -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: 13411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I generally agree that we shouldn't keep updating older releases. I can apply it to the chocolatey distros but, that said, this is a special case. To emphasise the issue: In a few weeks (and at the pace 8.2 is going, likely before 8.2 is released) we won't have a single working official release of the compiler on Windows 10 at all. Given Microsoft's upgrade policy, the "Creator's Update" (reportedly build 15063) will be shoved down your throat no matter if you want it or not. We risk the situation that no one on Windows 10 can use GHC at all, which is not a good situation to be in. I'm sure the stack folks can patch their distros as well. But I think we should have at least a discussion about this, and what happens if it happens again in the future, given the much higher cadence of Windows releases these days. There are more Windows releases than GHC releases these days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 15:06:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 15:06:00 -0000 Subject: [GHC] #13490: Ambiguous types with constraints on new variables In-Reply-To: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> References: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> Message-ID: <062.02844938745dc7e1f7ffe9fb99632444@haskell.org> #13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | 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 crockeea): Simon, your explanation seems similar to #11948. Are they related? I'm still wondering about this ticket. Why am I getting an ambiguous type error, and since the definition is `undefined`, why does GHC have to do any work at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 16:17:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 16:17:08 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.9efc542f84854c484490cff27293ce4d@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 simonmar): I quite like the idea of adding the call stack to `SomeException` actually. A lot of rethrowing operations already do the right thing, e.g. `catchJust` works: {{{ catchJust p a handler = catch a handler' where handler' e = case p e of Nothing -> throwIO e Just b -> handler b }}} So does `onException`, and the things that use it (`bracket` etc.) {{{ onException :: IO a -> IO b -> IO a onException io what = io `catch` \e -> do _ <- what throwIO (e :: SomeException) }}} So the places that don't work are those places that are using bare `catch` and re-throwing a more specific exception after doing some filtering on it. For those we should recommend using `catchJust` when possible, and perhaps provide alternative APIs that allow more expressive filtering. In the meantime there will be some places that get the wrong call stacks, but too bad - this is a debugging feature and as such doesn't need to be perfect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 16:49:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 16:49:05 -0000 Subject: [GHC] #13493: Recompilation avoidance and Backpack Message-ID: <045.f826ff93919b2101633c6970aee5c034@haskell.org> #13493: Recompilation avoidance and Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: recomp | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Today, recompilation avoidance is centered around two major mechanisms: 1. First, we keep track of entities we *use* (`tcg_dus`), which is done by reading off all external names from the renamed source code of a Haskell source file. 2. Second, we keep track of what we *import* (`tcg_imports`), which tracked when we rename imports. These two pieces of information get assembled into a module-indexed series of usages in `mk_mod_usage_info`. The general idea is that when an entity is used, we must record the hash of the entity; when a module is imported, we must record its export hash. There is an implicit assumption here, which is that a (direct) import is the only way we depend on the exports of a module, and an occurrence of a name in the renamed syntax is the only way we depend on an actual entity. Backpack breaks these assumptions: * When we perform signature merging, we depend on the exports and entities of each of the signatures we merge in. Furthermore, it is important to distinguish each of these by identity module (not semantic module, which collapses the distinction.) * When we instantiate a module, we depend on the exports and entities of the implementing module. When I initially implemented Backpack, I slowly added extra information to fix recompilation problems as I noticed them. I thus accreted the following recompilation avoidance mechanisms: * When signature merging occurs, we specially record the module hash for each used merge requirement as a special new field `UsageMergedRequirement`, and recomp if the module hash changed at all. We also add each merged signature to ImportAvails (but not as an "import") to ensure we pick up family instances. * When we instantiate a module, we treat it as if we had a direct import of it (not yet merged, in https://phabricator.haskell.org/D3381). Since instantiations are always referencing non-local modules, we'll always record a module hash in such cases. This is quite a hodgepodge, and I have no confidence that it is correct. For example, if an implementing module reexports an entity from another module, and that original entity changes, I doubt we recompile at this point. We "accidentally" handle the case when it's not a reexport because we record the module hash for the entire instantiating module. It seems that it would be better if we can recast this in terms of imports and usages. Here is a try at the design: * In both instantiation and merging, we must record the export hash of the modules we instantiated/merged in. It is a little troublesome to think of these as imports, however, because they're not (and if you try to implement this, you find yourself making a fake ImportedModVal for an import that doesn't exist); I think the correct thing here is to introduce a new notion of dependency for things that don't correspond to source level imports (another possibility is to add another constructor to ImportedModVal but the effect of this on existing code would have to be determined.) * The usages when we instantiate a signature are the (instantiated) usages of the original signature (in particular, this picks up the usages from instance lookup), plus a usage for each entity that we match against (because we must rematch if the type changes.) * Usages for signature merging are a little trickier. We want a usage for every entity that we end up merging in (so, we must record usages post thinning), BUT we must make sure the usage points at the identity module of the signature that originally provided it, not the semantic module (which will invariably point to the current module under compilation.) One more thing: when we instantiate a module on-the-fly, we need to account for how we instantiated it (to put it differently, the recompilation information we compute when we do on-the-fly should be the (morally) the same as what we would get if we actually compiled the modules in question. This is a bit troublesome since we don't have detailed information relating how a signature was instantiated and what we used (the on-the-fly instantiation process shortcuts this). The simplest thing is probably to just record the module hashes of each module that was used to instantiate an imported module (recursively); we might be able to do this even by just twiddling `mi_mod_hash` hash when we instantiate (the alternative is to switch to recording InstalledModule/InstalledUnitId only in hashes, and augmenting usage information to also carry along instantiations.) Another problem is that we record usages for Module (instantiated things), but hashes are actually on an InstalledModule basis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 18:16:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 18:16:47 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.667db3427d0fd5e1dda4573d4c92ae08@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 ekmett): Replying to [comment:17 ezyang]: > Your wiki page does comment that call stacks are preserved if you rethrow SomeException. But this often doesn't happen in practice. For example, the `system-fileio` example above rethrows an `IOError`: oops, call stack lost. Yes, there is no correct way to preserve this information that doesn't require the user signalling intent to us. Is what they are throwing a truly fresh exception or does it derive from one they were given? On the other hand, the very callstack was information you lacked to begin with in the old story. If we extend SomeException you can write code that is compatible with both the old and new story, and you can make a couple of one line tweaks to your code to make it so you can preserve the shiny new callstack information. If we extend _every_ exception type to carry this information then there is no code that has ever been written against the exception hierarchy that can survive the change. Moreover, the Exception class itself then has to provide a means for us to get in and find and replace the callStack in these user definable data types, and the user has to construct an empty callstack to throw their exception in the first place, all of which seems like a messy, invasive, and slow design. If we offer some subset of combinators (subject to bikeshedding) like {{{#!hs throwWithCallStack :: Exception e => e -> CallStack -> a withCallStack :: SomeException -> CallStack -> SomeException rethrow :: SomeException -> a rethrowAs :: Exception => SomeException -> e -> a throwIOWithCallStack, rethrowIO, rethrowIOAs ... catchWithCallStack :: Exception e => IO a -> (e -> CallStack -> IO a) -> IO a ... }}} to the user, then they can fix up these cases as they find them, and in the meantime they only get the callstack up to the last `throw`, which is __still__ more information than they have today. The same scenario involving destroying the source location happens in languages like c++ w/ throw vs rethrow. I personally am sad that extending `SomeException` with the callstack would mean my pretty little prisms into `SomeException` for the various exception types become a (convenient) lie, but I don't think the alternative of making the user decorate all of their exception types with a callstack, mangle every throw so that they include an empty callstack to kickstart the exception, and supply a callstack update function, and change all of their existing handlers, most of which do not rethrow, to deal with an extra argument is a terribly practical alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 20:13:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 20:13:27 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.0c03a736182e5cadf9ab6b29e0580697@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: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): The problem is that Call Arity has not been changed to know about the special semantics of join points. This is the code for in question: {{{ f :: forall a. [Int] -> a [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 128 0}] f = \ (@ a_a1iy) (a_XX6 :: [Int]) -> let { z_a34C :: Integer -> a_a1iy [LclId, CallArity=1, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 28 0}] z_a34C = joinrec { go_a34D [Occ=LoopBreaker] :: [Int] -> Integer -> a_a1iy [LclId[JoinId(1)], Arity=1, CallArity=2, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30] 24 0}] go_a34D (ds_a34E :: [Int]) = case ds_a34E of { [] -> case lvl_s4VT of wild_00 { }; : y_a34J ys_a34K -> jump go_a34D ys_a34K }; } in jump go_a34D a_XX6 } in letrec { go_a34D [Occ=LoopBreaker] :: [Int] -> Integer -> a_a1iy [LclId, Arity=1, CallArity=2, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30] 40 0}] go_a34D = \ (ds_a34E :: [Int]) -> case ds_a34E of { [] -> z_a34C; : y_a34J ys_a34K -> go_a34D ys_a34K }; } in go_a34D a_XX6 lvl_s4VV }}} Call Arity (which analyzes things from bottom to top) correctly finds out that the bottom `go_a34D` should have arity 2 (it is called with two arguments, and keeps passing the second one around). This implies that `z_a34C` is called with one argument, so that gets `CallArity=1`. From this Call Arity follows that to first `go_a34D` (the join point) should also have arity two, and it records it so. The subsequent simplification then eta-expands the `go_a34D` function, which turns it into a join point (yay!). But it does not *not* eta-expand the join point `go_a34D` (which gets renamed to `go_X45x`): {{{ f = \ (@ a_a1iy) (a_XX6 :: [Int]) -> joinrec { go_a34D [Occ=LoopBreaker] :: [Int] -> Integer -> a_a1iy [LclId[JoinId(2)], Arity=2, CallArity=2, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [36 0] 54 0}] go_a34D (ds_a34E :: [Int]) (eta_B1 :: Integer) = case ds_a34E of { [] -> joinrec { go_X35x [Occ=LoopBreaker] :: [Int] -> a_a1iy [LclId[JoinId(1)], Arity=1, CallArity=2, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30] 24 0}] go_X35x (ds_X35z :: [Int]) = case ds_X35z of { [] -> case lvl_s4VT of wild_00 { }; : y_a34J ys_a34K -> jump go_X35x ys_a34K }; } in jump go_X35x a_XX6; : y_a34J ys_a34K -> jump go_a34D ys_a34K eta_B1 }; } in jump go_a34D a_XX6 lvl_s4VV }}} At this point, something went wrong. The now named `go_X45x` is still marked as having CallArity=2, but it does not actually have that arity! Where did the argument `eta_B1`, which I would have expected to be passed to `go_X35x`, disappear? Was it “pushed into the branches”, and then into the empty set branches of the empty case there? So the simplifier uses the function `tryEtaExpandRhs` to try to eta-expand if Call Arity tells it to do so, but it does not even try that for join points (see `completeBind` in `Simplify`). I am a bit lost in the code right now and cannot quite reproduce what precisely is happening here. Something related to `simplJoinRHS` and “Context goes *inside* the lambdas.” Certainly, Luke’s opinion would be welcome. In any case, I believe the fix is to have the simplifier to simply zap Call Arity information. It is the only place where it is actually used, and as this demonstrates, the simplifier does not preserve Call Arity information. I will prepare a PR for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 20:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 20:22:50 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.4dc1416e476daf85d4be85822a487505@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3390 Comment: Patch ready and under scrutinee by Harbormaster and perf.haskell.org. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 20:33:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 20:33:33 -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.f94058e142b3d9d8cc9986b5daee9475@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): There was actually a third required change which I had guessed at earlier, namely changing {{{#!hs simplExprF1 env (Case scrut bndr _ alts) cont = simplExprF env scrut (Select { sc_dup = NoDup, sc_bndr = bndr }}} to {{{#!hs simplExprF1 env (Case scrut bndr ty alts) cont = seqType ty `seq` simplExprF env scrut (Select { sc_dup = NoDup, sc_bndr = bndr }}} Alternatively, one can insert a `seqType` into `reallyRebuildCase`: {{{#!diff @@ -2222,7 +2223,7 @@ reallyRebuildCase env scrut case_bndr alts cont ; dflags <- getDynFlags ; let alts_ty' = contResultType dup_cont - ; case_expr <- seqType alts_ty' `seq` mkCase dflags scrut' case_bndr' alts_ty' alts' + ; case_expr <- mkCase dflags scrut' case_bndr' alts_ty' alts' }}} I don't understand specifically why these changes make any difference, especially the first one, where we were throwing away the `ty` field anyways. It must share structure with some other part of the program, but I'm not sure what. Replying to [comment:14 simonpj]: > PS: you may then be able to get rid of the call to `coreBindsSize` in `SimplCore`. If so, that would be good: faster compilation! Worth trying... it might I suppose show up another leak currently patched by `coreBindsSize`. Yes, I'll try that next as I have a good setup for finding leaks now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 21:28:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 21:28:13 -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.4c430c12d424c6cbce868728385af505@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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:3391 Comment: Phab:3391 is for removing the added Core Lint pass after occurrence analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 21:39:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 21:39:50 -0000 Subject: [GHC] #13494: ASSERT failed in compiler/typecheck/TcErrors.hs Message-ID: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> #13494: ASSERT failed in compiler/typecheck/TcErrors.hs -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- One of the commits in the range https://github.com/ghc/ghc/compare/a6675a93efe7...de4723fd6d97 which were commited by SPJ, broke running the test suite with a `-DDEBUG` compiler: {{{ +++ /tmp/ghctest-sw9832/test spaces/./indexed- types/should_fail/T2627b.run/T2627b.comp.stderr.normalised 2017-03-27 16:28:10.448037112 +0000 @@ -1,13 +1,17 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.3.20170327 for x86_64-unknown-linux): + ASSERT failed! + b0_a1gy[tau:4] + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcErrors.hs:: in :TcErrors + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcErrors.hs:: in :TcErrors -T2627b.hs:20:24: - Couldn't match type ‘b0’ with ‘Dual (Dual b0)’ - arising from a use of ‘conn’ - ‘b0’ is untouchable - inside the constraints: b ~ W e f - bound by a pattern with constructor: - Wr :: forall e f. e -> Comm f -> Comm (W e f), - in an equation for ‘conn’ - at T2627b.hs:20:14-19 - In the expression: conn undefined undefined - In an equation for ‘conn’: - conn (Rd k) (Wr a r) = conn undefined undefined +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} See https://s3.amazonaws.com/archive.travis-ci.org/jobs/215578687/log.txt for a full log. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 22:36:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 22:36:43 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.c52fab39a4f3ec258da333c0eb0ac1c2@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): I tried to write {{{#!hs a `foo` @Bar b }}} the other day and was surprised it didn't work. I'd like to see this implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 23:35:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 23:35:59 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.56aec6d397c954c212aa603a4bda2958@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"e07211f752b9b98e2bd6957f126bd537d178041a/ghc" e07211f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e07211f752b9b98e2bd6957f126bd537d178041a" Zap Call Arity info in the simplifier As #13479 shows, there are corner cases where the simplifier decides to not eta-expand a function as much as its call arity would suggest, but instead transforms the code that the call arity annotation becomes a lie. As the call arity information is only meant to be used by the immediatelly following simplifier run, it makes sense to simply zap the information there. Differential Revision: https://phabricator.haskell.org/D3390 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 23:36:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 23:36:10 -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.7d3dd78d95b2ebef7a3915d0bd5c8de8@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: | -------------------------------------+------------------------------------- Old description: > Need to look at some modest performance regressions for the main join- > point patch (#12988, wiki [wiki:SequentCore]): > > * `perf/compiler/T9961`: `bytes_allocated` > * `perf/compiler/T10356`: `bytes_allocated` > * `perf/compiler/T1969`: `max_bytes_used` > * `perf/compile/T9020`: see > [https://git.haskell.org/ghc.git/commitdiff/c2becee48aa73795cbf04905f3891f543f1c746e] > * `deriving/perf/T10858`: `bytes_allocated` New description: Need to look at some modest performance regressions for the main join- point patch (#12988, wiki [wiki:SequentCore]): * `perf/compiler/T9961`: `bytes_allocated` * `perf/compiler/T13056`: `bytes_allocated` * `perf/compiler/T1969`: `max_bytes_used` * `perf/compile/T9020`: see [https://git.haskell.org/ghc.git/commitdiff/c2becee48aa73795cbf04905f3891f543f1c746e] * ~~`deriving/perf/T10858`: `bytes_allocated`~~ (was due to `-dcore-lint`) -- Comment (by rwbarton): One of the performance test regressions was due to Core Lint running more and is fixed by the above patch. The others remain to be investigated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 23:36:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 23:36:41 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.e5250087c6548d9f98ca87b55d001b0c@haskell.org> #13479: Core Lint issues during slowtest -------------------------------------+------------------------------------- Reporter: bgamari | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #10181 | Differential Rev(s): Phab:D3390 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge Comment: Fixed, please merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 28 23:59:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Mar 2017 23:59:33 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.d1be46b47c6a90b5917b385ef570e793@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 00:00:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 00:00:13 -0000 Subject: [GHC] #5288: Less noisy version of -fwarn-name-shadowing In-Reply-To: <053.61d200976f34aba1aca2962b3d96dae2@haskell.org> References: <053.61d200976f34aba1aca2962b3d96dae2@haskell.org> Message-ID: <068.ab0a864b98454b4aed50a5bac7d8d8e3@haskell.org> #5288: Less noisy version of -fwarn-name-shadowing -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): +1 (and is there a better way to say "I like this idea" than adding a "+1" comment like this?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 00:01:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 00:01:20 -0000 Subject: [GHC] #5288: Less noisy version of -fwarn-name-shadowing In-Reply-To: <053.61d200976f34aba1aca2962b3d96dae2@haskell.org> References: <053.61d200976f34aba1aca2962b3d96dae2@haskell.org> Message-ID: <068.d91732a3fef4bdce47ec760a870d1185@haskell.org> #5288: Less noisy version of -fwarn-name-shadowing -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * cc: nathan.collins@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 00:16:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 00:16:59 -0000 Subject: [GHC] #12964: Runtime regression to RTS change In-Reply-To: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> References: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> Message-ID: <061.6107fa70f289963002fdfcfd185a55e1@haskell.org> #12964: Runtime regression to RTS change -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 02:38:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 02:38:12 -0000 Subject: [GHC] #13479: Core Lint issues during slowtest In-Reply-To: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> References: <046.86fc8bb754ac201bb49f9ebcb50a495e@haskell.org> Message-ID: <061.32946f2021242b5868ae3707fd30322a@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: 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 bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as d88d0258204bf8d4aadd57280b8322890e5b98b3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 08:22:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 08:22:29 -0000 Subject: [GHC] #13494: ASSERT failed in compiler/typecheck/TcErrors.hs In-Reply-To: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> References: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> Message-ID: <061.30cbafe09072543fed9c7aaca332ea45@haskell.org> #13494: ASSERT failed in compiler/typecheck/TcErrors.hs -------------------------------------+------------------------------------- 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 simonpj): I'm on this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 08:24:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 08:24:01 -0000 Subject: [GHC] #5288: Less noisy version of -fwarn-name-shadowing In-Reply-To: <053.61d200976f34aba1aca2962b3d96dae2@haskell.org> References: <053.61d200976f34aba1aca2962b3d96dae2@haskell.org> Message-ID: <068.eb1af590e98d1b052f8323957cd74175@haskell.org> #5288: Less noisy version of -fwarn-name-shadowing -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think there still needs to be a proper specification and then of course an implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 10:19:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 10:19:10 -0000 Subject: [GHC] #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC Message-ID: <042.01198c06f32ffd32a946f96081bf35de@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: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- We have a product based on a Freescale MPC8544E. I have previously built powerpc-unknown-linux-gnuspe-ghc-7.8.3 and that produces viable code though annoyingly rather large binaries but this is covered elsewhere. I looked at both 7.8.4 and 7.10 a while ago but they proved to be non- starters for reasons I no longer remember. Now for reasons tooling reasons (Stack and friends) it would be nice to use 8.0.2 My procedure is as follows In the (ghc-7.83 or) ghc-8.0.2 source directory base=powerpc-unknown-linux-gnuspe; ./configure --prefix=/tmp/prefix --target=$base --with-gcc=$base-gcc --with-ld=$base-ld --with-nm=$base-nm --with-ar=$base-ar --with-ranlib=$base-ranlib --enable-unregisterised I edit mk/build.mk to make flavour "quick-cross" I edit ghc.mk and comment out anything with haskeline or terminfo The bottom of settings says ("Unregisterised", "YES"), ("LLVM llc command", "/usr/bin/llc-3.7"), ("LLVM opt command", "/usr/bin/opt-3.7") But the make itself (on Ubuntu 16 amd64) fails. "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -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/autogen -Ilibraries/ghc-prim/dist- install/build -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 -O -fllvm -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 -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.0.2 for powerpc-unknown-linux): LlvmCodeGen.Ppr: Cross compiling without valid target info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 13:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 13:59:27 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.44dbaa60407ca069ff765ad537db9373@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T13446 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f88ac374c5cb150d4f172fb40be338d2112a0600/ghc" f88ac374/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f88ac374c5cb150d4f172fb40be338d2112a0600" Fix ASSERT failure in TcErrors This fixes Trac #13494, by improving commit e0ad55f894a8d85dcc099c33c63cfe3d4515d464 Author: Simon Peyton Jones Date: Mon Mar 27 10:32:08 2017 +0100 Fix error-message suppress on given equalities which in turn was a fix to #13446 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 13:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 13:59:27 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.f7098ac33d5a52ef8816767e7f1fed3e@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints, | SpecConstr 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:"8674883c137401873fd53a6963acd33af651c2af/ghc" 8674883c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8674883c137401873fd53a6963acd33af651c2af" Allow unbound Refl binders in a RULE Trac #13410 was failing because we had a RULE with a binder (c :: t~t) and the /occurrences/ of c on the LHS were being optimised to Refl, leaving a binder that would not be filled in by matching the LHS of the rule. I flirted with trying to ensure that occurrences (c :: t~t) are not optimised to Relf, but that turned out to be fragile; it was being done, for good reasons, in multiple places, including - TyCoRep.substCoVarBndr - Simplify.simplCast - Corecion.mkCoVarCo So I fixed it in one place by making Rules.matchN deal happily with an unbound binder (c :: t~t). Quite easy. See "Coercion variables" in Note [Unbound RULE binders] in Rules. In addition, I needed to make CoreLint be happy with an bound RULE binder that is a Relf coercion variable In debugging this, I was perplexed that occurrences of a variable (c :: t~t) mysteriously turned into Refl. I found out how it was happening, and decided to move it: * In TyCoRep.substCoVarBndr, do not substitute Refl for a binder (c :: t~t). * In mkCoVarCo do not optimise (c :: t~t) to Refl. Instead, we do this optimisation in optCoercion (specifically opt_co4) where, surprisingly, the optimisation was /not/ being done. This has no effect on what programs compile; it just moves a relatively-expensive optimisation to optCoercion, where it seems more properly to belong. It's actually not clear to me which is really "better", but this way round is less surprising. One small simplifying refactoring * Eliminate TyCoRep.substCoVarBndrCallback, which was only called locally. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 13:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 13:59:27 -0000 Subject: [GHC] #13494: ASSERT failed in compiler/typecheck/TcErrors.hs In-Reply-To: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> References: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> Message-ID: <061.3cf8a17716beb3eb55ee0da43bc430eb@haskell.org> #13494: ASSERT failed in compiler/typecheck/TcErrors.hs -------------------------------------+------------------------------------- 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 Simon Peyton Jones ): In [changeset:"f88ac374c5cb150d4f172fb40be338d2112a0600/ghc" f88ac374/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f88ac374c5cb150d4f172fb40be338d2112a0600" Fix ASSERT failure in TcErrors This fixes Trac #13494, by improving commit e0ad55f894a8d85dcc099c33c63cfe3d4515d464 Author: Simon Peyton Jones Date: Mon Mar 27 10:32:08 2017 +0100 Fix error-message suppress on given equalities which in turn was a fix to #13446 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 14:02:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 14:02:42 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.ee2baa4259a94bdbb6f1623b4e080f50@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints, | SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T13410 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => simplCore/should_compile/T13410 Comment: OK, done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 14:03:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 14:03:12 -0000 Subject: [GHC] #13494: ASSERT failed in compiler/typecheck/TcErrors.hs In-Reply-To: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> References: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> Message-ID: <061.bdf4da99aa831864169e72ded79d55ad@haskell.org> #13494: ASSERT failed in compiler/typecheck/TcErrors.hs -------------------------------------+------------------------------------- Reporter: nomeata | 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 simonpj): * status: new => merge Comment: Need to merge the fix for #13446 first; or neither. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 14:13:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 14:13:41 -0000 Subject: [GHC] #13496: Add Generic instance to GHC.Stack.SrcLoc Message-ID: <047.9b98f75422c4e776cfed91f1a43ce507@haskell.org> #13496: Add Generic instance to GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Useful for deriving orphan instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 14:37:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 14:37:12 -0000 Subject: [GHC] #13496: Add Generic instance to GHC.Stack.SrcLoc In-Reply-To: <047.9b98f75422c4e776cfed91f1a43ce507@haskell.org> References: <047.9b98f75422c4e776cfed91f1a43ce507@haskell.org> Message-ID: <062.33a10de97c5d87f28f789481a2c5467d@haskell.org> #13496: Add Generic instance to GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: Fuuzetsu | 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 RyanGlScott): Sounds reasonable to me. Can you prepare a patch which implements this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 15:09:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 15:09:00 -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.726d7fddc4338c36f764afece06646ec@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow, I have no idea how you found that! Well done. > Alternatively, one can insert a seqType into reallyRebuildCase: That would be ''much'' better. That kills the leak when we build a `Case`, whereas the former alternative waits until the ''subsequent'' run of the simplifier before squashing it. Please add a `Note` to explain the `seq` (point to this ticket too). Does it need to be a `seqType` or will `seq` do? I expect that `seq` would be enough, since the `OutType` returned by `contResultType` is (I think) a result of calling `simplType`. > It must share structure with some other part of the program, but I'm not sure what. My guess: `exprType` often returns that type. Still I'm surprised that it leads to a ''cumulative'' space leak (i.e. every growing). Does it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 15:25:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 15:25:48 -0000 Subject: [GHC] #13490: Ambiguous types with constraints on new variables In-Reply-To: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> References: <047.d56b59b860596841b19fe5cc5b0612e8@haskell.org> Message-ID: <062.77a89d4e4f07d28acd1bea817c09d28d@haskell.org> #13490: Ambiguous types with constraints on new variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | 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): > Why am I getting an ambiguous type error The "ambiguous type" check works like this. Suppose we have {{{ foo :: ty foo = blah }}} When is foo's type ambiguous? Answer: consider {{{ foo2 :: ty foo2 = foo }}} Does `foo2` typecheck OK? If not, `foo`'s type is ambiguous. Classic example {{{ foo :: (Read a, Show a) => String -> String foo x = show (read x) foo2 :: (Read a, Show a) => String -> String foo2 = foo -- Error! }}} Now in your case we try {{{ foo2 :: (Typeable (C z), z ~ Foo zp) => C zp foo2 = foo }}} and it's this check (i.e. precisely the ambiguous-type test) that fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 15:47:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 15:47:39 -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.89a9f86ff6ebdf0cd7fccec9f2b78cbe@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: | ----------------------------------------+------------------------------- Changes (by bgamari): * cc: trommler, slyfox (added) * milestone: => 8.2.1 Comment: CCing the appropriate contributors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 16:04:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 16:04:32 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC In-Reply-To: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> References: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> Message-ID: <059.6f5821f62b793c29151d663de4b07850@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jms): Remember Linux, depending on its VM settings often overcommits itself. Suggest you allow the virtual machine _far_ more memory than currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 16:09:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 16:09:13 -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.8c2edb3c045779d42ac435c97996f7aa@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: | ----------------------------------------+------------------------------- Old description: > We have a product based on a Freescale MPC8544E. > > I have previously built powerpc-unknown-linux-gnuspe-ghc-7.8.3 and that > produces viable code though annoyingly rather large binaries but this is > covered elsewhere. > > I looked at both 7.8.4 and 7.10 a while ago but they proved to be non- > starters for reasons I no longer remember. > > Now for reasons tooling reasons (Stack and friends) it would be nice to > use 8.0.2 > > My procedure is as follows > > In the (ghc-7.83 or) ghc-8.0.2 source directory > > base=powerpc-unknown-linux-gnuspe; ./configure --prefix=/tmp/prefix > --target=$base --with-gcc=$base-gcc --with-ld=$base-ld --with-nm=$base-nm > --with-ar=$base-ar --with-ranlib=$base-ranlib --enable-unregisterised > > I edit mk/build.mk to make flavour "quick-cross" > > I edit ghc.mk and comment out anything with haskeline or terminfo > > The bottom of settings says ("Unregisterised", "YES"), ("LLVM llc > command", "/usr/bin/llc-3.7"), ("LLVM opt command", "/usr/bin/opt-3.7") > > But the make itself (on Ubuntu 16 amd64) fails. > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m > -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/autogen -Ilibraries/ghc-prim > /dist-install/build -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 -O -fllvm -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 -c > libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- > install/build/GHC/Types.o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.0.2 for powerpc-unknown-linux): > LlvmCodeGen.Ppr: Cross compiling without valid target info. New description: We have a product based on a Freescale MPC8544E. I have previously built powerpc-unknown-linux-gnuspe-ghc-7.8.3 and that produces viable code though annoyingly rather large binaries but this is covered elsewhere. I looked at both 7.8.4 and 7.10 a while ago but they proved to be non- starters for reasons I no longer remember. Now for reasons tooling reasons (Stack and friends) it would be nice to use 8.0.2 My procedure is as follows In the (ghc-7.83 or) ghc-8.0.2 source directory {{{ base=powerpc-unknown-linux-gnuspe; ./configure --prefix=/tmp/prefix --target=$base --with-gcc=$base-gcc --with-ld=$base-ld --with-nm=$base-nm --with-ar=$base-ar --with-ranlib=$base-ranlib --enable-unregisterised }}} I edit mk/build.mk to make flavour "quick-cross" I edit ghc.mk and comment out anything with haskeline or terminfo The bottom of settings says ("Unregisterised", "YES"), ("LLVM llc command", "/usr/bin/llc-3.7"), ("LLVM opt command", "/usr/bin/opt-3.7") But the make itself (on Ubuntu 16 amd64) fails. {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -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/autogen -Ilibraries/ghc-prim/dist- install/build -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 -O -fllvm -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 -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.0.2 for powerpc-unknown-linux): LlvmCodeGen.Ppr: Cross compiling without valid target info. }}} -- Comment (by bgamari): Given that you are trying to build an unregisterised compiler, it's quite unclear to me how this `-fllvm` is sneaking into the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 17:26:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 17:26:26 -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.2665c77f4f1b222586ead8116cf92fdb@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 nh2): Ai, it seems that ghc 8.0.2 changed some behaviour here: {{{ import System.IO import System.Timeout main = hWaitForInput stdin (5 * 1000) }}} On ghc 8.0.2, this crashes with `fdReady: msecs != 0, this shouldn't happen`. On ghc 8.0.1, this works as expected (doing nothing, terminating after 5 seconds). Probably this commit: https://github.com/ghc/ghc/commit/f46369b8a1bf90a3bdc30f2b566c3a7e03672518 #diff-f727d72230bd33b0e218d47df4738565R28 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 17:32:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 17:32:02 -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.62d8da645f43a3adcec1d54029258e0a@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 nh2): Note this change breaks the following code: {{{ import System.IO import System.Timeout main = hWaitForInput stdin (5 * 1000) }}} See https://ghc.haskell.org/trac/ghc/ticket/8684#comment:8 Is that expected? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 17:58:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 17:58:14 -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.15df3ad2b2e947124b62182c0df42820@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: | -------------------------------------+------------------------------------- Description changed by nh2: Old description: > http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html > > claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact > that's false (e.g. mentioned in > https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4). > > {{{ > -- import Control.Concurrent > import System.IO > import System.Timeout > > main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000) > }}} > > will not be killed after 1 second, but instead wait for the full 5 > seconds timeout passed to {{{hWaitForInput}}}. > > The implementation is {{{ready}}} at > http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-IO- > FD.html, where we have two foreign calls: {{{safe fdReady}}} and > {{{unsafe unsafe_fdReady}}}. > > The actual C implementation is at https://github.com/haskell- > suite/base/blob/master/cbits/inputReady.c#L16. It uses {{{select}}} on > Unix, and does check for {{{EINTR}}}, so I believe that according to > http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi- > interruptible both foreign calls can be replaced by a single > {{{interruptible}}} one. > > Is that true? > > If not, it's a documentation bug in {{{timeout}}} at least. > > Also, does {{{interruptible}}}, apart from allowing the function to be > interrupted, behave more like {{{safe}}} or {{{unsafe}}}? New description: http://hackage.haskell.org/package/base-4.6.0.1/docs/System-Timeout.html claims that {{{timeout}}} can interrupt {{{hWaitForInput}}}, but in fact that's false (e.g. mentioned in https://ghc.haskell.org/trac/ghc/ticket/7353#comment:4). {{{ -- import Control.Concurrent import System.IO import System.Timeout main = timeout (1 * 1000000) $ hWaitForInput stdin (5 * 1000) }}} will not be killed after 1 second, but instead wait for the full 5 seconds timeout passed to {{{hWaitForInput}}}. The implementation is {{{ready}}} at https://downloads.haskell.org/~ghc/7.6.3/docs/html/libraries/base/src/GHC- IO-FD.html, where we have two foreign calls: {{{safe fdReady}}} and {{{unsafe unsafe_fdReady}}}. The actual C implementation is at https://github.com/ghc/packages- base/blob/52c0b09036c36f1ed928663abb2f295fd36a88bb/cbits/inputReady.c#L16. It uses {{{select}}} on Unix, and does check for {{{EINTR}}}, so I believe that according to http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/ffi.html#ffi- interruptible both foreign calls can be replaced by a single {{{interruptible}}} one. Is that true? If not, it's a documentation bug in {{{timeout}}} at least. Also, does {{{interruptible}}}, apart from allowing the function to be interrupted, behave more like {{{safe}}} or {{{unsafe}}}? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:00:27 -0000 Subject: [GHC] #13491: UNIQUE_BITS is not crosscompiler-friendly In-Reply-To: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> References: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> Message-ID: <060.495fe71cc5426135f443837c46e340eb@haskell.org> #13491: UNIQUE_BITS is not crosscompiler-friendly -------------------------------------+------------------------------------- Reporter: slyfox | 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): Phab:D3397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D3397 Comment: Sent https://phabricator.haskell.org/D3397 for review -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:13:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:13:59 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms Message-ID: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From my discovery at https://phabricator.haskell.org/D42#30542: {{{ Why does the existing code work on platforms that are not Linux? In my select man page it says: On Linux, select() modifies timeout to reflect the amount of time not slept; most other implementations do not do this. (POSIX.1-2001 per‐ mits either behavior.) This causes problems both when Linux code which reads timeout is ported to other operating systems, and when code is ported to Linux that reuses a struct timeval for multiple select()s in a loop without reinitializing it. Consider timeout to be undefined after select() returns. The existing select loop seems to rely on the fact that &tv is updated as described here. }}} Same for `man 2 poll`. E.g. `man 2 select` on FreeBSD 11 says explicitly: {{{ BUGS Version 2 of the Single UNIX Specification (``SUSv2'') allows systems to modify the original timeout in place. Thus, it is unwise to assume that the timeout value will be unmodified by the select() system call. FreeBSD does not modify the return value, which can cause problems for applications ported from other systems. }}} I have tested this now on FreeBSD, and indeed it doesn't work as expected. With GHC 7.10.2: {{{ import System.IO main = hWaitForInput stdin (1 * 1000) }}} `ghc --make test.hs -rtsopts` {{{ [root@ ~]# time ./test real 0m1.386s user 0m0.004s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.01 real 0m1.386s user 0m0.001s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.001 real 0m1.678s user 0m0.003s sys 0m0.002s [root@ ~]# time ./test +RTS -V0.0001 real 0m11.311s user 0m0.032s sys 0m0.139s }}} See how when we increase the timer signal, the sleep suddenly takes 10x longer than it should. That's because it triggers the case where EINTR is received in https://github.com/ghc/ghc/blob/f46369b8a1bf90a3bdc30f2b566c3a7e03672518%5E/libraries/base/cbits/inputReady.c#L48, letting us use the same unmodified 1-second `struct timeval *timeout` again and again. This demo of the bug works for GHC 7.10 and 8.0.1; in 8.0.2 `hWaitForInput` is broken (https://ghc.haskell.org/trac/ghc/ticket/12912#comment:4) so the demo doesn't work there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:25:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:25:02 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.ea2032a1bbf78982f653bab7ce321d4f@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Using `git grep "select("`, I've found uses of `select()` in: * `libraries/base/cbits/inputReady.c` * `rts/posix/Select.c` The first one I already knew about, the other one has 3 uses. 2 of those are with a 0-timeout (in which case there is no problem), and the one in `awaitEvent()` aims to block as long as possible, so that's not a problem either. The only occurrence of `poll(` is in the new code that carries the problem I mentioned (https://ghc.haskell.org/trac/ghc/ticket/12912#comment:4); this probably has to be fixed (both to not crash and to handle the fact that `poll()` may not update the timeout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:42:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:42:19 -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.31a4ec5e911cc7d5aa017da60455c43d@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 slyfox): '''quick-cross.mk''' explicitly enables '''llvm''' backend: {{{ GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm }}} You might want to disable that as you are using '''--enable- unregisterised'''. I think '''GHC''' should ignore '''-fllvm''' (with a warning) if compiler targets unregisterised codegen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:53:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:53:25 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. In-Reply-To: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> References: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> Message-ID: <062.0f6fc3938edc640616fb63d34324ebe7@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: ruperthorlick Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T8501a Blocked By: | Blocking: Related Tickets: #3968 | Differential Rev(s): Phab:D3271 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5856c564dff79a5c2b6a92b1c6c350798b538da3/ghc" 5856c564/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5856c564dff79a5c2b6a92b1c6c350798b538da3" Fixed error messages for RecursiveDo (#8501) Changes in a few different places to catch several different types of error related to RecursiveDo Signed-off-by: Rupert Horlick Test Plan: Three test cases, with further tests in comments Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3271 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:53:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:53:25 -0000 Subject: [GHC] #13454: Operators not allowed as fields in Record Pattern Synonyms In-Reply-To: <051.27085269b67e022e580ad0a1da270800@haskell.org> References: <051.27085269b67e022e580ad0a1da270800@haskell.org> Message-ID: <066.6aea8a2e4f73cbc42ddd54c202a77e84@haskell.org> #13454: Operators not allowed as fields in Record Pattern Synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3379 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"154d224ade3d9f22b0e22fc8be8f3907f1ad51d2/ghc" 154d224a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="154d224ade3d9f22b0e22fc8be8f3907f1ad51d2" Allow operators as record pattern synonym fields Fixes #13454 Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3379 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:53:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:53:25 -0000 Subject: [GHC] #13489: openTempFile fails when the template parameter contain a path separator In-Reply-To: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> References: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> Message-ID: <062.2751d870795565ece542805dfd4b356f@haskell.org> #13489: openTempFile fails when the template parameter contain a path separator -------------------------------------+------------------------------------- Reporter: harendra | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b04ded8fca8ee8b0cd9c7c055bc5dc61ef2be1fe/ghc" b04ded8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b04ded8fca8ee8b0cd9c7c055bc5dc61ef2be1fe" base: Check for path separators chars in openTempFile' template string This fixes #13489. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 20:53:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:53:47 -0000 Subject: [GHC] #13454: Operators not allowed as fields in Record Pattern Synonyms In-Reply-To: <051.27085269b67e022e580ad0a1da270800@haskell.org> References: <051.27085269b67e022e580ad0a1da270800@haskell.org> Message-ID: <066.833c026966db4301e9e5c8563bd01b9e@haskell.org> #13454: Operators not allowed as fields in Record Pattern Synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3379 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 Mar 29 20:54:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:54:17 -0000 Subject: [GHC] #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. In-Reply-To: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> References: <047.d2feb1b8bba3b3b1bbfeebc99fe25059@haskell.org> Message-ID: <062.fff8d1a390ae1a335568fcd09de1b4b9@haskell.org> #8501: Improve error message when using rec/mdo keyword without RecursiveDo extention. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: ruperthorlick Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 (Parser) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T8501a Blocked By: | Blocking: Related Tickets: #3968 | Differential Rev(s): Phab:D3271 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 Mar 29 20:54:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 20:54:36 -0000 Subject: [GHC] #13489: openTempFile fails when the template parameter contain a path separator In-Reply-To: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> References: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> Message-ID: <062.06deb5b638646e6f1077a8be36a98b7c@haskell.org> #13489: openTempFile fails when the template parameter contain a path separator -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 23:03:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 23:03:27 -0000 Subject: [GHC] #13491: UNIQUE_BITS is not crosscompiler-friendly In-Reply-To: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> References: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> Message-ID: <060.6188376559e5f4608b887e1de4063dd1@haskell.org> #13491: UNIQUE_BITS is not crosscompiler-friendly -------------------------------------+------------------------------------- Reporter: slyfox | 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): Phab:D3397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"01b062ec3fa138b92124ce7ca4deca0ddcb474ea/ghc" 01b062ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01b062ec3fa138b92124ce7ca4deca0ddcb474ea" unique: fix UNIQUE_BITS crosscompilation (Trac #13491) The #13491 manifests best when we try to crosscompile from 32-bit (i386-linux) to 64-bit (powerpc64-linux) system: ./configure --target=powerpc64-unknown-linux-gnu The build fails at assembly time: "inplace/bin/ghc-stage1" ... -c rts/StgStartup.cmm /tmp/ghc19687_0/ghc_4.s: Assembler messages: /tmp/ghc19687_0/ghc_4.s:11:0: error: Error: unknown pseudo-op: `.l' | 11 | .L<\x00>4: | ^ That happens because UNIQUE_BITS is defined in terms of WORD_SIZE_IN_BITS macro: #define UNIQUE_BITS (WORD_SIZE_IN_BITS - 8) WORD_SIZE_IN_BITS is 64 bits (equals to target value) while ghc-stage1 is still running on i386-linux The fix is to stop relying on target macros and use host's 'sizeof (HsInt)' and 'finiteBitSize' way to determine unique layout. Signed-off-by: Sergei Trofimovich Test Plan: build i386-to-powerpc64 crosscompiler Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D3397 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 23:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 23:42:58 -0000 Subject: [GHC] #13491: UNIQUE_BITS is not crosscompiler-friendly In-Reply-To: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> References: <045.019fc66dd09571c3af1dd69f494ef2be@haskell.org> Message-ID: <060.9a487d2e3359f53be09ae55b7a8e6c2b@haskell.org> #13491: UNIQUE_BITS is not crosscompiler-friendly -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` as 3389bb3454f973f76ed6aac2f0831e1dbfb7ea07. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 23:44:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 23:44:18 -0000 Subject: [GHC] #13433: Segmentation faults in profiled way In-Reply-To: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> References: <046.24f1c8db2e6e408fad288a9d693dbea5@haskell.org> Message-ID: <061.5859222961ea790d7bb082d23e316f9d@haskell.org> #13433: Segmentation faults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as bdcb0c8572044f2a93981910bb4ed6e9d65160c0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 23:45:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 23:45:46 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.5663cdce708fb3fb912380fbc39ed74d@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Reverted reverting commits on `ghc-8.2` and merged fix to #13433. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 23:46:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 23:46:12 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.79d9e46961308cfc3541e33a1f26bcd4@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:2 merged to `ghc-8.2` as 8a857f50c5922365c71d07cb403f5c46a75b204e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 29 23:48:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Mar 2017 23:48:41 -0000 Subject: [GHC] #13489: openTempFile fails when the template parameter contain a path separator In-Reply-To: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> References: <047.e1510426e201713c0873ce74f9dfed4b@haskell.org> Message-ID: <062.5bf881e2c5b40dcb80c9bd34149200e8@haskell.org> #13489: openTempFile fails when the template parameter contain a path separator -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 02a9c6a3442c1b560176ec01789c0042c655c0eb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 00:26:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 00:26:19 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.eb847013e8d0f10f5639fdcc976b6c8f@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I have a first patch for this ready (based on 8.0.1) at https://github.com/ghc/ghc/compare/ghc-8.0.1-release...nh2:fix-12695 -select-time-loop-ghc-8.0.1 Still need to forward-port it to 8.0.2 / HEAD after fixing the `poll()` failure there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 00:38:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 00:38:25 -0000 Subject: [GHC] #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match In-Reply-To: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> References: <047.c734cadd004dddbfb83d087e1ec12353@haskell.org> Message-ID: <062.e94928e9e2cc993884f392d75e7c3210@haskell.org> #13441: Type inference failure in bidirectional pattern synonym and GADT pattern match -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged as 765219d949abc4afd4d6eb2c13c2dfb35a392249. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 00:38:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 00:38:56 -0000 Subject: [GHC] #13410: GHC HEAD regression: Template variable unbound in rewrite rule In-Reply-To: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> References: <050.1a5aa500c01039fd20c21213a55e4b34@haskell.org> Message-ID: <065.e884b30237e7807da2a491cf9fe8e458@haskell.org> #13410: GHC HEAD regression: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: JoinPoints, | SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T13410 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 7087abfe2ba944d6609eee399c5ad2ca44cd388c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 00:40:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 00:40:01 -0000 Subject: [GHC] #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled In-Reply-To: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> References: <050.487293044f282f83b0b870b20c1e30e5@haskell.org> Message-ID: <065.928546c0f29a554eb74d054c3a78ccd5@haskell.org> #13446: Deferred type error sneaks in with -fno-defer-type-errors enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: GHC accepts | Test Case: invalid program | typecheck/should_fail/T13446 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged to `ghc-8.2` c9935f1578369a8aa8243081873b706f7ff1b336. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 00:40:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 00:40:28 -0000 Subject: [GHC] #13494: ASSERT failed in compiler/typecheck/TcErrors.hs In-Reply-To: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> References: <046.09df79e762fc0f321c1406248afd06f9@haskell.org> Message-ID: <061.390af9d3d87a9f5176cb689fa9dea890@haskell.org> #13494: ASSERT failed in compiler/typecheck/TcErrors.hs -------------------------------------+------------------------------------- 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Merged to `ghc-8.2` merged to 95ca115d22ce3dc7f9ad53d8d8a74175121fdda8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 00:40:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 00:40:53 -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.6359eba1c4290737949f89a009f4b5c3@haskell.org> #13458: Panic with unsafeCoerce and -dcore-lint -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: 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: merge => closed * resolution: => fixed Comment: Merged comment:12 to `ghc-8.2` as 662c64226e302009175abfa7ed196ac905990486. I'll look into the warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 03:18:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 03:18:10 -0000 Subject: [GHC] #13498: More storable instances? Message-ID: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> #13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: Storable, | Operating System: Unknown/Multiple Foreign, Ptr | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is it intentional that we don't have {{{Storable}}} instances for ADTs like {{{Maybe}}} and {{{Either}}}, nor for things like {{{(,)}}}? This approach seems to work: https://gist.github.com/wyager/8443c3f5a9fc9b52dc28346bafdf409f Basically what the C compiler would do for a {{{union}}} type with a tag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 06:42:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 06:42:23 -0000 Subject: [GHC] #13498: More storable instances? In-Reply-To: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> References: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> Message-ID: <060.94d883622a1f973121d52b6c61a73737@haskell.org> #13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Storable, | Foreign, Ptr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): The reasoning why sum types have no `Storable` instance by default is that the encoding would be quite arbitrary. In your example: Why are the tags 8 bit wide, and why are the tag values `0` and `1`? Do we need a tag at all? For e.g. `Maybe (Ptr a)` a more common encoding is to have no tag at all and represent `Nothing` as a null pointer. For product types things are less arbitrary, but even then there is the issue of alignment. If you need serialization, you can use `Data.Binary`. I think we should close this ticket as `wontfix`, because the lack of these instances was a very deliberate decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 08:34:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 08:34:27 -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.ee17778be24fd16c6c6afeee3812ad93@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 jms): You are both right. I have removed the -fllvm options, made and the result seems to work as well as 7.8.3 anyway. Thank you very much for your quick response and please close this ticket. Jon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 09:23:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 09:23:25 -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.1bb253dcfdaebeff674740764ccf7cb9@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 pjljvdlaar): Issue still present in GHC 8.0.2 on windows. Tested with LTS 8.5 - https://www.stackage.org/lts-8.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 09:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 09:31:09 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole Message-ID: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux StaticPointers, hole, skolem, | panic | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this minimal example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE StaticPointers #-} import Data.Typeable (Typeable) import GHC.StaticPtr (StaticPtr) f :: Typeable a => StaticPtr (a -> a) f = static (\a -> _) main :: IO () main = return () }}} I get this output: {{{ Bug.hs:8:19: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: a_aJo[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Unlike similar reported bugs, this happens on both 8.0.1 and 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 09:38:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 09:38:34 -0000 Subject: [GHC] #13500: GHCi preprocesses every source file on :reload Message-ID: <047.c03db918e06d38fdf043e2b0357dbc8e@haskell.org> #13500: GHCi preprocesses every source file on :reload -------------------------------------+------------------------------------- Reporter: simonmar | 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): Phab:D3398 | Wiki Page: -------------------------------------+------------------------------------- This is a regression in 8.0 caused by 5d48e67fac952f7188fc9ebcfbf6e3ccb9b75705 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 10:16:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 10:16:34 -0000 Subject: [GHC] #13501: TH segmentation fault on Linux when calling function from another package Message-ID: <044.d86696700d9151a875e7fe29f91a002c@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 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The bug was hit when using Buck (buckbuild.com) to build. I had two packages, A containing a single module with a TH function of type `TH.Q [TH.Dec]` and module B importing A it and calling that function at top-level. I've attached a tarball that reproduces the problem. I've verified that the problem occurs with 7.10.3, 8.0.2 and a semi-recent GHC HEAD from @bitonic. The issue doesn't occur on macOS and does not occur when the modules are in a single package or if the package is compiled as a shared library. The problem also does not occur when using stack, so this is likely related to how buck creates packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 10:17:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 10:17:26 -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.62ac8c75e2af926a87282b73309863f3@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: 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 jmaki): * Attachment "repro.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 10:19:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 10:19:25 -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.eb33a0af688fadfd90239492abe89fad@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: 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: | -------------------------------------+------------------------------------- Description changed by jmaki: Old description: > The bug was hit when using Buck (buckbuild.com) to build. I had two > packages, A containing a > single module with a TH function of type `TH.Q [TH.Dec]` and module B > importing A it and calling that function at top-level. I've attached a > tarball that reproduces the problem. > > I've verified that the problem occurs with 7.10.3, 8.0.2 and a semi- > recent GHC HEAD from @bitonic. > The issue doesn't occur on macOS and does not occur when the modules are > in a single package or if the package is compiled as a shared library. > The problem also does not occur when using stack, so this is likely > related to how buck creates packages. New description: The bug was hit when using Buck (buckbuild.com) to build. I had two packages, A containing a single module with a TH function of type `TH.Q [TH.Dec]` and module B importing A it and calling that function at top-level. I've attached a tarball that reproduces the problem using just 'ghc', 'ghc-pkg' and 'ar'. I've verified that the problem occurs with 7.10.3, 8.0.2 and a semi-recent GHC HEAD from @bitonic. The issue doesn't occur on macOS and does not occur when the modules are in a single package or if the package is compiled as a shared library. The problem also does not occur when using stack, so this is likely related to how buck creates packages. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 10:26:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 10:26:13 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.ffe933a39bf2996b90696464c0a38dfe@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, hole, skolem, panic Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Also happens on HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 10:31:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 10:31:15 -0000 Subject: [GHC] #13499: "Panic: no skolem info" with StaticPointers and typed hole In-Reply-To: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> References: <044.5000664cb44543b0892ceec125b4ed7e@haskell.org> Message-ID: <059.df7413e2d4cbc5ace6f6b5af3d7d9263@haskell.org> #13499: "Panic: no skolem info" with StaticPointers and typed hole -------------------------------------+------------------------------------- Reporter: Otini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers, hole, skolem, panic 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: | -------------------------------------+------------------------------------- Old description: > When compiling this minimal example: > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE StaticPointers #-} > > import Data.Typeable (Typeable) > import GHC.StaticPtr (StaticPtr) > > f :: Typeable a => StaticPtr (a -> a) > f = static (\a -> _) > > main :: IO () > main = return () > }}} > > I get this output: > > {{{ > Bug.hs:8:19: error:ghc: panic! (the 'impossible' happened) > (GHC version 8.0.1 for x86_64-unknown-linux): > No skolem info: a_aJo[sk] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Unlike similar reported bugs, this happens on both 8.0.1 and 8.0.2. New description: When compiling this minimal example: {{{#!hs {-# LANGUAGE StaticPointers #-} import Data.Typeable (Typeable) import GHC.StaticPtr (StaticPtr) f :: Typeable a => StaticPtr (a -> a) f = static (\a -> _) main :: IO () main = return () }}} I get this output: {{{ Bug.hs:8:19: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: a_aJo[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Unlike similar reported bugs, this happens on both 8.0.1 and 8.0.2. ''Edit:'' no need to activate GADTs. -- Comment (by Otini): Edit: no need to activate GADTs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 12:26:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 12:26:37 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.7d2ce0c7ea7996ed4565da28fd883d32@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: lowest | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) Comment: There are lots of cases where this transformation would be very beneficial. I am interested in reviving it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 13:07:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 13:07:56 -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.8209ef03e5168540ba8408f91073cb1f@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the repro! There is definitely something fishy here. GDB says, {{{ Thread 1 received signal SIGSEGV, Segmentation fault. 0x00007f631235ed30 in base_GHCziBase_return_info () from /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/bin/../base-4.10.0.0/libHSbase-4.10.0.0-ghc8.3.20170329.so (rr) bt #0 0x00007f631235ed30 in base_GHCziBase_return_info () from /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/bin/../base-4.10.0.0/libHSbase-4.10.0.0-ghc8.3.20170329.so #1 0x0000000000000000 in ?? () (rr) }}} passing `+RTS -Dl` we get the following forboding warnings, {{{ ... Rel entry 4 is raw( 0x54 0x160000000b (nil)) lookupSymbol: looking up stg_ap_p_info lookupSymbol: value of stg_ap_p_info is 0x7f63112740c8 `stg_ap_p_info' resolves to 0x7f63112740c8 Reloc: P = 0x401311ec S = 0x7f63112740c8 A = (nil) Rel entry 5 is raw( 0x5c 0x170000000b 0x1) lookupSymbol: looking up ghczmprim_GHCziTypes_ZMZN_closure lookupSymbol: symbol not found `ghczmprim_GHCziTypes_ZMZN_closure' resolves to 0x7f6311b41d50 Reloc: P = 0x401311f4 S = 0x7f6311b41d50 A = 0x1 Rel entry 6 is raw( 0x65 0x1800000002 0xfffffffffffffffc) lookupSymbol: looking up base_GHCziBase_return_info lookupSymbol: symbol not found `base_GHCziBase_return_info' resolves to 0x7f631235ed10 Reloc: P = 0x401311fd S = 0x7f631235ed10 A = 0xfffffffffffffffc relocations for section 3 using symtab 11 Rel entry 0 is raw( (nil) 0xe00000001 (nil)) lookupSymbol: looking up ghczmprim_GHCziTypes_TrNameS_con_info lookupSymbol: symbol not found `ghczmprim_GHCziTypes_TrNameS_con_info' resolves to 0x7f63118655c0 Reloc: P = 0x40131208 S = 0x7f63118655c0 A = (nil) ... }}} Looking at the `libHSbase` archive, we see, {{{ $ objdump -x /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/base-4.10.0.0/libHSbase-4.10.0.0.a | less ... SYMBOL TABLE: ... 0000000000000000 *UND* 0000000000000000 base_GHCziBase_return_info }}} Very interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 13:10:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 13:10:28 -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.e223990a1aa1079891d9a228522850cc@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In contrast, the monolithic object file contains the symbol, {{{ $ objdump -x /opt/exp/ghc/roots/master/lib/ghc-8.3.20170329/base-4.10.0.0/HSbase-4.10.0.0.o | less ... SYMBOL TABLE: ... 00000000001b1150 g O .text 0000000000000045 base_GHCziBase_return_info }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 13:27:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 13:27:34 -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.6eafdf48fa1db10de7aa87090505d712@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmmm, looking back at `GHC/Base.o`, {{{ $ objdump -x /opt/exp/ghc/ghc-master/libraries/base/dist- install/build/GHC/Base.o | less ... SYMBOL TABLE: ... 0000000000000050 l .text.base_GHCziBase_zgzg_info 0000000000000000 c5Mf_info 0000000000000000 l d .data.base_GHCziBase_return_closure 0000000000000000 .data.base_GHCziBase_return_closure 0000000000000000 l d .text.base_GHCziBase_return_info 0000000000000000 .text.base_GHCziBase_return_info 0000000000000050 l .text.base_GHCziBase_return_info 0000000000000000 c5Mx_info 0000000000000000 l d .data.base_GHCziBase_fail_closure 0000000000000000 .data.base_GHCziBase_fail_closure 0000000000000000 l d .text.base_GHCziBase_fail_info 0000000000000000 .text.base_GHCziBase_fail_info ... 0000000000000018 g O .text.base_GHCziBase_zgzg_info 0000000000000045 base_GHCziBase_zgzg_info 0000000000000000 g O .data.base_GHCziBase_return_closure 0000000000000000 base_GHCziBase_return_closure 0000000000000018 g O .text.base_GHCziBase_return_info 0000000000000045 base_GHCziBase_return_info 0000000000000000 g O .data.base_GHCziBase_fail_closure 0000000000000000 base_GHCziBase_fail_closure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 13:30:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 13:30:46 -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.32eacf58b42f28aaca799563bea6c17f@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One interesting observation is that there are two modules named `Base.o` that get placed in the archive file, {{{ $ ar t dist-install/build/libHSbase-4.10.0.0.a | grep Base Base.o Base.o }}} One of these is `GHC.Base` and the other is `Control.Exception.Base`. Given that `ar --print-armap` reports `base_GHCziBase_return_info` as defined I wonder whether the RTS linker fails to find the symbol due to this repeated object name. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 14:05:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 14:05:48 -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.d16a162a10ace88ba0ec2afec3b59b84@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Regarding comment:5: I suspect not given that this is a dynamic GHC; in fact, I believe GHC shouldn't actually load **any** objects for `base` since it is one of the packages in `Linker.partOfGHCi`. I have confirmed that the symbol is present in the `libHSbase` shared object. Nevertheless, it might be good to circle back and look into the archive oddness seen in comment:2 after nailing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 14:47:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 14:47:47 -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.53211592d5da12a594f67f5929520840@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So the symbols in question are indeed being resolved by the dynamic linker (using the "main program" handle). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 14:59:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 14:59:13 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.462cbc1ba1f8ff6b5dc3c8941eb1422b@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: lowest | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Good! Can you give specifics about "lots of cases"? It is good for optimisations to be informed by concrete use-cases. See [https://www.microsoft.com/en-us/research/publication/compilation- transformation-non-strict-functional-languages/ Andre Sansos's thesis] which has a whole chapter. Also [http://ojs.statsbiblioteket.dk/index.php/brics/article/view/18785 Danvy's lambda-dropping paper] Keep me posted! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 15:00:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 15:00:58 -0000 Subject: [GHC] #13502: Static argument transformation should also run after specialisation Message-ID: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> #13502: Static argument transformation should also run after specialisation -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- Consider the following program where we eventually want `thepayload` to simplify to the same code as `direct`. {{{#!hs {-# LANGUAGE ExistentialQuantification, RankNTypes, DeriveFunctor #-} module Foo where newtype Q a b t = Q { getQ :: forall f . Applicative f => (a -> f b) -> f t } deriving Functor instance Applicative (Q a b) where pure a = Q (\_ -> pure a) (Q ab) <*> (Q a) = (Q (\v -> ab v <*> a v)) singleQ :: a -> Q a b b singleQ a = Q (\f -> f a) data L a = Nil | L a (L a) deriving Show traverseList :: Applicative f => (a -> f b) -> L a -> f (L b) traverseList f Nil = pure Nil traverseList f (L a la) = L <$> f a <*> traverseList f la newtype Identity a = Identity { runIdentity :: a } deriving (Functor, Show) instance Applicative Identity where pure = Identity (Identity f) <*> (Identity x) = Identity (f x) thepayload :: L String -> L String thepayload l = runIdentity $ (getQ $ (traverseList singleQ l)) Identity direct :: L String -> L String direct Nil = Nil direct (L a b) = L a b }}} With `ghc-8.0.2` and `-fstatic-argument-transformation`, the specialiser will specialise the call to `traverseList` and leave us with a definition like, {{{#!hs rec (20) $ssat_worker= λ sg sc l → case l of Nil→ pure sc Nil L a la → <*> sc (fmap ($p1Applicative sc) (L a)) ($ssat_worker sg sc la) (4) thepayload = λl→ $ssat_worker $fApplicativeIdentity l }}} `$ssat_worked` is recursive in `l` but not in the other two arguments so we can also apply SAT here. Notice that `$ssat_worker` is called with a statically known dictionary in `thepayload` and so if we can inline `$ssat_worker` we would get the same code as the naive `direct`, as desired. I verified that inserting another SAT pass later in the compilation pipeline does have the desired effect but am not sure where exactly the right place would be or whether it is in general desirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 15:02:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 15:02:56 -0000 Subject: [GHC] #13502: Static argument transformation should also run after specialisation In-Reply-To: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> References: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> Message-ID: <064.d7800002438f6d3ca02c08052d717a18@haskell.org> #13502: Static argument transformation should also run after specialisation -------------------------------------+------------------------------------- Reporter: mpickering | 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): See #9374 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 15:10:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 15:10:04 -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.4dad4dd6ff70a7e49b517802553fd431@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 ezyang): We have also noticed that regex-posix is buggy on Windows, but I'm pretty sure this is a regex-posix/underlying library problem than a GHC problem. See also https://github.com/haskell/cabal/issues/4336 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 16:01:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 16:01:38 -0000 Subject: [GHC] #13502: Static argument transformation should also run after specialisation In-Reply-To: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> References: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> Message-ID: <064.ebf9fc2059122f61d92d3a1983d15220@haskell.org> #13502: Static argument transformation should also run after specialisation -------------------------------------+------------------------------------- Reporter: mpickering | 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 mpickering): Similar desires for a late SAT pass are in #888 and #9374 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 16:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 16:04:50 -0000 Subject: [GHC] #13502: Static argument transformation should also run after specialisation In-Reply-To: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> References: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> Message-ID: <064.0d6c054ad50183c853ddcce2dc1ebbc7@haskell.org> #13502: Static argument transformation should also run after specialisation -------------------------------------+------------------------------------- Reporter: mpickering | 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 mpickering: Old description: > Consider the following program where we eventually want `thepayload` to > simplify to the same code as `direct`. > > {{{#!hs > {-# LANGUAGE ExistentialQuantification, RankNTypes, DeriveFunctor #-} > module Foo where > > newtype Q a b t = Q { getQ :: forall f . Applicative f => (a -> f b) -> f > t } > deriving Functor > > instance Applicative (Q a b) where > pure a = Q (\_ -> pure a) > (Q ab) <*> (Q a) = (Q (\v -> ab v <*> a v)) > > singleQ :: a -> Q a b b > singleQ a = Q (\f -> f a) > > data L a = Nil | L a (L a) deriving Show > > traverseList :: Applicative f => (a -> f b) -> L a -> f (L b) > traverseList f Nil = pure Nil > traverseList f (L a la) = L <$> f a <*> traverseList f la > > newtype Identity a = Identity { runIdentity :: a } deriving (Functor, > Show) > > instance Applicative Identity where > pure = Identity > (Identity f) <*> (Identity x) = Identity (f x) > > thepayload :: L String -> L String > thepayload l = runIdentity $ (getQ $ (traverseList singleQ l)) Identity > > direct :: L String -> L String > direct Nil = Nil > direct (L a b) = L a b > }}} > > With `ghc-8.0.2` and `-fstatic-argument-transformation`, the specialiser > will specialise the call > to `traverseList` and leave us with a definition like, > > {{{#!hs > rec > (20) > $ssat_worker= λ sg sc l → > case l of > Nil→ pure sc Nil > L a la → <*> sc (fmap ($p1Applicative sc) (L a)) ($ssat_worker sg > sc la) > > (4) thepayload = λl→ $ssat_worker $fApplicativeIdentity l > }}} > > `$ssat_worked` is recursive in `l` but not in the other two arguments so > we can also apply SAT here. > > Notice that `$ssat_worker` is called with a statically known dictionary > in `thepayload` and so if we can inline `$ssat_worker` > we would get the same code as the naive `direct`, as desired. > > I verified that inserting another SAT pass later in the compilation > pipeline does have the desired effect but am not sure where exactly the > right place would be or whether it is in general desirable. New description: Consider the following program where we eventually want `thepayload` to simplify to the same code as `direct`. {{{#!hs {-# LANGUAGE ExistentialQuantification, RankNTypes, DeriveFunctor #-} module Foo where newtype Q a b t = Q { getQ :: forall f . Applicative f => (a -> f b) -> f t } deriving Functor instance Applicative (Q a b) where pure a = Q (\_ -> pure a) (Q ab) <*> (Q a) = (Q (\v -> ab v <*> a v)) singleQ :: a -> Q a b b singleQ a = Q (\f -> f a) data L a = Nil | L a (L a) deriving Show traverseList :: Applicative f => (a -> f b) -> L a -> f (L b) traverseList f Nil = pure Nil traverseList f (L a la) = L <$> f a <*> traverseList f la newtype Identity a = Identity { runIdentity :: a } deriving (Functor, Show) instance Applicative Identity where pure = Identity (Identity f) <*> (Identity x) = Identity (f x) thepayload :: L String -> L String thepayload l = runIdentity $ (getQ $ (traverseList singleQ l)) Identity direct :: L String -> L String direct Nil = Nil direct (L a b) = L a (direct b) }}} With `ghc-8.0.2` and `-fstatic-argument-transformation`, the specialiser will specialise the call to `traverseList` and leave us with a definition like, {{{#!hs rec (20) $ssat_worker= λ sg sc l → case l of Nil→ pure sc Nil L a la → <*> sc (fmap ($p1Applicative sc) (L a)) ($ssat_worker sg sc la) (4) thepayload = λl→ $ssat_worker $fApplicativeIdentity l }}} `$ssat_worked` is recursive in `l` but not in the other two arguments so we can also apply SAT here. Notice that `$ssat_worker` is called with a statically known dictionary in `thepayload` and so if we can inline `$ssat_worker` we would get the same code as the naive `direct`, as desired. I verified that inserting another SAT pass later in the compilation pipeline does have the desired effect but am not sure where exactly the right place would be or whether it is in general desirable. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 16:05:47 -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.16efd312c9b1a37495202bcb677af1ed@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: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jmaki): Switching to link-style 'static_pic' in buck fixes the issue. Difference to "repro": {{{ -ghc -no-link -package-name foo -i Foo.hs -Wall -Werror +ghc -fPIC -dynamic -hisuf dyn_hi -no-link -package-name foo -i Foo.hs -Wall -Werror -ghc -no-link -package-name bar -package-db ../foo/pkg -package foo \ +ghc -fPIC -dynamic -no-link -package-name bar -package-db ../foo/pkg -package foo-1.0.0 \ Bar.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:33:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:33:14 -0000 Subject: [GHC] #13498: More storable instances? In-Reply-To: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> References: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> Message-ID: <060.8f8a16edd5cd8b061f8e57e0ebc52475@haskell.org> #13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Storable, | Foreign, Ptr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wyager): > the encoding would be quite arbitrary How is this an argument against adding the encodings? If they function correctly, why does it matter that they aren't "fixed" in some sense? > Why are the tags 8 bit wide, and why are the tag values 0 and 1? Because it makes sense and works. Why, for a {{{Ratio}}}, is the numerator stored before the denominator? Presumably for the same reason. The choice of representation doesn't really matter a whole lot; the point of this feature request isn't to bikeshed over the exact implementation, but to establish if there's some fundamental stumbling block with this approach. > then there is the issue of alignment I *think* my `lcm` trick solves this for sum types. For product types, there are some obvious approaches. > If you need serialization, you can use `Data.Binary`. Besides `Data.Binary` being vastly slower than `Storable`, the primary use case here is `Data.Vector.Storable` and `Data.Array.Storable`. You can't write an `Unbox` instance for `Maybe a`, but you can (as I've done here) write a `Storable` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:35:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:35:17 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.7554b44227895893ab4b5d59ddc1048e@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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:"69f070d8e4d6043937e3405675ac911448bfcb44/ghc" 69f070d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69f070d8e4d6043937e3405675ac911448bfcb44" Deriving for phantom and empty types Make `Functor`, `Foldable`, and `Traversable` take advantage of the case where the type parameter is phantom. In this case, * `fmap _ = coerce` * `foldMap _ _ = mempty` * `traverse _ x = pure (coerce x)` For the sake of consistency and especially simplicity, make other types with no data constructors behave the same: * `fmap _ x = case x of` * `foldMap _ _ = mempty` * `traverse _ x = pure (case x of)` Similarly, for `Generic`, * `to x = case x of` * `from x = case x of` Give all derived methods for types without constructors appropriate arities. For example, ``` compare _ _ = error ... ``` rather than ``` compare = error ... ``` Fixes #13117 and #13328 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: ekmett, RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3374 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:35:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:35:17 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.4f3856a8cf519c026e945811c0d5fbee@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"69f070d8e4d6043937e3405675ac911448bfcb44/ghc" 69f070d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69f070d8e4d6043937e3405675ac911448bfcb44" Deriving for phantom and empty types Make `Functor`, `Foldable`, and `Traversable` take advantage of the case where the type parameter is phantom. In this case, * `fmap _ = coerce` * `foldMap _ _ = mempty` * `traverse _ x = pure (coerce x)` For the sake of consistency and especially simplicity, make other types with no data constructors behave the same: * `fmap _ x = case x of` * `foldMap _ _ = mempty` * `traverse _ x = pure (case x of)` Similarly, for `Generic`, * `to x = case x of` * `from x = case x of` Give all derived methods for types without constructors appropriate arities. For example, ``` compare _ _ = error ... ``` rather than ``` compare = error ... ``` Fixes #13117 and #13328 Reviewers: austin, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: ekmett, RyanGlScott, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3374 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:38:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:38:26 -0000 Subject: [GHC] #13328: Foldable, Functor, and Traversable deriving handle phantom types badly In-Reply-To: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> References: <045.d70b9396261fbd5ebd0ff9d08e3d420d@haskell.org> Message-ID: <060.e1d297804bd78e59c64800bc6fb01143@haskell.org> #13328: Foldable, Functor, and Traversable deriving handle phantom types badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:41:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:41:11 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.3e7b3f24ed51c7076de9b28791ded99a@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): There are still several types that have not reached what I'd consider a good final status, but as Ryan indicates, we need more discussion to get that done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:43:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:43:05 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.9f6064d58644200ae40e49c60c23835f@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7401, #10577 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #7401 => #7401, #10577 Comment: Indeed. However, this ticket specifically concerns `Functor`, right? It might be best to tackle the other classes in #10577. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:45:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:45:29 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.21a750da00e38d19ec6ee13b0834cb86@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7401, #10577 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: Replying to [comment:7 RyanGlScott]: > Indeed. However, this ticket specifically concerns `Functor`, right? It might be best to tackle the other classes in #10577. Indeed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:48:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:48:40 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.ad2105c48ddbbcadbcb41258d6a0a6ce@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #13117, #7401 Comment: This is fixed for `Functor`, `Foldable`, `Traversable`, `Generic`, and `Generic1`. I believe some `Data` methods already do the right thing here, but I don't know if they all do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:49:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:49:51 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.5570d6d37ff6777330222bb44f942af3@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 17:50:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:50:18 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.1e8992893a71c85fc6a6bfbb9e0b2d8c@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | 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 Mar 30 17:54:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 17:54:44 -0000 Subject: [GHC] #13503: "ghc: panic" when trying to build purescript with profiling Message-ID: <047.a338051f2c40c0d10721824cdeeee3de@haskell.org> #13503: "ghc: panic" when trying to build purescript with profiling -------------------------------------+------------------------------------- Reporter: rintcius | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Other | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- i got the following panic when trying to build purescript with profiling (the plain build works ok) {{{ $ stack build --executable-profiling --library-profiling --ghc-options ="-fprof-auto -rtsopts" purescript-0.11.1: build Preprocessing library purescript-0.11.1... [ 23 of 145] Compiling Language.PureScript.Constants ( src/Language/PureScript/Constants.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/Language/PureScript/Constants.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): kindPrimRep.go rep_sfuE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package purescript-0.11.1 using: /Users/rintciusblok/.stack/setup-exe-cache/x86_64-osx/setup-Simple- Cabal-1.24.2.0-ghc-8.0.2 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.24.2.0 build lib:purescript exe:purs --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} If this report needs to be reduced, I'd be happy to do that, but I would need some guidance in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 18:03:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 18:03:34 -0000 Subject: [GHC] #13503: "ghc: panic" when trying to build purescript with profiling In-Reply-To: <047.a338051f2c40c0d10721824cdeeee3de@haskell.org> References: <047.a338051f2c40c0d10721824cdeeee3de@haskell.org> Message-ID: <062.3d1d3568989333ee29417987b1c9f544@haskell.org> #13503: "ghc: panic" when trying to build purescript with profiling -------------------------------------+------------------------------------- Reporter: rintcius | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): My guess is that this will be fixed in HEAD, as the whole mechanism around `kindPrimRep` has been rewritten. Can anyone verify? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 18:28:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 18:28:45 -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.827dfe883af462516a5cdcbf0755e4ac@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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: goldfire => (none) * priority: normal => highest * status: closed => new * resolution: fixed => Comment: This cure is worse than the disease was--Core Lint now seems to warn about *every* unsafe coercion; and the volume of warnings produced during the build of ghc somehow broke https://perf.haskell.org/ghc/. Can we revert this for now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 18:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 18:36:19 -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.e4af7ca67775b1746340ba80f10481d4@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 simonpj): Richard, it's your commit. Might you look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 19:40:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 19:40:41 -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.9aef990541308f8c48d3fa002589f143@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 rwbarton): * differential: => Phab:D3399, Phab:D3400 Comment: Replying to [comment:14 simonpj]: > PS: you may then be able to get rid of the call to `coreBindsSize` in `SimplCore`. If so, that would be good: faster compilation! Worth trying... it might I suppose show up another leak currently patched by `coreBindsSize`. This line of investigation already paid some dividends. It turns out that that `coreBindsSize` is what takes care of forcing the demand and strictness info produced by the demand analysis pass. Otherwise, the demand analysis pass leaks basically a copy of the whole Core program. But ''late'' demand analysis runs after all simplifier passes, and there is no more `coreBindsSize` or `seqBinds` after that. Presumably code generation uses some of the information added by this pass, but it doesn't force all of it; and the result is that we hang on to two copies of the Core program during code generation. And code generation is the phase that uses the most memory anyways, so this makes a big difference in peak memory usage. As a crude measure I added a `seqBinds` to demand analysis (Phab:D3400) and it reduced peak memory usage on DynFlags by around 30% and even made the running time a few percent faster (I think because of reduced GC work). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 20:43:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 20:43:52 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.fc87e5fe711a5c37f645bf9bbb62b6b9@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Actually before that, I should probably fix the Windows version too (for the case that the FD is not a socket). https://github.com/ghc/ghc/blob/f46369b8a1bf90a3bdc30f2b566c3a7e03672518%5E/libraries/base/cbits/inputReady.c#L80 {{{ while (1) // keep trying until we find a real key event { rc = WaitForSingleObject( hFile, msecs ); ... }}} Looking at this, it is not clear to me how this should ever have worked (how this should have provided the semantics that after the maximum given time, `hWaitForInput` returns), as this would simply loop forever if interrupted by a signal. I just wrote the above sentence and then realised that the exact same was true for any non-Linux select, so I got suspicious why it worked at all so far on my FreeBSD VM before my fix, because any EINTR should just return out of `fdReady()` just to have it restarted with the original full duration. [1 hour later] I now know what's going on. It only worked on non-Linux because of the idle GC! Looking at `truss`, it keeps calling `select()` until suddenly a `ktimer_settime` appears, and a quick `printf` reveals that it's issued by `stopTicker()` called by `stopTimer()` caused by idle GC. When the idle GC is set to a value larger than the `msecs` passed to `fdReady()`, e.g. when `msecs = 500` and `+RTS -I1`, then `fdReady` will never return and the program will be stuck. BSD and Mac OS users (and probably Windows) were just lucky so far that idle GC defaults to 0.3 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 21:11:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 21:11:10 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.56fb33d2b657cb50a1ddb197ef1a6a82@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Uh, some things are still puzzling me here. If I run with `+RTS -I0.3`, the infinite loop does not occur on FreeBSD, even though 0.3 is supposed to be the default, so I'm not sure why giving no `+RTS` and `+RTS -I0.3` have different behaviour. Also, passing `+RTS -I0` does not enforce the bug, surprises me. Note all these observations are for the non`-threaded` runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 21:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 21:29:54 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.1c407d8cbd4d4fe71abf70418eb6f1d0@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I don't understand how changing `-I...` can even do anything given that I don't use the threaded runtime (confirmed by `+RTS --info`), as `-I` is supposed to be only available for the threaded runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 22:26:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 22:26:24 -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.0c3eae2dc61b499bfb22da4b2dc69f99@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 DimaSamoz): Adding {{{ #!haskell c = evaluate ('a' :-: 'b') }}} to the above example, then loading it and querying the value of `c` also triggers the panic. This wouldn't be surprising if GHCi called `evaluate` upon let bindings, but surely that's not the case? I encountered this error when trying to test my library using the `should- not-typecheck` package (https://hackage.haskell.org/package/should-not- typecheck), which provides a HSpec assertion `shouldNotTypecheck` that passes only if the argument doesn't compile (hence the need for deferred type errors). I eventually realised that the library doesn't work with custom compiler errors: the function performs a case split on the result of `try (evaluate $ force a)` (for the argument `a`), but terms with custom type errors never got into the `Left (TypeError msg)` case (where the assertion could pass), so the function thought that the argument compiles. This might not be directly related, but I thought I would mention it in case it is! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 23:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 23:19:16 -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.23bf523b3e1d3a9dc9a1776d6ce36222@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 rwbarton): Replying to [comment:14 simonpj]: > PS: you may then be able to get rid of the call to `coreBindsSize` in `SimplCore`. If so, that would be good: faster compilation! Worth trying... it might I suppose show up another leak currently patched by `coreBindsSize`. The input core program size is used to bound the number of simplifier ticks so we can't remove the call to `coreBindsSize` entirely without affecting the behavior of the simplifier. I'm not sure whether we could make do with a more crude estimate of program size. However, `coreBindsSize` currently goes out of its way to force a lot of structure (like `seqBinds` does) that is not needed to compute the Core program size. So an easy intermediate option is to just remove all the extra `seq`s from `coreBindsSize`. This still leaves a lot less work than `coreBindsSize` does currently and forcing the main program body may be useful. I almost have this working but in order to fix another space leak I had to make another similar change of {{{#!hs simplExpr env expr = simplExprC env expr (mkBoringStop expr_out_ty) where expr_out_ty :: OutType expr_out_ty = substTy env (exprType expr) }}} to {{{#!hs simplExpr env expr = do { expr_out_ty <- simplType env (exprType expr) ; simplExprC env expr (mkBoringStop expr_out_ty) } }}} However, this also produces a lot of warnings like {{{ exprType TYPE: ModuleName }}} which seem to be from calling `simplExpr` on a `Type t`. Is it a bug that that happens in the first place? What is the best way to handle this? I get another smal improvement in space and time from this change so I'm hoping this is easy to finish off. Please advise! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 23:28:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 23:28:22 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.94bdb40a18c49c5fcf70530aa5a5ad57@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I found (using [https://hackage.haskell.org/package/base-4.9.1.0/docs/GHC- RTS-Flags.html#v:getRTSFlags getRTSFlags]) that setting `+RTS -I10` will set {{{ idleGCDelayTime = 10000000000 doIdleGC = True }}} even when the threaded RTS is not enabled. I'm not sure if that's a bug, but commit [https://github.com/ghc/ghc/commit/33a84b8c79f 33a84b8c79f] that introduced the idle GC says {{{ The idle GC only happens in the threaded RTS }}} so maybe this is a bug? [https://github.com/ghc/ghc/blob/428e152be6bb0fd3867e41cee82a6d5968a11a26/rts/Timer.c#L66 The line that checks doIdleGC] is clearly outside the `#ifdef THREADED_RTS`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 23:28:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 23:28:47 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.091ee1524171d75ef2bd812d1045f211@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 23:30:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 23:30:10 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.f5a53416a0f159a2a45421442bfe24fb@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): The `stopTimer()` occurring for me (and terminating `fdReady()`) is the one [https://github.com/ghc/ghc/blob/428e152be6bb0fd3867e41cee82a6d5968a11a26/rts/Timer.c#L85 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 30 23:53:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Mar 2017 23:53:58 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.27a532b1d88afaeadd8f6c80d45ea16c@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I have confirmed by printf-debugging that the line {{{ ticks_to_gc = RtsFlags.GcFlags.idleGCDelayTime / RtsFlags.MiscFlags.tickInterval; }}} is used even if the non-threaded runtime is used, and `doIdleGC` is `False`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 00:51:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 00:51:32 -0000 Subject: [GHC] #13504: registerTimeout can wait too little because it uses Doubles for times Message-ID: <042.fd5657ca3041b4f2ee2007bc0c2c4662@haskell.org> #13504: registerTimeout can wait too little because it uses Doubles for times -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 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: -------------------------------------+------------------------------------- [https://github.com/ghc/ghc/blob/380b25ea4754c2aea683538ffdb179f8946219a0/libraries/base/GHC/Event/TimerManager.hs#L218 registerTimeout] uses `getMonotonicTime :: IO Double` and thus goes a roundtrip to `Double` when it is perfectly possible to always work on integers instead (`getMonotonicTime` obtains integers and then converts it). This can result in functions like `timeout` to wait too little, as e.g. `timeout 4` is converted to `3.997420` seconds, which can violate standard expecations of programs that it will wait _at least_ as much as demanded. We should export and use the integer based function [https://github.com/ghc/ghc/blob/380b25ea4754c2aea683538ffdb179f8946219a0/libraries/base/GHC/Event/Clock.hsc#L15 GHC.getMonotonicNSec] that `getMonotonicTime` calls. Not going through Double will also make inspecting e.g. `strace` more obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 00:55:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 00:55:00 -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.30ed0e644912adce238e2f2fa890c365@haskell.org> #13504: registerTimeout can wait too little because it uses Doubles for times -------------------------------------+------------------------------------- Reporter: nh2 | Owner: nh2 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 nh2): * owner: (none) => nh2 * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 01:01:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 01:01:42 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.66386623e7b0a6fe1f6bfce681d81ba9@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Hmm, this seems to happen on purpose: Commit [https://github.com/ghc/ghc/commit/0b79d5cd4687dacf7efd430df7fba9d9a5a5ce32 Another overhaul of the recent_activity / idle GC handling] (#5991) mentions {{{ - we now turn off the timer signal after idleGCDelay even if the idle GC is disabled with +RTS -I0. }}} I personally find that very confusing, using a setting called `idleGCDelay` even when the user explicitly turned that off. Further, doing it this way, there's no way of actually setting what the value of `idleGCDelay` is, because if you use `-I0`, well, then it's the default (0.3 seconds), and if you use `-I` with any other value, then that actually turns idle GC on (as I found above). So there's no way to change away from the default 0.3 seconds when idle GC is set to off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 01:05:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 01:05:34 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.f1fd1e138b77f19631e06432970235b2@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I was wrong when I said: Replying to [comment:1 nh2]: > and the one in `awaitEvent()` aims to block as long as possible, so that's not a problem either. The `select()` occurrence in `awaitEvent()` waits for `sleeping_queue->block_info.target - now` so that also needs to be vetted on whether it has the `&tv` updating problem on non-Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 02:03:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 02:03:30 -0000 Subject: [GHC] #13503: "ghc: panic" when trying to build purescript with profiling In-Reply-To: <047.a338051f2c40c0d10721824cdeeee3de@haskell.org> References: <047.a338051f2c40c0d10721824cdeeee3de@haskell.org> Message-ID: <062.773ab708856a44f730de7d94e5ed0edd@haskell.org> #13503: "ghc: panic" when trying to build purescript with profiling -------------------------------------+------------------------------------- Reporter: rintcius | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I've verified that `purescript-0.11.1` builds without issue on GHC HEAD with profiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 03:18:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 03:18:28 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.e8872a02c72bee4fdfc3c962ace0c604@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | typecheck/should_run/T13435 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): During my levity-polymorphism sweep, I saw that this was newly working. I'm not sure exactly what did it, but the seg-fault is gone, and the program looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 09:01:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 09:01:04 -0000 Subject: [GHC] #13435: Segfaults on levity-polymorphic type class In-Reply-To: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> References: <051.9de90049d3b893c73e0c6d4eefaf7349@haskell.org> Message-ID: <066.5d8e6caa4f0b3d44cb975f8bd07eb8e9@haskell.org> #13435: Segfaults on levity-polymorphic type class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | typecheck/should_run/T13435 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Great! Cheers Richard -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 09:52:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 09:52:24 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.90fbe5d8b51394527e48d62dfc4406b2@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: SpecConstr => SpecConstr, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 09:56:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 09:56:55 -0000 Subject: [GHC] #4945: Another SpecConstr infelicity In-Reply-To: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> References: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> Message-ID: <068.f40299ccb08a9e2d7554b6ee9707a5e3@haskell.org> #4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T4945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 09:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 09:57:32 -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.57eb91361ac492554716e44ab6c40f67@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 09:58:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 09:58:09 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.606bc411606e233d504042934f6206fa@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:01:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:01:21 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.cbd408eb734524aeff5afb4d75e2525b@haskell.org> #5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #8613, #9070, | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining Comment: This ticket is a bit of a mess but someone should test these examples again and make new tickets if they are still a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:36:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:36:56 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.61dc5ed4f7494439efd414bae5e6ca7a@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Resolution: wontfix | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => StaticArgumentTransformation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:40:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:40:35 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.1e16db2d80a1cd02b9236d0bf4a7c4ad@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => StaticArgumentTransformation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:45:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:45:06 -0000 Subject: [GHC] #13502: Static argument transformation should also run after specialisation In-Reply-To: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> References: <049.c5fa2b685c24cd8cc2b027074a2b8de0@haskell.org> Message-ID: <064.350f41437b9fcc87a6e35129bdaed312@haskell.org> #13502: Static argument transformation should also run after specialisation -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => StaticArgumentTransformation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:48:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:48:29 -0000 Subject: [GHC] #888: Implement the static argument transformation In-Reply-To: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> References: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> Message-ID: <061.8041edc49babc92989719e39a12ca020@haskell.org> #888: Implement the static argument transformation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.2 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => StaticArgumentTransformation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:52:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:52:11 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.3840099461ed85864a5eecbfdc2e41c2@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => SpecConstr * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:55:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:55:05 -0000 Subject: [GHC] #13498: More storable instances? In-Reply-To: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> References: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> Message-ID: <060.dd54b5a3999c4ea834d0e606d1e373e2@haskell.org> #13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Storable, | Foreign, Ptr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:2 wyager]: > > the encoding would be quite arbitrary > > How is this an argument against adding the encodings? If they function correctly, why does it matter that they aren't "fixed" in some sense? The general rule of thumb is: The Prelude doesn't make arbitrary choices when there is no obviously "right" way of doing things. Well, there are exceptions, but that's the idea. In our case, there ''are'' various arbitrary choices. Remember that the prime motivation for `Storable` is the FFI, and there are numerous ways used in actual C libraries to encode the equivalent of `Maybe` or `Either`, and none of them is "more correct" than the other. > > Why are the tags 8 bit wide, and why are the tag values 0 and 1? > > Because it makes sense and works. `CChar` or `CInt` or `Word` make sense, too, and depending on the circumstances, they would be even better. That was just an example for the arbitrary decisions which would have to be made. > [...] > > If you need serialization, you can use `Data.Binary`. > > Besides `Data.Binary` being vastly slower than `Storable`, the primary use case here is `Data.Vector.Storable` and `Data.Array.Storable`. You can't write an `Unbox` instance for `Maybe a`, but you can (as I've done here) write a `Storable` instance. If you directly want to use `Maybe` and `Either` with those containers, nothing is going to stop you from rolling your own. A better approach would probably be `newtype` wrappers for `Maybe` and `Either` with the corresponding `Storable` instances, making your arbitrary decisions explicit. Is using `Binary` really that much slower than your own code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:55:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:55:11 -0000 Subject: [GHC] #5059: Pragma to SPECIALISE on value arguments In-Reply-To: <053.849bb392c496a215b6de8dc003fc625c@haskell.org> References: <053.849bb392c496a215b6de8dc003fc625c@haskell.org> Message-ID: <068.468ab512d74ff3413be5e46334e1052f@haskell.org> #5059: Pragma to SPECIALISE on value arguments -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: SpecConstr, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => SpecConstr, StaticArgumentTransformation Comment: In comment:10 Max notes that SAT provides 20-30% wins in nofib, wow! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 10:56:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 10:56:38 -0000 Subject: [GHC] #4941: SpecConstr generates functions that do not use their arguments In-Reply-To: <046.96b4c779d798fee1961760fb67e6fe6f@haskell.org> References: <046.96b4c779d798fee1961760fb67e6fe6f@haskell.org> Message-ID: <061.70efb9c768526b9ff00a139e97ef4efe@haskell.org> #4941: SpecConstr generates functions that do not use their arguments -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.0.1 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 11:59:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 11:59:16 -0000 Subject: [GHC] #2255: Improve SpecConstr for free variables In-Reply-To: <046.8df476ad68a5391260ec75cd3c9c045f@haskell.org> References: <046.8df476ad68a5391260ec75cd3c9c045f@haskell.org> Message-ID: <061.0cf2f54b6e6bb59bb5337bd766a3a5cc@haskell.org> #2255: Improve SpecConstr for free variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 11:59:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 11:59:28 -0000 Subject: [GHC] #3767: SpecConstr for join points In-Reply-To: <046.4ab0a63e59360e2986f5c0a1b503004f@haskell.org> References: <046.4ab0a63e59360e2986f5c0a1b503004f@haskell.org> Message-ID: <061.b139ec784fcb2624c222b0ad553133ca@haskell.org> #3767: SpecConstr for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 11:59:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 11:59:45 -0000 Subject: [GHC] #2642: Improve SpecConstr for join points In-Reply-To: <046.b2eed70c8de5c8334b5f0d2bce85500e@haskell.org> References: <046.b2eed70c8de5c8334b5f0d2bce85500e@haskell.org> Message-ID: <061.926d1119aa9974a600b3dd2cd437d124@haskell.org> #2642: Improve SpecConstr for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 11:59:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 11:59:58 -0000 Subject: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@haskell.org> References: <044.5fe60f4f535f1251caca48895d45a780@haskell.org> Message-ID: <059.a4c76042b4f200df316c8f15ab4e567c@haskell.org> #3831: SpecConstr should exploit cases where there is exactly one call pattern -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | simplCore/should_compile/T3831 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 12:00:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 12:00:30 -0000 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@haskell.org> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@haskell.org> Message-ID: <061.0a56b889eb4ff4bb80b825e549a79b82@haskell.org> #2598: Avoid excessive specialisation in SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 12:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 12:19:41 -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.76e9170ef377c5ae7a06d3bba3746c23@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 simonpj): About forcing the type before passing to `mkBoringStop`. Often the type passed into `mkBoringStop` is discarded unused, so I'd prefer not to force it when building a `SimplCont`. I'd prefer to force it when getting it out of the `SimplCont`. Notably, `contResultType` does that. So, possible alternative plan: when extracting the `contResultType` can we just force it then? E.g. {{{ ; let alts_ty' = contResultType dup_cont ; case_expr <- mkCase dflags scrut' case_bndr' alts_ty' alts' }}} Aha -- you have already added a `seq` there! Here's another (line 1622 of `Simplify`) {{{ missingAlt env case_bndr _ cont = WARN( True, text "missingAlt" <+> ppr case_bndr ) return (env, mkImpossibleExpr (contResultType cont)) }}} Here want to force that type. Ditto here (line 1656) {{{ | not (contIsTrivial cont) -- Only do this if there is a non-trivial = return (env, castBottomExpr res cont_ty) -- continuation to discard, else we do it where -- again and again! res = argInfoExpr fun rev_args cont_ty = contResultType cont }}} But not here (line 1591) {{{ trim_cont 0 cont = mkBoringStop (contResultType cont) }} because we are just building another `SimplCont`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 13:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 13:19:41 -0000 Subject: [GHC] #13505: Write the name of the people of the Haskell Committee into the GHC compiler Message-ID: <044.7bbc5e3186437f444a10b3d223e19279@haskell.org> #13505: Write the name of the people of the Haskell Committee into the GHC compiler -------------------------------------+------------------------------------- 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: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi,\\ Write the name of the people in the Haskell report file is good.\\ I propose to write also the names in the compiler.\\\\ The names would be accessible, for instance, by the following commands:\\ with GHC in a command line: {{{ghc -- Committee}}}\\ with GHCi: {{{: Committee}}}\\\\ For instance, in the Haskell 2010 Language Report, the Haskell Committee is not up-to-date. In the last release of GHC, 8.0.2, it would have been the current Committee with the former.\\ What do you all think?\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 13:21:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 13:21:13 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.59fc87a1fbe4921798fd6efd22632fdd@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Reading the aforementioned [https://github.com/ghc/ghc/commit/0b79d5cd4687dacf7efd430df7fba9d9a5a5ce32 #diff-dce00d71def2bd086622a775b0723323R71 commit] in detail, it seems that the code currently doesn't do what the code may not follow the intents expressed in the comments: {{{ + * The timer interrupt transitions ACTIVITY_YES into + * ACTIVITY_MAYBE_NO, waits for RtsFlags.GcFlags.idleGCDelayTime, + * and then: + * - if idle GC is no, set ACTIVITY_INACTIVE and wakeUpRts() + * - if idle GC is off, set ACTIVITY_DONE_GC and stopTimer() }}} [https://github.com/ghc/ghc/blob/380b25ea4754c2aea683538ffdb179f8946219a0/rts/Timer.c#L66 Code:] {{{ if (RtsFlags.GcFlags.doIdleGC) { recent_activity = ACTIVITY_INACTIVE; #ifdef THREADED_RTS ... }}} It depends on what `if idle GC is no` (read: `on`) means. In many places I have read that idle GC can really only be "on" in the threaded RTS. In that case, the code does not implement the comment, as it sets `ACTIVITY_INACTIVE` even when we're not in the threaded RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 13:21:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 13:21:18 -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.67862322a413616e7c7d0bcb5dee22cb@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I just tried compiling the programs in comment:5 and comment:8 with GHC 8.2.1 and HEAD, and neither went into an infinite loop. I'm not sure OtToMH what commit fixed this (wild guess: 8674883c137401873fd53a6963acd33af651c2af ?), but we should find it and add a regression test for it so that this stays fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 13:40:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 13:40:53 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.545a29da3a2437639077eb20e4c76ce1@haskell.org> #5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: fixed | Keywords: Inlining Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #8613, #9070, | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: I tried all the examples in this thread compiling with `-c -O2` on `ghc-8.0.2` and they all compile without panicking. Please open new tickets if you see this panic in future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 13:58:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 13:58:46 -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.43cd293a4bf62aa16571f74f30d1817e@haskell.org> #7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Seems plausible that it was the join points patch. Nothing else in the file history looks like a big change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 15:02:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 15:02:34 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.420d1e8586f57a59d052d2acf32ada8a@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Some comments I've found in the code base: {{{ switch (recent_activity) { case ACTIVITY_INACTIVE: if (force_major) { // We are doing a GC because the system has been idle for a // timeslice and we need to check for deadlock. Record the // fact that we've done a GC and turn off the timer signal; // it will get re-enabled if we run any threads after the GC. recent_activity = ACTIVITY_DONE_GC; }}} {{{ switch (recent_activity) { case ACTIVITY_DONE_GC: { // ACTIVITY_DONE_GC means we turned off the timer signal to // conserve power (see #1623). Re-enable it here. }}} So the disabling of the timer signal is a power saving feature. I don't understand though why this is only done after a certain time (`idleGCDelayTime / tickInterval` many ticks) instead of immediately. Is there something we know only after that many ticks? Or is it a performance optimisation to do it after that many ticks instead of immediately? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 15:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 15:15:18 -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.99dedcf337c029c9d25dc907fb67647e@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, `aeson` has resolved this upstream by increasing the `simpl-tick- factor` to 200 for that particular benchmark (see [https://github.com/bos/aeson/issues/502 this issue], and [https://github.com/bos/aeson/commit/35ae44dbec513b45d4ec94d95588c56d35b7f88a #diff-2f38c1adee324e73bf376a514fd4a3ae this commit]). I slightly reduced the [https://github.com/bos/aeson/issues/502#issuecomment-269911373 test case] here, but I do ultimately think that overly aggressive `INLINE`-ing is the culprit here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 16:09:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 16:09:29 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.9af0187331e7be09ca46e437acdef227@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @nh2 the timer signal gets turned off after the idle GC. We can't turn it off before the idle GC, because then we would never do the idle GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 16:52:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 16:52:54 -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.1e1242d5814fecb59d3a1dbc08b24407@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 Simon Peyton Jones ): In [changeset:"29645274a3c97a904759aa245dc8f8c03a58c601/ghc" 2964527/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29645274a3c97a904759aa245dc8f8c03a58c601" Refactor simplExpr (Type ty) This small refactoring, provoked by comment:18 on Trac #13426, makes it so that simplExprF never gets a (Type ty) expression to simplify, which in turn means that calls to exprType on its argument will always succeed. No change in behaviour. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 16:53:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 16:53:47 -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.05486a3bec65a4e97d81111588d9755e@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 simonpj): > Please advise! I've pushed a fix (to HEAD) that should resolve this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 18:43:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 18:43:21 -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.89f0a43e95519a3958863d90a18ab78c@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 rwbarton): Let's keep this open as it pointed out that GHC fails to ignore `-fllvm` in an unregisterized compiler. I don't have time to fix this right now but it looks like we just need to check for `HscLlvm` as well in this snippet near the end of `DynFlags`: {{{#!hs | hscTarget dflags == HscAsm && platformUnregisterised (targetPlatform dflags) = loop (dflags { hscTarget = HscC }) "Compiler unregisterised, so compiling via C" }}} (Maybe it would even be better to merge the targets `HscAsm` and `HscLlvm`, since they are equivalent for most purposes besides actually building the build pipeline?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 19:38:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 19:38:08 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.5f1c5260a5b92e301e0e4e3b7facfa83@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- 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: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:11 nh2]: > The `select()` occurrence in `awaitEvent()` waits for `sleeping_queue->block_info.target - now` ([https://github.com/ghc/ghc/blob/380b25ea4754c2aea683538ffdb179f8946219a0/rts/posix/Select.c#L316 code]) so that also needs to be vetted on whether it has the `&tv` updating problem on non-Linux. OK, I've looked into that in detail now and added some printfs, and I think this `select()` needs some update as well if we want it to wake up precisely at `sleeping_queue->block_info.target`. The reasoning is the following: Inside the `while ((numFound = select(maxfd+1, &rfd, &wfd, NULL, ptv)) < 0) { ... }` there's this code: {{{ /* check for threads that need waking up */ wakeUpSleepingThreads(getLowResTimeOfDay()); /* If new runnable threads have arrived, stop waiting for * I/O and run them. */ if (!emptyRunQueue(&MainCapability)) { return; /* still hold the lock */ } }}} After an EINTR has interrupted `select()`, `wakeUpSleepingThreads(getLowResTimeOfDay())` checks whether there is a Haskell thread that wants to run (whether we are past its `sleeping_queue->block_info.target` time) -- and that includes the thread for which we're currently `select`ing -- and if so, we `return` out of the C code. So we're looking at the current time in each loop iteration. Consequently, we don't have the same problem as in `fdReady`, as this scheme does not rely on `select()` updating the passed in `struct timeval *ptv` pointer. However, there is still a problem: The `EINTR`s interrupting the `select()` come at fixed intervals (the timer signal). That can result in us waiting slighly too long. For example, assume `*ptv` is set to 15 ms (`sleeping_queue->block_info.target` is 15 ms from `now`), and assume the timer signal is every 10 ms. Then we would enter `select(15ms)`, get interrupted with EINTR after 10ms, and then call `select(15ms)` again in the same while loop. With the next timer EINTR 10ms later, we would `return` out of the `while` loop, so we're not at risk of running forever due to EINTR. But we have now waited 20ms in total instead of the desired 15ms. That's why I currently believe that the timeout argument to this `select()` should be recalculated based on the current time in every iteration, similar to how my fix for `fdReady()` does it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 19:44:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 19:44:50 -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.a399409dd5871f3312288e887549492a@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think Ryan is right that the `INLINE` pragmas in `Data.Aeson.Encoding.Builder` are too aggressive. In this example, `utcTime` contains a call to `timeOfDay` which is a huge function marked with an `INLINE` pragma. This causes the unoptimised unfolding for `timeOfDay` to be inlined into the unfolding for `utcTime` which is then inlined 12 times in the example Ryan posted. So there is a lot of duplicated work because of how the inline pragmas cause unfoldings not to be optimised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 21:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 21:06:07 -0000 Subject: [GHC] #13506: Spurious extra error message due to functional dependencies Message-ID: <046.671390fc101e477bef2ba99f8b38e846@haskell.org> #13506: Spurious extra error message due to functional dependencies -------------------------------------+------------------------------------- Reporter: gelisam | 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: -------------------------------------+------------------------------------- One call site is ill-typed, but GHC reports a type error at every call site, not just the problematic one. In the original code, the problem occurred with a very common function (`Data.Lens.view`), so the avalanche of error messages made it difficult to find the problematic call site. {{{#!hs {-# LANGUAGE FlexibleInstances, FunctionalDependencies, MultiParamTypeClasses #-} module Bug where class FunDep lista a | lista -> a instance FunDep [a] a singleton :: FunDep lista a => a -> lista singleton _ = undefined -- this error is expected: -- Couldn't match type 'Char' with '()' -- arising from a functional dependency between -- constraint 'FunDep [Char] ()' arising from a use of 'singleton' -- instance 'FunDep [a] a' illTyped :: [Char] illTyped = singleton () -- but this one is not: -- Couldn't match type '()' with 'Char' -- arising from a functional dependency between constraints: -- 'FunDep [Char] Char' arising from a use of 'singleton' (in 'wellTyped') -- 'FunDep [Char] ()' arising from a use of 'singleton' (in 'illTyped') wellTyped :: [Char] wellTyped = singleton 'a' }}} The spurious error disappears if `illTyped` is commented out or moved after `wellTyped`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 21:28:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 21:28:42 -0000 Subject: [GHC] #13498: More storable instances? In-Reply-To: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> References: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> Message-ID: <060.cdd0aa4a03701b8922ac0a0b327407a8@haskell.org> #13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Storable, | Foreign, Ptr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wyager): > Remember that the prime motivation for Storable is the FFI That's a fair argument. But I'm curious; how often do people use the various `Storable` array types? I use `Data.Vector.Storable` a fair amount, and if that's a common use case, it makes sense to support it as well. > nothing is going to stop you from rolling your own Which is precisely what I've done here, although I think it could make sense to use a standardized, agreed-upon representation known to be alignment-safe and have good performance. That said, I think you're right that this would be equally well-served by a library external to `base`, so on that note I'll close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 21:29:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 21:29:30 -0000 Subject: [GHC] #13498: More storable instances? In-Reply-To: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> References: <045.e1728b95de6dfb6844e4eb5308276d6c@haskell.org> Message-ID: <060.9a267bf9530e72cd687cf059695f05d0@haskell.org> #13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: worksforme | Keywords: Storable, | Foreign, Ptr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by wyager): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 22:18:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 22:18: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.908ebb0181a57d3239649cddad1af4cb@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 Ben Gamari ): In [changeset:"e13419c5562ed0aa587516255d1dbb48a8165457/ghc" e13419c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e13419c5562ed0aa587516255d1dbb48a8165457" Fix space leaks in simplifier (#13426) The Join points commit (8d5cf8bf) introduced a space leak somewhere in the simplifier. The extra strictness added in this commit fixes the leak. Unfortunately I don't really understand the details. Unfortunately, the extra strictness appears to result in more overall allocations in some cases, even while the peak heap size decreases in others. Test Plan: harbormaster Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3399 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 22:41:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 22:41:50 -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.0b24938688a9447ccdc62e06c33e9404@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 RyanGlScott): This error message has had an interesting history. In GHC 7.4.2 and earlier, you get the error message that you desire: {{{ GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:12: Couldn't match type `Char' with `()' When using functional dependencies to combine FunDep [a] a, arising from the dependency `lista -> a' in the instance declaration at Bug.hs:5:10 FunDep [Char] (), arising from a use of `singleton' at Bug.hs:16:12-20 In the expression: singleton () In an equation for `illTyped': illTyped = singleton () Failed, modules loaded: none. }}} In GHC 7.6.3, it changed to the current behavior: {{{ GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:12: Couldn't match type `Char' with `()' When using functional dependencies to combine FunDep [a] a, arising from the dependency `lista -> a' in the instance declaration at Bug.hs:5:10 FunDep [Char] (), arising from a use of `singleton' at Bug.hs:16:12-20 In the expression: singleton () In an equation for `illTyped': illTyped = singleton () Bug.hs:24:13: Couldn't match type `()' with `Char' When using functional dependencies to combine FunDep [Char] (), arising from a use of `singleton' at Bug.hs:16:12-20 FunDep [Char] Char, arising from a use of `singleton' at Bug.hs:24:13-21 In the expression: singleton 'a' In an equation for `wellTyped': wellTyped = singleton 'a' }}} But in GHC 7.8.4, it was briefly fixed again! {{{ GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:12: No instance for (FunDep [Char] ()) arising from a use of ‘singleton’ In the expression: singleton () In an equation for ‘illTyped’: illTyped = singleton () }}} But in GHC 7.10.3 and later, we get the current error message again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 22:45:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 22:45:05 -0000 Subject: [GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE In-Reply-To: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> References: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> Message-ID: <065.2d2dc4d9ecd3255f0132375baba251b6@haskell.org> #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE -----------------------------------+-------------------------------------- Reporter: pggiarrusso | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by allbery_b): The specific circumstances that would lead to this are: - runtime does an `madvise` to request a new page. This returns success/fail of the request, but the OS does not actually assign a page until it is needed - if the page can't actually be allocated at the time of first use (which likely means first write to it), the process will be sent `SIGSEGV` This is one reason other projects don't use this style of memory management any more (somewhat infamously, the original Bourne shell did memory allocation this way, but instead of `madvise` --- which didn't exist yet --- it just caught the `SIGSEGV` and called `brk` to increase the allocated address space). That sort-of worked (except on MC68000; Sun had to rewrite the Bourne shell's memory manager) on non-demand paged systems, but delayed-until-use allocation on demand paged systems means `SEGV` is the only way to know an allocation failed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 22:48:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 22:48:44 -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.790a186008a044375064bfacec453f8c@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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ezyang (added) * status: new => patch * differential: => Phab:D3404 Comment: Huh, the commit that fixed this turned out to be something quite different from what I was imagining. It's actually b8b3e30a6eedf9f213b8a718573c4827cfa230ba (Axe RecFlag on TyCons.) I don't know if this change directly fixes the issue or if it's just a happy coincidence (ezyang, any thoughts?), but either way, I've added a regression test in Phab:D3404. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 23:10:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 23:10:11 -0000 Subject: [GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE In-Reply-To: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> References: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> Message-ID: <065.3bc2a62566885d7e13f886c9cd58203a@haskell.org> #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE -----------------------------------+-------------------------------------- Reporter: pggiarrusso | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by pggiarrusso): Thanks for looking into this bug and replying, but the code I pointed to doesn't seem to use madvise (except at reallocation time). Maybe you're thinking of some other GHC allocator? This is new in 8.0.1. I've tried to confirm your analysis but was unable to find evidence. I pointed to a void function calling my_mmap (which calls mmap on Linux) and ignoring any failure from it. So the obvious explanation is that mmap is failing and GHC is writing to the page anyway since it considers it allocated; that's consistent with GDB failing to access *bd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 23:27:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 23:27:53 -0000 Subject: [GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE In-Reply-To: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> References: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> Message-ID: <065.3c216684a00a315e27ea4c1c06d6cf7f@haskell.org> #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE -----------------------------------+-------------------------------------- Reporter: pggiarrusso | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by pggiarrusso): > that's consistent with GDB failing to access *bd. But GDB behavior is also consistent with a mapping existing without a backing page. To tell the difference, on would probably need to look at /proc/XXX/maps file at failure time, to see if there is a mapping covering the address in bd. Regardless, I'd patch osCommitMemory no matter what, unless somebody can explain why it's correct to ignore a failure from mmap. If that needs saying: yes, mmap can fail, even with default settings of https://www.kernel.org/doc/Documentation/vm/overcommit-accounting according to those docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 31 23:53:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Mar 2017 23:53:05 -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.2062c0a0d360661ccdd67c0a509476c3@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: rwbarton 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 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Comment;20 and comment:22 merged to `ghc-8.2` as 4d724299a3aedfaec99b7d14187736fe5886de1a and 0d20cc11c95de33b8a125555c16d2b0860030227. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 19 00:10:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Mar 2017 00:10:05 -0000 Subject: [GHC] #13447: error on MacOS Sierra upgrading stack In-Reply-To: <047.6ba3c83fc73a5c6771edcf78f4ed56cb@haskell.org> References: <047.6ba3c83fc73a5c6771edcf78f4ed56cb@haskell.org> Message-ID: <062.f7cb42348f027285394ce3fa1741a782@haskell.org> #13447: error on MacOS Sierra upgrading stack ---------------------------------+------------------------------------- Reporter: wolfkden | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: stack upgrade Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------------- Changes (by dfeuer): * version: 8.0.1 => 7.10.3 Old description: > Wolfgangs-MacBook-Air:~ wolf$ stack upgrade > Fetched package index. > Populated index cache. > stack-1.4.0: download > Downloaded lts-6.25 build plan. > Caching build plan > Preparing to install GHC to an isolated location. > This will not interfere with any system-level installation. > Downloaded ghc-7.10.3. > Installed GHC. > [1 of 1] Compiling Main ( > /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack68242/Setup.hs, > /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack68242/Setup.o > ) > Linking /Users/wolf/.stack/setup-exe-cache/x86_64-osx/tmp-setup-Simple- > Cabal-1.22.5.0-ghc-7.10.3 ... > HUnit-1.3.1.2: download > annotated-wl-pprint-0.7.0: download > Cabal-1.24.2.0: download > annotated-wl-pprint-0.7.0: configure > SHA-1.6.4.2: download > annotated-wl-pprint-0.7.0: build > HUnit-1.3.1.2: configure > HUnit-1.3.1.2: build > Cabal-1.24.2.0: configure > Cabal-1.24.2.0: build > SHA-1.6.4.2: configure > SHA-1.6.4.2: build > annotated-wl-pprint-0.7.0: copy/register > ansi-terminal-0.6.2.3: download > ansi-terminal-0.6.2.3: configure > ansi-terminal-0.6.2.3: build > HUnit-1.3.1.2: copy/register > auto-update-0.1.4: download > auto-update-0.1.4: configure > auto-update-0.1.4: build > auto-update-0.1.4: copy/register > ansi-terminal-0.6.2.3: copy/register > base-compat-0.9.1: download > base-compat-0.9.1: configure > ansi-wl-pprint-0.6.7.3: download > base-compat-0.9.1: build > ansi-wl-pprint-0.6.7.3: configure > ansi-wl-pprint-0.6.7.3: build > ansi-wl-pprint-0.6.7.3: copy/register > base-orphans-0.5.4: download > base-compat-0.9.1: copy/register > base-orphans-0.5.4: configure > base16-bytestring-0.1.1.6: download > base-orphans-0.5.4: build > base16-bytestring-0.1.1.6: configure > base16-bytestring-0.1.1.6: build > base16-bytestring-0.1.1.6: copy/register > base64-bytestring-1.0.0.1: configure > base64-bytestring-1.0.0.1: build > base64-bytestring-1.0.0.1: copy/register > byteable-0.1.1: download > byteable-0.1.1: configure > byteable-0.1.1: build > byteable-0.1.1: copy/register > bytestring-builder-0.10.6.0.0: configure > bytestring-builder-0.10.6.0.0: build > bytestring-builder-0.10.6.0.0: copy/register > clock-0.7.2: download > clock-0.7.2: configure > clock-0.7.2: build > clock-0.7.2: copy/register > cryptohash-sha256-0.11.100.1: download > cryptohash-sha256-0.11.100.1: configure > cryptohash-sha256-0.11.100.1: build > base-orphans-0.5.4: copy/register > data-default-class-0.0.1: configure > data-default-class-0.0.1: build > cryptohash-sha256-0.11.100.1: copy/register > data-default-class-0.0.1: copy/register > dlist-0.7.1.2: configure > digest-0.0.1.2: download > dlist-0.7.1.2: build > digest-0.0.1.2: configure > digest-0.0.1.2: build > dlist-0.7.1.2: copy/register > digest-0.0.1.2: copy/register > easy-file-0.2.1: download > ed25519-0.0.5.0: download > easy-file-0.2.1: configure > easy-file-0.2.1: build > ed25519-0.0.5.0: configure > ed25519-0.0.5.0: build > easy-file-0.2.1: copy/register > extra-1.4.10: download > extra-1.4.10: configure > extra-1.4.10: build > ed25519-0.0.5.0: copy/register > extra-1.4.10: copy/register > file-embed-0.0.10: download > file-embed-0.0.10: configure > fail-4.9.0.0: download > file-embed-0.0.10: build > fail-4.9.0.0: configure > fail-4.9.0.0: build > fail-4.9.0.0: copy/register > cereal-0.5.2.0: download > file-embed-0.0.10: copy/register > cereal-0.5.2.0: configure > filelock-0.1.0.1: download > cereal-0.5.2.0: build > filelock-0.1.0.1: configure > filelock-0.1.0.1: build > filelock-0.1.0.1: copy/register > generic-deriving-1.10.5: download > generic-deriving-1.10.5: configure > generic-deriving-1.10.5: build > cereal-0.5.2.0: copy/register > generics-sop-0.2.2.0: download > generics-sop-0.2.2.0: configure > generics-sop-0.2.2.0: build > generic-deriving-1.10.5: copy/register > gitrev-1.2.0: download > gitrev-1.2.0: configure > gitrev-1.2.0: build > gitrev-1.2.0: copy/register > hourglass-0.2.10: download > hourglass-0.2.10: configure > hourglass-0.2.10: build > hourglass-0.2.10: copy/register > hspec-discover-2.2.4: download > hspec-discover-2.2.4: configure > hspec-discover-2.2.4: build > hspec-discover-2.2.4: copy/register > hspec-expectations-0.7.2: download > hspec-expectations-0.7.2: configure > hspec-expectations-0.7.2: build > hspec-expectations-0.7.2: copy/register > ieee754-0.7.9: download > ieee754-0.7.9: configure > ieee754-0.7.9: build > ieee754-0.7.9: copy/register > memory-0.13: download > memory-0.13: configure > memory-0.13: build > SHA-1.6.4.2: copy/register > microlens-0.4.7.0: download > microlens-0.4.7.0: configure > microlens-0.4.7.0: build > microlens-0.4.7.0: copy/register > generics-sop-0.2.2.0: copy/register > monad-loops-0.4.3: configure > memory-0.13: copy/register > monad-loops-0.4.3: build > mtl-2.2.1: configure > asn1-types-0.3.2: download > mtl-2.2.1: build > asn1-types-0.3.2: configure > asn1-types-0.3.2: build > monad-loops-0.4.3: copy/register > cryptonite-0.19: download > cryptonite-0.19: configure > cryptonite-0.19: build > mtl-2.2.1: copy/register > asn1-types-0.3.2: copy/register > logict-0.6.0.2: download > logict-0.6.0.2: configure > asn1-encoding-0.9.4: download > logict-0.6.0.2: build > asn1-encoding-0.9.4: configure > asn1-encoding-0.9.4: build > logict-0.6.0.2: copy/register > nats-1.1.1: download > nats-1.1.1: configure > nats-1.1.1: build > nats-1.1.1: copy/register > network-2.6.3.1: download > asn1-encoding-0.9.4: copy/register > network-2.6.3.1: configure > asn1-parse-0.9.4: download > network-2.6.3.1: build > asn1-parse-0.9.4: configure > asn1-parse-0.9.4: build > asn1-parse-0.9.4: copy/register > old-locale-1.0.0.7: configure > old-locale-1.0.0.7: build > old-locale-1.0.0.7: copy/register > old-time-1.1.0.3: configure > old-time-1.1.0.3: build > network-2.6.3.1: copy/register > open-browser-0.2.1.0: download > open-browser-0.2.1.0: configure > open-browser-0.2.1.0: build > old-time-1.1.0.3: copy/register > patience-0.1.1: download > patience-0.1.1: configure > open-browser-0.2.1.0: copy/register > patience-0.1.1: build > pem-0.2.2: download > pem-0.2.2: configure > pem-0.2.2: build > patience-0.1.1: copy/register > pem-0.2.2: copy/register > pid1-0.1.0.0: download > pid1-0.1.0.0: configure > prelude-extras-0.4.0.3: download > pid1-0.1.0.0: build > prelude-extras-0.4.0.3: configure > prelude-extras-0.4.0.3: build > pid1-0.1.0.0: copy/register > primitive-0.6.1.0: configure > primitive-0.6.1.0: build > prelude-extras-0.4.0.3: copy/register > random-1.1: configure > random-1.1: build > primitive-0.6.1.0: copy/register > regex-applicative-0.3.3: download > regex-applicative-0.3.3: configure > regex-applicative-0.3.3: build > regex-applicative-0.3.3: copy/register > random-1.1: copy/register > safe-0.3.10: download > safe-0.3.10: configure > safe-0.3.10: build > setenv-0.1.1.3: download > setenv-0.1.1.3: configure > setenv-0.1.1.3: build > setenv-0.1.1.3: copy/register > silently-1.2.5: configure > silently-1.2.5: build > safe-0.3.10: copy/register > silently-1.2.5: copy/register > smallcheck-1.1.1: download > smallcheck-1.1.1: configure > socks-0.5.5: download > smallcheck-1.1.1: build > socks-0.5.5: configure > socks-0.5.5: build > smallcheck-1.1.1: copy/register > split-0.2.3.1: download > split-0.2.3.1: configure > split-0.2.3.1: build > split-0.2.3.1: copy/register > stm-2.4.4.1: download > stm-2.4.4.1: configure > stm-2.4.4.1: build > socks-0.5.5: copy/register > syb-0.6: download > syb-0.6: configure > stm-2.4.4.1: copy/register > syb-0.6: build > StateVar-1.1.0.4: download > StateVar-1.1.0.4: configure > StateVar-1.1.0.4: build > StateVar-1.1.0.4: copy/register > async-2.1.0: download > async-2.1.0: configure > async-2.1.0: build > syb-0.6: copy/register > stm-chans-3.0.0.4: configure > async-2.1.0: copy/register > tagged-0.8.4: download > stm-chans-3.0.0.4: build > tagged-0.8.4: configure > tagged-0.8.4: build > stm-chans-3.0.0.4: copy/register > tar-0.5.0.3: download > tar-0.5.0.3: configure > tagged-0.8.4: copy/register > tar-0.5.0.3: build > text-1.2.2.1: download > cryptonite-0.19: copy/register > text-1.2.2.1: configure > text-1.2.2.1: build > cryptohash-0.11.9: download > cryptohash-0.11.9: configure > cryptohash-0.11.9: build > cryptohash-0.11.9: copy/register > tf-random-0.5: download > tf-random-0.5: configure > tf-random-0.5: build > tar-0.5.0.3: copy/register > th-expand-syns-0.4.1.0: download > th-expand-syns-0.4.1.0: configure > th-expand-syns-0.4.1.0: build > tf-random-0.5: copy/register > QuickCheck-2.8.2: download > QuickCheck-2.8.2: configure > th-expand-syns-0.4.1.0: copy/register > QuickCheck-2.8.2: build > th-lift-0.7.6: download > th-lift-0.7.6: configure > th-lift-0.7.6: build > th-lift-0.7.6: copy/register > th-reify-many-0.1.6: download > th-reify-many-0.1.6: configure > th-reify-many-0.1.6: build > th-reify-many-0.1.6: copy/register > time-locale-compat-0.1.1.3: download > time-locale-compat-0.1.1.3: configure > time-locale-compat-0.1.1.3: build > time-locale-compat-0.1.1.3: copy/register > transformers-compat-0.4.0.4: configure > transformers-compat-0.4.0.4: build > transformers-compat-0.4.0.4: copy/register > MonadRandom-0.4.2.3: download > MonadRandom-0.4.2.3: configure > MonadRandom-0.4.2.3: build > MonadRandom-0.4.2.3: copy/register > distributive-0.5.0.2: download > distributive-0.5.0.2: configure > distributive-0.5.0.2: build > QuickCheck-2.8.2: copy/register > distributive-0.5.0.2: copy/register > exceptions-0.8.3: download > exceptions-0.8.3: configure > microlens-mtl-0.1.10.0: download > exceptions-0.8.3: build > microlens-mtl-0.1.10.0: configure > microlens-mtl-0.1.10.0: build > exceptions-0.8.3: copy/register > microlens-mtl-0.1.10.0: copy/register > mmorph-1.0.6: download > mmorph-1.0.6: configure > quickcheck-io-0.1.4: download > mmorph-1.0.6: build > quickcheck-io-0.1.4: configure > quickcheck-io-0.1.4: build > quickcheck-io-0.1.4: copy/register > mmorph-1.0.6: copy/register > hspec-core-2.2.4: download > hspec-core-2.2.4: configure > retry-0.7.4.1: download > hspec-core-2.2.4: build > retry-0.7.4.1: configure > retry-0.7.4.1: build > retry-0.7.4.1: copy/register > safe-exceptions-0.1.4.0: download > safe-exceptions-0.1.4.0: configure > safe-exceptions-0.1.4.0: build > safe-exceptions-0.1.4.0: copy/register > temporary-1.2.0.4: download > temporary-1.2.0.4: configure > temporary-1.2.0.4: build > hspec-core-2.2.4: copy/register > temporary-1.2.0.4: copy/register > hspec-2.2.4: download > hspec-2.2.4: configure > hspec-smallcheck-0.4.1: download > hspec-2.2.4: build > hspec-smallcheck-0.4.1: configure > hspec-smallcheck-0.4.1: build > hspec-smallcheck-0.4.1: copy/register > hspec-2.2.4: copy/register > transformers-base-0.4.4: configure > unexceptionalio-0.3.0: download > transformers-base-0.4.4: build > unexceptionalio-0.3.0: configure > unexceptionalio-0.3.0: build > transformers-base-0.4.4: copy/register > unexceptionalio-0.3.0: copy/register > monad-control-1.0.1.0: download > monad-control-1.0.1.0: configure > errors-2.1.2: download > monad-control-1.0.1.0: build > errors-2.1.2: configure > errors-2.1.2: build > monad-control-1.0.1.0: copy/register > errors-2.1.2: copy/register > lifted-base-0.2.3.8: download > lifted-base-0.2.3.8: configure > unix-compat-0.4.1.4: download > lifted-base-0.2.3.8: build > unix-compat-0.4.1.4: configure > unix-compat-0.4.1.4: build > lifted-base-0.2.3.8: copy/register > unix-compat-0.4.1.4: copy/register > enclosed-exceptions-1.0.2: download > enclosed-exceptions-1.0.2: configure > resourcet-1.1.8.1: download > enclosed-exceptions-1.0.2: build > resourcet-1.1.8.1: configure > resourcet-1.1.8.1: build > enclosed-exceptions-1.0.2: copy/register > unix-time-0.3.7: download > unix-time-0.3.7: configure > resourcet-1.1.8.1: copy/register > conduit-1.2.8: download > unix-time-0.3.7: build > conduit-1.2.8: configure > conduit-1.2.8: build > unix-time-0.3.7: copy/register > utf8-string-1.0.1.1: download > utf8-string-1.0.1.1: configure > utf8-string-1.0.1.1: build > utf8-string-1.0.1.1: copy/register > vector-0.11.0.0: download > vector-0.11.0.0: configure > vector-0.11.0.0: build > conduit-1.2.8: copy/register > x509-1.6.4: download > x509-1.6.4: configure > x509-1.6.4: build > Cabal-1.24.2.0: copy/register > zlib-0.6.1.2: download > zlib-0.6.1.2: configure > text-1.2.2.1: copy/register > zlib-0.6.1.2: build > blaze-builder-0.4.0.2: download > blaze-builder-0.4.0.2: configure > blaze-builder-0.4.0.2: build > x509-1.6.4: copy/register > fast-logger-2.4.7: download > fast-logger-2.4.7: configure > fast-logger-2.4.7: build > blaze-builder-0.4.0.2: copy/register > blaze-markup-0.7.1.0: download > blaze-markup-0.7.1.0: configure > fast-logger-2.4.7: copy/register > blaze-markup-0.7.1.0: build > cookie-0.4.2.1: download > cookie-0.4.2.1: configure > zlib-0.6.1.2: copy/register > cookie-0.4.2.1: build > hashable-1.2.4.0: download > hashable-1.2.4.0: configure > hashable-1.2.4.0: build > cookie-0.4.2.1: copy/register > hastache-0.6.1: download > hastache-0.6.1: configure > hashable-1.2.4.0: copy/register > hastache-0.6.1: build > constraints-0.8: download > constraints-0.8: configure > constraints-0.8: build > blaze-markup-0.7.1.0: copy/register > blaze-html-0.8.1.2: download > blaze-html-0.8.1.2: configure > constraints-0.8: copy/register > blaze-html-0.8.1.2: build > hfsevents-0.1.6: download > hfsevents-0.1.6: configure > hfsevents-0.1.6: build > hastache-0.6.1: copy/register > hfsevents-0.1.6: copy/register > http-api-data-0.2.4: download > http-api-data-0.2.4: configure > fsnotify-0.2.1: download > http-api-data-0.2.4: build > fsnotify-0.2.1: configure > fsnotify-0.2.1: build > fsnotify-0.2.1: copy/register > lifted-async-0.9.0: download > lifted-async-0.9.0: configure > lifted-async-0.9.0: build > lifted-async-0.9.0: copy/register > mime-types-0.1.0.7: download > mime-types-0.1.0.7: configure > mime-types-0.1.0.7: build > http-api-data-0.2.4: copy/register > monad-unlift-0.2.0: download > monad-unlift-0.2.0: configure > blaze-html-0.8.1.2: copy/register > monad-unlift-0.2.0: build > parsec-3.1.11: download > monad-unlift-0.2.0: copy/register > parsec-3.1.11: configure > parsec-3.1.11: build > path-pieces-0.2.1: configure > path-pieces-0.2.1: build > path-pieces-0.2.1: copy/register > mime-types-0.1.0.7: copy/register > regex-applicative-text-0.1.0.1: download > regex-applicative-text-0.1.0.1: configure > store-core-0.3: download > regex-applicative-text-0.1.0.1: build > store-core-0.3: configure > store-core-0.3: build > regex-applicative-text-0.1.0.1: copy/register > streaming-commons-0.1.16: download > streaming-commons-0.1.16: configure > streaming-commons-0.1.16: build > store-core-0.3: copy/register > system-filepath-0.4.13.4: download > system-filepath-0.4.13.4: configure > system-filepath-0.4.13.4: build > parsec-3.1.11: copy/register > network-uri-2.6.1.0: download > network-uri-2.6.1.0: configure > network-uri-2.6.1.0: build > streaming-commons-0.1.16: copy/register > system-filepath-0.4.13.4: copy/register > text-binary-0.2.1.1: download > text-binary-0.2.1.1: configure > text-binary-0.2.1.1: build > network-uri-2.6.1.0: copy/register > system-fileio-0.3.16.3: download > system-fileio-0.3.16.3: configure > text-binary-0.2.1.1: copy/register > hackage-security-0.5.2.2: download > system-fileio-0.3.16.3: build > hackage-security-0.5.2.2: configure > text-metrics-0.1.0: download > hackage-security-0.5.2.2: build > text-metrics-0.1.0: configure > text-metrics-0.1.0: build > system-fileio-0.3.16.3: copy/register > text-metrics-0.1.0: copy/register > unicode-transforms-0.1.0.1: download > unordered-containers-0.2.7.1: download > unicode-transforms-0.1.0.1: configure > unicode-transforms-0.1.0.1: build > unordered-containers-0.2.7.1: configure > unordered-containers-0.2.7.1: build > unicode-transforms-0.1.0.1: copy/register > x509-store-1.6.2: download > x509-store-1.6.2: configure > x509-store-1.6.2: build > x509-store-1.6.2: copy/register > x509-system-1.6.4: download > x509-system-1.6.4: configure > x509-system-1.6.4: build > x509-system-1.6.4: copy/register > x509-validation-1.6.5: download > x509-validation-1.6.5: configure > x509-validation-1.6.5: build > x509-validation-1.6.5: copy/register > tls-1.3.8: download > tls-1.3.8: configure > tls-1.3.8: build > hackage-security-0.5.2.2: copy/register > zip-archive-0.2.3.7: download > zip-archive-0.2.3.7: configure > vector-0.11.0.0: copy/register > mwc-random-0.13.4.0: download > zip-archive-0.2.3.7: build > mwc-random-0.13.4.0: configure > mwc-random-0.13.4.0: build > zip-archive-0.2.3.7: copy/register > resource-pool-0.2.3.2: configure > resource-pool-0.2.3.2: build > unordered-containers-0.2.7.1: copy/register > scientific-0.3.4.9: download > scientific-0.3.4.9: configure > resource-pool-0.2.3.2: copy/register > semigroups-0.18.2: download > scientific-0.3.4.9: build > semigroups-0.18.2: configure > semigroups-0.18.2: build > scientific-0.3.4.9: copy/register > th-lift-instances-0.1.10: download > th-lift-instances-0.1.10: configure > th-lift-instances-0.1.10: build > th-lift-instances-0.1.10: copy/register > th-orphans-0.13.1: download > th-orphans-0.13.1: configure > th-orphans-0.13.1: build > semigroups-0.18.2: copy/register > Glob-0.7.12: download > Glob-0.7.12: configure > Glob-0.7.12: build > th-orphans-0.13.1: copy/register > attoparsec-0.13.1.0: download > attoparsec-0.13.1.0: configure > attoparsec-0.13.1.0: build > tls-1.3.8: copy/register > case-insensitive-1.2.0.7: download > case-insensitive-1.2.0.7: configure > Glob-0.7.12: copy/register > case-insensitive-1.2.0.7: build > connection-0.2.6: download > connection-0.2.6: configure > connection-0.2.6: build > case-insensitive-1.2.0.7: copy/register > dlist-instances-0.1.1.1: download > dlist-instances-0.1.1.1: configure > connection-0.2.6: copy/register > dlist-instances-0.1.1.1: build > http-types-0.9.1: download > http-types-0.9.1: configure > dlist-instances-0.1.1.1: copy/register > optparse-applicative-0.13.0.0: download > http-types-0.9.1: build > optparse-applicative-0.13.0.0: configure > optparse-applicative-0.13.0.0: build > http-types-0.9.1: copy/register > http-client-0.5.3.3: download > http-client-0.5.3.3: configure > http-client-0.5.3.3: build > optparse-applicative-0.13.0.0: copy/register > th-utilities-0.2.0.1: download > th-utilities-0.2.0.1: configure > th-utilities-0.2.0.1: build > th-utilities-0.2.0.1: copy/register > vector-binary-instances-0.2.3.2: download > vector-binary-instances-0.2.3.2: configure > vector-binary-instances-0.2.3.2: build > http-client-0.5.3.3: copy/register > http-client-tls-0.3.4: download > http-client-tls-0.3.4: configure > vector-binary-instances-0.2.3.2: copy/register > http-client-tls-0.3.4: build > void-0.7.1: download > void-0.7.1: configure > void-0.7.1: build > void-0.7.1: copy/register > http-client-tls-0.3.4: copy/register > contravariant-1.4: download > contravariant-1.4: configure > zlib-bindings-0.1.1.5: download > contravariant-1.4: build > zlib-bindings-0.1.1.5: configure > zlib-bindings-0.1.1.5: build > zlib-bindings-0.1.1.5: copy/register > contravariant-1.4: copy/register > comonad-4.2.7.2: download > comonad-4.2.7.2: configure > comonad-4.2.7.2: build > comonad-4.2.7.2: copy/register > bifunctors-5.2: download > bifunctors-5.2: configure > bifunctors-5.2: build > attoparsec-0.13.1.0: copy/register > aeson-1.0.2.1: download > conduit-extra-1.1.14: download > conduit-extra-1.1.14: configure > conduit-extra-1.1.14: build > aeson-1.0.2.1: configure > aeson-1.0.2.1: build > mwc-random-0.13.4.0: copy/register > hit-0.6.3: download > hit-0.6.3: configure > hit-0.6.3: build > bifunctors-5.2: copy/register > conduit-extra-1.1.14: copy/register > profunctors-5.2: download > profunctors-5.2: configure > cryptonite-conduit-0.1: download > profunctors-5.2: build > cryptonite-conduit-0.1: configure > cryptonite-conduit-0.1: build > cryptonite-conduit-0.1: copy/register > monad-logger-0.3.20.1: download > monad-logger-0.3.20.1: configure > monad-logger-0.3.20.1: build > monad-logger-0.3.20.1: copy/register > project-template-0.2.0: download > project-template-0.2.0: configure > project-template-0.2.0: build > profunctors-5.2: copy/register > semigroupoids-5.0.1: download > semigroupoids-5.0.1: configure > project-template-0.2.0: copy/register > vector-algorithms-0.7.0.1: download > semigroupoids-5.0.1: build > vector-algorithms-0.7.0.1: configure > vector-algorithms-0.7.0.1: build > hit-0.6.3: copy/register > semigroupoids-5.0.1: copy/register > free-4.12.4: download > free-4.12.4: configure > free-4.12.4: build > free-4.12.4: copy/register > either-4.4.1.1: download > adjunctions-4.3: download > either-4.4.1.1: configure > either-4.4.1.1: build > adjunctions-4.3: configure > adjunctions-4.3: build > either-4.4.1.1: copy/register > keys-3.11: download > keys-3.11: configure > keys-3.11: build > adjunctions-4.3: copy/register > kan-extensions-4.2.3: download > kan-extensions-4.2.3: configure > kan-extensions-4.2.3: build > keys-3.11: copy/register > optparse-simple-0.0.3: download > optparse-simple-0.0.3: configure > optparse-simple-0.0.3: build > kan-extensions-4.2.3: copy/register > optparse-simple-0.0.3: copy/register > pointed-4.2.0.2: download > pointed-4.2.0.2: configure > pointed-4.2.0.2: build > pointed-4.2.0.2: copy/register > vector-instances-3.3.1: download > vector-instances-3.3.1: configure > vector-instances-3.3.1: build > vector-instances-3.3.1: copy/register > vector-algorithms-0.7.0.1: copy/register > mono-traversable-0.10.2: download > mono-traversable-0.10.2: configure > mono-traversable-0.10.2: build > aeson-1.0.2.1: copy/register > http-conduit-2.2.3: download > binary-tagged-0.1.4.1: download > binary-tagged-0.1.4.1: configure > aeson-compat-0.3.6: download > binary-tagged-0.1.4.1: build > http-conduit-2.2.3: configure > http-conduit-2.2.3: build > aeson-compat-0.3.6: configure > aeson-compat-0.3.6: build > http-conduit-2.2.3: copy/register > aeson-compat-0.3.6: copy/register > path-0.5.9: download > path-0.5.9: configure > persistent-2.6: download > path-0.5.9: build > persistent-2.6: configure > binary-tagged-0.1.4.1: copy/register > persistent-2.6: build > yaml-0.8.20: download > yaml-0.8.20: configure > yaml-0.8.20: build > path-0.5.9: copy/register > path-io-1.1.0: download > path-io-1.1.0: configure > path-io-1.1.0: build > path-io-1.1.0: copy/register > yaml-0.8.20: copy/register > hpack-0.17.0: download > hpack-0.17.0: configure > hpack-0.17.0: build > persistent-2.6: copy/register > persistent-template-2.5.1.6: download > persistent-sqlite-2.6: download > persistent-template-2.5.1.6: configure > persistent-template-2.5.1.6: build > persistent-sqlite-2.6: configure > persistent-sqlite-2.6: build > hpack-0.17.0: copy/register > mono-traversable-0.10.2: copy/register > store-0.3: download > store-0.3: configure > store-0.3: build > persistent-template-2.5.1.6: copy/register > persistent-sqlite-2.6: copy/register > store-0.3: copy/register > stack-1.4.0: configure > [1 of 1] Compiling Main ( > /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- > upgrade68242/stack-1.4.0/Setup.hs, > /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- > upgrade68242/stack-1.4.0/.stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) > Linking /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- > upgrade68242/stack-1.4.0/.stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... > Configuring stack-1.4.0... > stack-1.4.0: build > Preprocessing library stack-1.4.0... > [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( > src/Text/PrettyPrint/Leijen/Extended.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o > ) > [ 2 of 124] Compiling > Hackage.Security.Client.Repository.HttpLib.HttpClient ( > src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o > ) > [ 3 of 124] Compiling Stack.Options.ScriptParser ( > src/Stack/Options/ScriptParser.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) > [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, > .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) > [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) > [ 6 of 124] Compiling System.Process.PagerEditor ( > src/System/Process/PagerEditor.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) > [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, > .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) > [ 8 of 124] Compiling Paths_stack ( .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) > [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) > [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) > [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, > .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.3 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/ghc89392_0/libghc_68.dylib, > 5): no suitable image found. Did find: > /var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/ghc89392_0/libghc_68.dylib: > malformed mach-o: load commands size (49264) > 32768 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Completed all 185 actions. > > -- While building package stack-1.4.0 using: > /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- > upgrade68242/stack-1.4.0/.stack- > work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- > work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- > options " -ddump-hi -ddump-to-file" > Process exited with code: ExitFailure 1 > Wolfgangs-MacBook-Air:~ wolf$ New description: {{{ Wolfgangs-MacBook-Air:~ wolf$ stack upgrade Fetched package index. Populated index cache. stack-1.4.0: download Downloaded lts-6.25 build plan. Caching build plan Preparing to install GHC to an isolated location. This will not interfere with any system-level installation. Downloaded ghc-7.10.3. Installed GHC. [1 of 1] Compiling Main ( /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack68242/Setup.hs, /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack68242/Setup.o ) Linking /Users/wolf/.stack/setup-exe-cache/x86_64-osx/tmp-setup-Simple- Cabal-1.22.5.0-ghc-7.10.3 ... HUnit-1.3.1.2: download annotated-wl-pprint-0.7.0: download Cabal-1.24.2.0: download annotated-wl-pprint-0.7.0: configure SHA-1.6.4.2: download annotated-wl-pprint-0.7.0: build HUnit-1.3.1.2: configure HUnit-1.3.1.2: build Cabal-1.24.2.0: configure Cabal-1.24.2.0: build SHA-1.6.4.2: configure SHA-1.6.4.2: build annotated-wl-pprint-0.7.0: copy/register ansi-terminal-0.6.2.3: download ansi-terminal-0.6.2.3: configure ansi-terminal-0.6.2.3: build HUnit-1.3.1.2: copy/register auto-update-0.1.4: download auto-update-0.1.4: configure auto-update-0.1.4: build auto-update-0.1.4: copy/register ansi-terminal-0.6.2.3: copy/register base-compat-0.9.1: download base-compat-0.9.1: configure ansi-wl-pprint-0.6.7.3: download base-compat-0.9.1: build ansi-wl-pprint-0.6.7.3: configure ansi-wl-pprint-0.6.7.3: build ansi-wl-pprint-0.6.7.3: copy/register base-orphans-0.5.4: download base-compat-0.9.1: copy/register base-orphans-0.5.4: configure base16-bytestring-0.1.1.6: download base-orphans-0.5.4: build base16-bytestring-0.1.1.6: configure base16-bytestring-0.1.1.6: build base16-bytestring-0.1.1.6: copy/register base64-bytestring-1.0.0.1: configure base64-bytestring-1.0.0.1: build base64-bytestring-1.0.0.1: copy/register byteable-0.1.1: download byteable-0.1.1: configure byteable-0.1.1: build byteable-0.1.1: copy/register bytestring-builder-0.10.6.0.0: configure bytestring-builder-0.10.6.0.0: build bytestring-builder-0.10.6.0.0: copy/register clock-0.7.2: download clock-0.7.2: configure clock-0.7.2: build clock-0.7.2: copy/register cryptohash-sha256-0.11.100.1: download cryptohash-sha256-0.11.100.1: configure cryptohash-sha256-0.11.100.1: build base-orphans-0.5.4: copy/register data-default-class-0.0.1: configure data-default-class-0.0.1: build cryptohash-sha256-0.11.100.1: copy/register data-default-class-0.0.1: copy/register dlist-0.7.1.2: configure digest-0.0.1.2: download dlist-0.7.1.2: build digest-0.0.1.2: configure digest-0.0.1.2: build dlist-0.7.1.2: copy/register digest-0.0.1.2: copy/register easy-file-0.2.1: download ed25519-0.0.5.0: download easy-file-0.2.1: configure easy-file-0.2.1: build ed25519-0.0.5.0: configure ed25519-0.0.5.0: build easy-file-0.2.1: copy/register extra-1.4.10: download extra-1.4.10: configure extra-1.4.10: build ed25519-0.0.5.0: copy/register extra-1.4.10: copy/register file-embed-0.0.10: download file-embed-0.0.10: configure fail-4.9.0.0: download file-embed-0.0.10: build fail-4.9.0.0: configure fail-4.9.0.0: build fail-4.9.0.0: copy/register cereal-0.5.2.0: download file-embed-0.0.10: copy/register cereal-0.5.2.0: configure filelock-0.1.0.1: download cereal-0.5.2.0: build filelock-0.1.0.1: configure filelock-0.1.0.1: build filelock-0.1.0.1: copy/register generic-deriving-1.10.5: download generic-deriving-1.10.5: configure generic-deriving-1.10.5: build cereal-0.5.2.0: copy/register generics-sop-0.2.2.0: download generics-sop-0.2.2.0: configure generics-sop-0.2.2.0: build generic-deriving-1.10.5: copy/register gitrev-1.2.0: download gitrev-1.2.0: configure gitrev-1.2.0: build gitrev-1.2.0: copy/register hourglass-0.2.10: download hourglass-0.2.10: configure hourglass-0.2.10: build hourglass-0.2.10: copy/register hspec-discover-2.2.4: download hspec-discover-2.2.4: configure hspec-discover-2.2.4: build hspec-discover-2.2.4: copy/register hspec-expectations-0.7.2: download hspec-expectations-0.7.2: configure hspec-expectations-0.7.2: build hspec-expectations-0.7.2: copy/register ieee754-0.7.9: download ieee754-0.7.9: configure ieee754-0.7.9: build ieee754-0.7.9: copy/register memory-0.13: download memory-0.13: configure memory-0.13: build SHA-1.6.4.2: copy/register microlens-0.4.7.0: download microlens-0.4.7.0: configure microlens-0.4.7.0: build microlens-0.4.7.0: copy/register generics-sop-0.2.2.0: copy/register monad-loops-0.4.3: configure memory-0.13: copy/register monad-loops-0.4.3: build mtl-2.2.1: configure asn1-types-0.3.2: download mtl-2.2.1: build asn1-types-0.3.2: configure asn1-types-0.3.2: build monad-loops-0.4.3: copy/register cryptonite-0.19: download cryptonite-0.19: configure cryptonite-0.19: build mtl-2.2.1: copy/register asn1-types-0.3.2: copy/register logict-0.6.0.2: download logict-0.6.0.2: configure asn1-encoding-0.9.4: download logict-0.6.0.2: build asn1-encoding-0.9.4: configure asn1-encoding-0.9.4: build logict-0.6.0.2: copy/register nats-1.1.1: download nats-1.1.1: configure nats-1.1.1: build nats-1.1.1: copy/register network-2.6.3.1: download asn1-encoding-0.9.4: copy/register network-2.6.3.1: configure asn1-parse-0.9.4: download network-2.6.3.1: build asn1-parse-0.9.4: configure asn1-parse-0.9.4: build asn1-parse-0.9.4: copy/register old-locale-1.0.0.7: configure old-locale-1.0.0.7: build old-locale-1.0.0.7: copy/register old-time-1.1.0.3: configure old-time-1.1.0.3: build network-2.6.3.1: copy/register open-browser-0.2.1.0: download open-browser-0.2.1.0: configure open-browser-0.2.1.0: build old-time-1.1.0.3: copy/register patience-0.1.1: download patience-0.1.1: configure open-browser-0.2.1.0: copy/register patience-0.1.1: build pem-0.2.2: download pem-0.2.2: configure pem-0.2.2: build patience-0.1.1: copy/register pem-0.2.2: copy/register pid1-0.1.0.0: download pid1-0.1.0.0: configure prelude-extras-0.4.0.3: download pid1-0.1.0.0: build prelude-extras-0.4.0.3: configure prelude-extras-0.4.0.3: build pid1-0.1.0.0: copy/register primitive-0.6.1.0: configure primitive-0.6.1.0: build prelude-extras-0.4.0.3: copy/register random-1.1: configure random-1.1: build primitive-0.6.1.0: copy/register regex-applicative-0.3.3: download regex-applicative-0.3.3: configure regex-applicative-0.3.3: build regex-applicative-0.3.3: copy/register random-1.1: copy/register safe-0.3.10: download safe-0.3.10: configure safe-0.3.10: build setenv-0.1.1.3: download setenv-0.1.1.3: configure setenv-0.1.1.3: build setenv-0.1.1.3: copy/register silently-1.2.5: configure silently-1.2.5: build safe-0.3.10: copy/register silently-1.2.5: copy/register smallcheck-1.1.1: download smallcheck-1.1.1: configure socks-0.5.5: download smallcheck-1.1.1: build socks-0.5.5: configure socks-0.5.5: build smallcheck-1.1.1: copy/register split-0.2.3.1: download split-0.2.3.1: configure split-0.2.3.1: build split-0.2.3.1: copy/register stm-2.4.4.1: download stm-2.4.4.1: configure stm-2.4.4.1: build socks-0.5.5: copy/register syb-0.6: download syb-0.6: configure stm-2.4.4.1: copy/register syb-0.6: build StateVar-1.1.0.4: download StateVar-1.1.0.4: configure StateVar-1.1.0.4: build StateVar-1.1.0.4: copy/register async-2.1.0: download async-2.1.0: configure async-2.1.0: build syb-0.6: copy/register stm-chans-3.0.0.4: configure async-2.1.0: copy/register tagged-0.8.4: download stm-chans-3.0.0.4: build tagged-0.8.4: configure tagged-0.8.4: build stm-chans-3.0.0.4: copy/register tar-0.5.0.3: download tar-0.5.0.3: configure tagged-0.8.4: copy/register tar-0.5.0.3: build text-1.2.2.1: download cryptonite-0.19: copy/register text-1.2.2.1: configure text-1.2.2.1: build cryptohash-0.11.9: download cryptohash-0.11.9: configure cryptohash-0.11.9: build cryptohash-0.11.9: copy/register tf-random-0.5: download tf-random-0.5: configure tf-random-0.5: build tar-0.5.0.3: copy/register th-expand-syns-0.4.1.0: download th-expand-syns-0.4.1.0: configure th-expand-syns-0.4.1.0: build tf-random-0.5: copy/register QuickCheck-2.8.2: download QuickCheck-2.8.2: configure th-expand-syns-0.4.1.0: copy/register QuickCheck-2.8.2: build th-lift-0.7.6: download th-lift-0.7.6: configure th-lift-0.7.6: build th-lift-0.7.6: copy/register th-reify-many-0.1.6: download th-reify-many-0.1.6: configure th-reify-many-0.1.6: build th-reify-many-0.1.6: copy/register time-locale-compat-0.1.1.3: download time-locale-compat-0.1.1.3: configure time-locale-compat-0.1.1.3: build time-locale-compat-0.1.1.3: copy/register transformers-compat-0.4.0.4: configure transformers-compat-0.4.0.4: build transformers-compat-0.4.0.4: copy/register MonadRandom-0.4.2.3: download MonadRandom-0.4.2.3: configure MonadRandom-0.4.2.3: build MonadRandom-0.4.2.3: copy/register distributive-0.5.0.2: download distributive-0.5.0.2: configure distributive-0.5.0.2: build QuickCheck-2.8.2: copy/register distributive-0.5.0.2: copy/register exceptions-0.8.3: download exceptions-0.8.3: configure microlens-mtl-0.1.10.0: download exceptions-0.8.3: build microlens-mtl-0.1.10.0: configure microlens-mtl-0.1.10.0: build exceptions-0.8.3: copy/register microlens-mtl-0.1.10.0: copy/register mmorph-1.0.6: download mmorph-1.0.6: configure quickcheck-io-0.1.4: download mmorph-1.0.6: build quickcheck-io-0.1.4: configure quickcheck-io-0.1.4: build quickcheck-io-0.1.4: copy/register mmorph-1.0.6: copy/register hspec-core-2.2.4: download hspec-core-2.2.4: configure retry-0.7.4.1: download hspec-core-2.2.4: build retry-0.7.4.1: configure retry-0.7.4.1: build retry-0.7.4.1: copy/register safe-exceptions-0.1.4.0: download safe-exceptions-0.1.4.0: configure safe-exceptions-0.1.4.0: build safe-exceptions-0.1.4.0: copy/register temporary-1.2.0.4: download temporary-1.2.0.4: configure temporary-1.2.0.4: build hspec-core-2.2.4: copy/register temporary-1.2.0.4: copy/register hspec-2.2.4: download hspec-2.2.4: configure hspec-smallcheck-0.4.1: download hspec-2.2.4: build hspec-smallcheck-0.4.1: configure hspec-smallcheck-0.4.1: build hspec-smallcheck-0.4.1: copy/register hspec-2.2.4: copy/register transformers-base-0.4.4: configure unexceptionalio-0.3.0: download transformers-base-0.4.4: build unexceptionalio-0.3.0: configure unexceptionalio-0.3.0: build transformers-base-0.4.4: copy/register unexceptionalio-0.3.0: copy/register monad-control-1.0.1.0: download monad-control-1.0.1.0: configure errors-2.1.2: download monad-control-1.0.1.0: build errors-2.1.2: configure errors-2.1.2: build monad-control-1.0.1.0: copy/register errors-2.1.2: copy/register lifted-base-0.2.3.8: download lifted-base-0.2.3.8: configure unix-compat-0.4.1.4: download lifted-base-0.2.3.8: build unix-compat-0.4.1.4: configure unix-compat-0.4.1.4: build lifted-base-0.2.3.8: copy/register unix-compat-0.4.1.4: copy/register enclosed-exceptions-1.0.2: download enclosed-exceptions-1.0.2: configure resourcet-1.1.8.1: download enclosed-exceptions-1.0.2: build resourcet-1.1.8.1: configure resourcet-1.1.8.1: build enclosed-exceptions-1.0.2: copy/register unix-time-0.3.7: download unix-time-0.3.7: configure resourcet-1.1.8.1: copy/register conduit-1.2.8: download unix-time-0.3.7: build conduit-1.2.8: configure conduit-1.2.8: build unix-time-0.3.7: copy/register utf8-string-1.0.1.1: download utf8-string-1.0.1.1: configure utf8-string-1.0.1.1: build utf8-string-1.0.1.1: copy/register vector-0.11.0.0: download vector-0.11.0.0: configure vector-0.11.0.0: build conduit-1.2.8: copy/register x509-1.6.4: download x509-1.6.4: configure x509-1.6.4: build Cabal-1.24.2.0: copy/register zlib-0.6.1.2: download zlib-0.6.1.2: configure text-1.2.2.1: copy/register zlib-0.6.1.2: build blaze-builder-0.4.0.2: download blaze-builder-0.4.0.2: configure blaze-builder-0.4.0.2: build x509-1.6.4: copy/register fast-logger-2.4.7: download fast-logger-2.4.7: configure fast-logger-2.4.7: build blaze-builder-0.4.0.2: copy/register blaze-markup-0.7.1.0: download blaze-markup-0.7.1.0: configure fast-logger-2.4.7: copy/register blaze-markup-0.7.1.0: build cookie-0.4.2.1: download cookie-0.4.2.1: configure zlib-0.6.1.2: copy/register cookie-0.4.2.1: build hashable-1.2.4.0: download hashable-1.2.4.0: configure hashable-1.2.4.0: build cookie-0.4.2.1: copy/register hastache-0.6.1: download hastache-0.6.1: configure hashable-1.2.4.0: copy/register hastache-0.6.1: build constraints-0.8: download constraints-0.8: configure constraints-0.8: build blaze-markup-0.7.1.0: copy/register blaze-html-0.8.1.2: download blaze-html-0.8.1.2: configure constraints-0.8: copy/register blaze-html-0.8.1.2: build hfsevents-0.1.6: download hfsevents-0.1.6: configure hfsevents-0.1.6: build hastache-0.6.1: copy/register hfsevents-0.1.6: copy/register http-api-data-0.2.4: download http-api-data-0.2.4: configure fsnotify-0.2.1: download http-api-data-0.2.4: build fsnotify-0.2.1: configure fsnotify-0.2.1: build fsnotify-0.2.1: copy/register lifted-async-0.9.0: download lifted-async-0.9.0: configure lifted-async-0.9.0: build lifted-async-0.9.0: copy/register mime-types-0.1.0.7: download mime-types-0.1.0.7: configure mime-types-0.1.0.7: build http-api-data-0.2.4: copy/register monad-unlift-0.2.0: download monad-unlift-0.2.0: configure blaze-html-0.8.1.2: copy/register monad-unlift-0.2.0: build parsec-3.1.11: download monad-unlift-0.2.0: copy/register parsec-3.1.11: configure parsec-3.1.11: build path-pieces-0.2.1: configure path-pieces-0.2.1: build path-pieces-0.2.1: copy/register mime-types-0.1.0.7: copy/register regex-applicative-text-0.1.0.1: download regex-applicative-text-0.1.0.1: configure store-core-0.3: download regex-applicative-text-0.1.0.1: build store-core-0.3: configure store-core-0.3: build regex-applicative-text-0.1.0.1: copy/register streaming-commons-0.1.16: download streaming-commons-0.1.16: configure streaming-commons-0.1.16: build store-core-0.3: copy/register system-filepath-0.4.13.4: download system-filepath-0.4.13.4: configure system-filepath-0.4.13.4: build parsec-3.1.11: copy/register network-uri-2.6.1.0: download network-uri-2.6.1.0: configure network-uri-2.6.1.0: build streaming-commons-0.1.16: copy/register system-filepath-0.4.13.4: copy/register text-binary-0.2.1.1: download text-binary-0.2.1.1: configure text-binary-0.2.1.1: build network-uri-2.6.1.0: copy/register system-fileio-0.3.16.3: download system-fileio-0.3.16.3: configure text-binary-0.2.1.1: copy/register hackage-security-0.5.2.2: download system-fileio-0.3.16.3: build hackage-security-0.5.2.2: configure text-metrics-0.1.0: download hackage-security-0.5.2.2: build text-metrics-0.1.0: configure text-metrics-0.1.0: build system-fileio-0.3.16.3: copy/register text-metrics-0.1.0: copy/register unicode-transforms-0.1.0.1: download unordered-containers-0.2.7.1: download unicode-transforms-0.1.0.1: configure unicode-transforms-0.1.0.1: build unordered-containers-0.2.7.1: configure unordered-containers-0.2.7.1: build unicode-transforms-0.1.0.1: copy/register x509-store-1.6.2: download x509-store-1.6.2: configure x509-store-1.6.2: build x509-store-1.6.2: copy/register x509-system-1.6.4: download x509-system-1.6.4: configure x509-system-1.6.4: build x509-system-1.6.4: copy/register x509-validation-1.6.5: download x509-validation-1.6.5: configure x509-validation-1.6.5: build x509-validation-1.6.5: copy/register tls-1.3.8: download tls-1.3.8: configure tls-1.3.8: build hackage-security-0.5.2.2: copy/register zip-archive-0.2.3.7: download zip-archive-0.2.3.7: configure vector-0.11.0.0: copy/register mwc-random-0.13.4.0: download zip-archive-0.2.3.7: build mwc-random-0.13.4.0: configure mwc-random-0.13.4.0: build zip-archive-0.2.3.7: copy/register resource-pool-0.2.3.2: configure resource-pool-0.2.3.2: build unordered-containers-0.2.7.1: copy/register scientific-0.3.4.9: download scientific-0.3.4.9: configure resource-pool-0.2.3.2: copy/register semigroups-0.18.2: download scientific-0.3.4.9: build semigroups-0.18.2: configure semigroups-0.18.2: build scientific-0.3.4.9: copy/register th-lift-instances-0.1.10: download th-lift-instances-0.1.10: configure th-lift-instances-0.1.10: build th-lift-instances-0.1.10: copy/register th-orphans-0.13.1: download th-orphans-0.13.1: configure th-orphans-0.13.1: build semigroups-0.18.2: copy/register Glob-0.7.12: download Glob-0.7.12: configure Glob-0.7.12: build th-orphans-0.13.1: copy/register attoparsec-0.13.1.0: download attoparsec-0.13.1.0: configure attoparsec-0.13.1.0: build tls-1.3.8: copy/register case-insensitive-1.2.0.7: download case-insensitive-1.2.0.7: configure Glob-0.7.12: copy/register case-insensitive-1.2.0.7: build connection-0.2.6: download connection-0.2.6: configure connection-0.2.6: build case-insensitive-1.2.0.7: copy/register dlist-instances-0.1.1.1: download dlist-instances-0.1.1.1: configure connection-0.2.6: copy/register dlist-instances-0.1.1.1: build http-types-0.9.1: download http-types-0.9.1: configure dlist-instances-0.1.1.1: copy/register optparse-applicative-0.13.0.0: download http-types-0.9.1: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build http-types-0.9.1: copy/register http-client-0.5.3.3: download http-client-0.5.3.3: configure http-client-0.5.3.3: build optparse-applicative-0.13.0.0: copy/register th-utilities-0.2.0.1: download th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build th-utilities-0.2.0.1: copy/register vector-binary-instances-0.2.3.2: download vector-binary-instances-0.2.3.2: configure vector-binary-instances-0.2.3.2: build http-client-0.5.3.3: copy/register http-client-tls-0.3.4: download http-client-tls-0.3.4: configure vector-binary-instances-0.2.3.2: copy/register http-client-tls-0.3.4: build void-0.7.1: download void-0.7.1: configure void-0.7.1: build void-0.7.1: copy/register http-client-tls-0.3.4: copy/register contravariant-1.4: download contravariant-1.4: configure zlib-bindings-0.1.1.5: download contravariant-1.4: build zlib-bindings-0.1.1.5: configure zlib-bindings-0.1.1.5: build zlib-bindings-0.1.1.5: copy/register contravariant-1.4: copy/register comonad-4.2.7.2: download comonad-4.2.7.2: configure comonad-4.2.7.2: build comonad-4.2.7.2: copy/register bifunctors-5.2: download bifunctors-5.2: configure bifunctors-5.2: build attoparsec-0.13.1.0: copy/register aeson-1.0.2.1: download conduit-extra-1.1.14: download conduit-extra-1.1.14: configure conduit-extra-1.1.14: build aeson-1.0.2.1: configure aeson-1.0.2.1: build mwc-random-0.13.4.0: copy/register hit-0.6.3: download hit-0.6.3: configure hit-0.6.3: build bifunctors-5.2: copy/register conduit-extra-1.1.14: copy/register profunctors-5.2: download profunctors-5.2: configure cryptonite-conduit-0.1: download profunctors-5.2: build cryptonite-conduit-0.1: configure cryptonite-conduit-0.1: build cryptonite-conduit-0.1: copy/register monad-logger-0.3.20.1: download monad-logger-0.3.20.1: configure monad-logger-0.3.20.1: build monad-logger-0.3.20.1: copy/register project-template-0.2.0: download project-template-0.2.0: configure project-template-0.2.0: build profunctors-5.2: copy/register semigroupoids-5.0.1: download semigroupoids-5.0.1: configure project-template-0.2.0: copy/register vector-algorithms-0.7.0.1: download semigroupoids-5.0.1: build vector-algorithms-0.7.0.1: configure vector-algorithms-0.7.0.1: build hit-0.6.3: copy/register semigroupoids-5.0.1: copy/register free-4.12.4: download free-4.12.4: configure free-4.12.4: build free-4.12.4: copy/register either-4.4.1.1: download adjunctions-4.3: download either-4.4.1.1: configure either-4.4.1.1: build adjunctions-4.3: configure adjunctions-4.3: build either-4.4.1.1: copy/register keys-3.11: download keys-3.11: configure keys-3.11: build adjunctions-4.3: copy/register kan-extensions-4.2.3: download kan-extensions-4.2.3: configure kan-extensions-4.2.3: build keys-3.11: copy/register optparse-simple-0.0.3: download optparse-simple-0.0.3: configure optparse-simple-0.0.3: build kan-extensions-4.2.3: copy/register optparse-simple-0.0.3: copy/register pointed-4.2.0.2: download pointed-4.2.0.2: configure pointed-4.2.0.2: build pointed-4.2.0.2: copy/register vector-instances-3.3.1: download vector-instances-3.3.1: configure vector-instances-3.3.1: build vector-instances-3.3.1: copy/register vector-algorithms-0.7.0.1: copy/register mono-traversable-0.10.2: download mono-traversable-0.10.2: configure mono-traversable-0.10.2: build aeson-1.0.2.1: copy/register http-conduit-2.2.3: download binary-tagged-0.1.4.1: download binary-tagged-0.1.4.1: configure aeson-compat-0.3.6: download binary-tagged-0.1.4.1: build http-conduit-2.2.3: configure http-conduit-2.2.3: build aeson-compat-0.3.6: configure aeson-compat-0.3.6: build http-conduit-2.2.3: copy/register aeson-compat-0.3.6: copy/register path-0.5.9: download path-0.5.9: configure persistent-2.6: download path-0.5.9: build persistent-2.6: configure binary-tagged-0.1.4.1: copy/register persistent-2.6: build yaml-0.8.20: download yaml-0.8.20: configure yaml-0.8.20: build path-0.5.9: copy/register path-io-1.1.0: download path-io-1.1.0: configure path-io-1.1.0: build path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.17.0: download hpack-0.17.0: configure hpack-0.17.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: download persistent-sqlite-2.6: download persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure persistent-sqlite-2.6: build hpack-0.17.0: copy/register mono-traversable-0.10.2: copy/register store-0.3: download store-0.3: configure store-0.3: build persistent-template-2.5.1.6: copy/register persistent-sqlite-2.6: copy/register store-0.3: copy/register stack-1.4.0: configure [1 of 1] Compiling Main ( /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/Setup.hs, /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.4.0... stack-1.4.0: build Preprocessing library stack-1.4.0... [ 1 of 124] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 124] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 124] Compiling Stack.Options.ScriptParser ( src/Stack/Options/ScriptParser.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Options/ScriptParser.o ) [ 4 of 124] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 5 of 124] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 6 of 124] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 7 of 124] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 8 of 124] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 9 of 124] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 10 of 124] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 11 of 124] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/ghc89392_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/ghc89392_0/libghc_68.dylib: malformed mach-o: load commands size (49264) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed all 185 actions. -- While building package stack-1.4.0 using: /private/var/folders/7z/sy01r6wd3mzclwj66h1t25zw0000gn/T/stack- upgrade68242/stack-1.4.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Wolfgangs-MacBook-Air:~ wolf$ }}} -- Comment: Can you check if this is still a problem in 8.0.2? We're getting ready to release 8.2.1; it's a bit late to be worrying about 7.10.3 issues. -- Ticket URL: GHC The Glasgow Haskell Compiler