From ghc-devs at haskell.org Sat Dec 1 06:25:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 06:25:32 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.42ba369a909bffca3c4a21e0c4328263@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 osa1): I think this is because `CorePrep` adds ticks in data con workers. Comments around the code: {{{ -- If we want to generate debug info, we put a source note on the -- worker. This is useful, especially for heap profiling. }}} Why do you think this is a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 07:26:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 07:26:20 -0000 Subject: [GHC] #4900: Consider usage files in the GHCi recompilation check In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.2a5625efa841529d92631f520f28a8ee@haskell.org> #4900: Consider usage files in the GHCi recompilation check -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: TH_Depends Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Wizek): * cc: Wizek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 09:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 09:39:27 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.5a9018369a74c260cf2f24cbe0892365@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.3 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 10:10:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 10:10:16 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.64c810bc628b824243cec7b3beeba183@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 AndreasK): It directly contradicts the info on the wiki: > It is important to realize that - in contrast to instrumentation - adding DWARF debug information does not change the code sections of the executable. In particular some expressions get turned into join points without -g, but are inlined without -g. This leads to different code being generated and ultimately also to different behaviour in regards to performance. It seems reasonably that it is caused by the adding of source notes you mentioned. But if source notes cause different inlining/join point behaviour I would still consider that a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 13:42:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 13:42:20 -0000 Subject: [GHC] #15951: Hadrian test doesn't show testsuite output by default In-Reply-To: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> References: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> Message-ID: <061.3f485e89df0084d60d8d022f67227997@haskell.org> #15951: Hadrian test doesn't show testsuite output by default -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 14:08:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 14:08:53 -0000 Subject: [GHC] #14655: Compiled nofib-analyse executable segfaults under windows In-Reply-To: <047.44633c0d8f4acc4718fac822df06754c@haskell.org> References: <047.44633c0d8f4acc4718fac822df06754c@haskell.org> Message-ID: <062.fff2df9503c31dff286e56706dc24053@haskell.org> #14655: Compiled nofib-analyse executable segfaults under windows -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 AndreasK): * version: 8.2.2 => 8.7 Comment: Still happens with GHC HEAD. Could also be unsafe code in nofib-analyse that causes this but I haven't checked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 14:34:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 14:34:26 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.bf04471e9349a8d35c804b50d0dbfdbc@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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): Phab:D5402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5402 Comment: Alright. If you're happy with the new output, then I am too. Phab:D5402 implements this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 14:39:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 14:39:46 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.a66dc41a0ad84a3ce8cbca837d4d4bf2@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): Is it just me, or does this Core Lint check seem entirely bogus? This seems to assume that the body of a `forall` will always be `*`-kinded, but that's just blatantly false (`forall (f :: Type -> Type). f` is another counterexample.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 15:31:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 15:31:09 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.fb90643591ee1e83748e9ed9f5f92850@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5381 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cbf57b7dbfdbfa72475d793b27858cacf2ed9816/ghc" cbf57b7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cbf57b7dbfdbfa72475d793b27858cacf2ed9816" hadrian/test: Don't depend upon iserv on Windows Iserv is not supported on Windows. This fixes #15950 but this whole situation feels awfully fragile to me. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 15:36:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 15:36:53 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.cd4bddbd0ec8011d1e44b66cf7b9d9a9@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ok, so I compiled and added in the line: {{{pprTrace "..." (text "litI:" <+> ppr litI <+> text "litE:" <+> ppr litE) $ pure ()}}} ... however that's in `MatchLit`, so doesn't get executed when typechecking, only when evaluating. Makes sense because if I typecheck, I still get the slow behaviour, but if I evaluate, I get that error (coz I still haven't updated the location of `mkRational` yet). So, this also seems correct, given I have made zero changes in the typechecker so far. So I'm looking in to that. I hope I'm on the right track. I ran it with `./inplace/bin/ghc-stage2 -e ":t 1e289" -ddump-parsed-ast` and it responded with something that ended with: {{{ ==================== Parser AST ==================== (Just ({ :1:1-5 } (BodyStmt (NoExt) ({ :1:1-5 } (HsOverLit (NoExt) (OverLit (NoExt) (HsFractional (FL (SourceText "1e289") (False) (1) (289) (Base10))) (HsLit (NoExt) (HsString (SourceText "noExpr") {FastString: "noExpr"}))))) (SyntaxExpr (HsLit (NoExt) (HsString (NoSourceText) {FastString: "noSyntaxExpr"})) [] (WpHole)) (SyntaxExpr (HsLit (NoExt) (HsString (NoSourceText) {FastString: "noSyntaxExpr"})) [] (WpHole))))) }}} And, seeing `HsOverLit` in this output, and looking at `tcExpr` in `compiler/typecheck/TcExpr.hs`, it seems to match the `HsOverLit` clause, which calls `newOverloadedLit` from `compiler/typechecker/Inst.hs`, which I'm not 100% sure, but it seems to be *not* matching on a short cut clause, and so applying `newNonTrivialOverloadedLit`. I'll take another pass at understanding it all again tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 15:47:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 15:47:02 -0000 Subject: [GHC] #8043: Feature Request : Qualified module exports In-Reply-To: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> References: <044.7e67fd67a3a24a755f819579ca8418d3@haskell.org> Message-ID: <059.a3a2c801622854d3a5f8f9dd05151134@haskell.org> #8043: Feature Request : Qualified module exports -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Wizek): * cc: Wizek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 18:20:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 18:20:18 -0000 Subject: [GHC] #15982: Hadrian's `--configure` flag is broken on Windows Message-ID: <050.1db3a576777b406081d2912367d7ba45@haskell.org> #15982: Hadrian's `--configure` flag is broken on Windows -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error: {{{ rm: cannot remove '.MTREE': No such file or directory }}} This is certainly caused by this line in `configure.ac`: https://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/configure.ac#L358 It's unclear what should be done in this case. Here is the command line I use to invoke Hadrian: {{{ hadrian\build --configure -j --flavour=quickest --integer-simple }}} When I run the configure script manually from the MinGW shell, it works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 18:33:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 18:33:43 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.a04157c000b16c0d93367ad10936404b@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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): Phab:D5402 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS. Here's an idea. In `check_syn_tc_app`, you could wrap the recursive call to `check_type` in `addErrCtxt "In the expansion of type synonym `. That would give us the best of both worlds, including for the trickier case I described in comment:5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 18:38:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 18:38:02 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.0f7ad6b5394d04d097f2d3fa6d6ca567@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 simonpj): No, the Lint check is right. The kinding rules for types are given in comment:4 of #15791. And, I assume, in `docs/core-spec`. So the bug is in the type checker which should reject the program. It's not easy to do that for type inference, because we lack a constraint that says "This kind should be either (TYPE r) or Constraint". I think the easiest way to fix this would be in `checkValidType`; and specifically in the code you have just been working on in `check_type`. In a sigma-type (the code you moved up) add a test that the kind of the body is `TYPE r` or `Constraint`. Richard, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 18:49:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 18:49:36 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.c55d6e022ce99d675d31d8f9d621cfe0@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): Uh... what? I must be living in a different reality, then, since GHC has always let me do this without complaint: {{{#!hs type Foo = forall (f :: Type -> Type). f }}} So either I'm taking crazy pills, or those kinding rules for types are blatantly wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 19:11:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 19:11:23 -0000 Subject: [GHC] #15982: Hadrian's `--configure` flag is broken on Windows In-Reply-To: <050.1db3a576777b406081d2912367d7ba45@haskell.org> References: <050.1db3a576777b406081d2912367d7ba45@haskell.org> Message-ID: <065.cfb4181615e81d970d3b7c9fa07fd338@haskell.org> #15982: Hadrian's `--configure` flag is broken on Windows -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Invoking Hadrian using the `build.cabal.bat` script seems to work fine too: {{{ hadrian\build.cabal.bat --configure -j --flavour=quickest --integer-simple }}} So this is somehow related to my Stack setup. Can anyone reproduce? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 19:39:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 19:39:39 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.bff7fd4609a96b35b10c617a1026c26d@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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): Phab:D5402 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 20:04:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 20:04:41 -0000 Subject: [GHC] #15956: Linker error building `runghc` In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.c0a5e2297291a8de056c25e102e8d6ba@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * owner: (none) => harpocrates Comment: I've got a fix for this coded up. Applied directly on top of 561748cb507505bd5b7bd76bdc57796d896b62a2, it works just fine. Unfortunately, I'm now running into another Hadrian issue which must've been introduced sometime between 561748cb507505bd5b7bd76bdc57796d896b62a2 and current master. Slowly bisecting... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 20:10:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 20:10:38 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.04154f4b23df8b504c8b70a5c281f1e4@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): some patches need to be merged in so that folks aside from me can continue building with gcc :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 20:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 20:29:15 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.2e27402c0620c5be1e5957a6b03553ea@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 simonpj): * cc: goldfire (added) Comment: Let's ask Richard, but I think it should never have accepted that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 21:47:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 21:47:20 -0000 Subject: [GHC] #15983: Built-in support for half-floats Message-ID: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> #15983: Built-in support for half-floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Half-floats (16-bit floating point values with 1-bit sign, 5-bits of exponent, and 10 bits of mantissa) are becoming more and more common in this new era of data-centric programming: Almost all GPUs have native support, and most CPU's are starting to support them natively in their instruction set. It would be great if GHC can lead the way and have half-floats as a natively supported data-type as well, just like Float and Double. I'm aware of Edward's http://hackage.haskell.org/package/half package; so that could be a starting point; though we'd eventually want GHC to generate native code. Note that LLVM does support half-floats, so a viable path can be using LLVM when available and software-FFI/implementation otherwise. Eventually the native code generator can add support as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 1 22:13:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Dec 2018 22:13:54 -0000 Subject: [GHC] #15984: Backpack accepts ill-kinded instantiations. Can cause GHC panic Message-ID: <049.deeb5b9e2e3119f31844049d97d3a4f8@haskell.org> #15984: Backpack accepts ill-kinded instantiations. Can cause GHC panic -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: backpack | 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: -------------------------------------+------------------------------------- Given the following: {{{#!hs {-# language KindSignatures #-} signature A where data A :: * }}} {{{#!hs module Foo where import A foo :: A -> A foo = id }}} {{{#!hs module IllKindedA where type A = Maybe }}} GHC allows the signature `A` to be instantiated with `IllKindedA`: {{{ mixins: foo (Foo as Bug) requires (A as IllKindedA) }}} Using the resulting module can cause odd errors or a panic. E.g. the following causes a panic: {{{#!hs module Bar where import Bug bar = foo }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): getRuntimeRep A :: * -> * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:2049:18 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 00:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 00:29:46 -0000 Subject: [GHC] #15985: `pprint EqualityT` infinitely loops Message-ID: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> #15985: `pprint EqualityT` infinitely loops -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was very surprised to discover that this program loops infinitely: {{{#!hs module Main where import Language.Haskell.TH main :: IO () main = print $ pprint EqualityT }}} Let's not do that. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 00:35:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 00:35:01 -0000 Subject: [GHC] #15985: `pprint EqualityT` infinitely loops In-Reply-To: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> References: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> Message-ID: <065.c20562dcd9d5d1a3f96df60907b15ae8@haskell.org> #15985: `pprint EqualityT` infinitely loops -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.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:D5403 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5403 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 00:44:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 00:44:57 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.a5416d96882233a018aefe1e73c3e651@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I'm working on this. > Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched. Just to clarify, they are produced by this build rule: https://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/hadrian/src/Rules/Gmp.hs#L50-L67 Note that we do not know all GMP object files statically, before the build, and therefore cannot tell Shake which files we expect to produce as the result of running this rule. I'm not entirely clear about how this causes the lint failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 00:48:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 00:48:26 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.45568c7a219d2ecf229565a26a3b0811@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: NeilMitchell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 02:10:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 02:10:32 -0000 Subject: [GHC] #15984: Backpack accepts ill-kinded instantiations. Can cause GHC panic In-Reply-To: <049.deeb5b9e2e3119f31844049d97d3a4f8@haskell.org> References: <049.deeb5b9e2e3119f31844049d97d3a4f8@haskell.org> Message-ID: <064.f357d29ba90986645ecb64b5edb08906@haskell.org> #15984: Backpack accepts ill-kinded instantiations. Can cause GHC panic -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: backpack 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: | -------------------------------------+------------------------------------- Old description: > Given the following: > > {{{#!hs > {-# language KindSignatures #-} > signature A where > > data A :: * > }}} > > {{{#!hs > module Foo where > > import A > > foo :: A -> A > foo = id > }}} > > {{{#!hs > module IllKindedA where > > type A = Maybe > }}} > > GHC allows the signature `A` to be instantiated with `IllKindedA`: > > {{{ > mixins: foo (Foo as Bug) requires (A as IllKindedA) > }}} > > Using the resulting module can cause odd errors or a panic. E.g. the > following causes a panic: > > {{{#!hs > module Bar where > > import Bug > > bar = foo > }}} > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.2 for x86_64-unknown-linux): > getRuntimeRep > A :: * -> * > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/types/Type.hs:2049:18 in ghc:Type > }}} New description: Given the following: {{{#!hs {-# language KindSignatures #-} signature A where data A :: * }}} {{{#!hs module Foo where import A foo :: A -> A foo = id }}} {{{#!hs module IllKindedA where type A = Maybe }}} GHC allows the signature `A` to be instantiated with `IllKindedA`: {{{ mixins: foo (Foo as Bug) requires (A as IllKindedA) }}} Using the resulting module can cause odd errors or a panic. E.g. the following causes a panic: {{{#!hs module Bar where import Bug bar = foo }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): getRuntimeRep A :: * -> * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:2049:18 in ghc:Type }}} -- Comment (by aaronvargo): Oops, it seems this only happened because I foolishly had `IllKindedA` in the same library as `A`: {{{ library foo build-depends: base signatures: A exposed-modules: Foo, IllKindedA library bar build-depends: base, foo exposed-modules: Bar mixins: foo (Foo as Bug) requires (A as IllKindedA) }}} It's still a bug though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 06:41:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 06:41:21 -0000 Subject: [GHC] #4900: Consider usage files in the GHCi recompilation check In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.f22f565dd130230f72b51467bfdcbb57@haskell.org> #4900: Consider usage files in the GHCi recompilation check -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: TH_Depends Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Wizek): I'm also interested in this. Here is my current use-case detailed: https://stackoverflow.com/questions/53569080/how-to-most-easily-break-up-a -large-haskell-file-with-lots-of-imports-many-qual -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 08:21:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 08:21:43 -0000 Subject: [GHC] #15937: CI strategy for Gitlab In-Reply-To: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> References: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> Message-ID: <063.061826c710f0681f17db496ab1fbfd78@haskell.org> #15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): https://gitlab.staging.haskell.org/alp/ghc/-/jobs/578 shows that I managed to get a Circle CI job to run smoothly from my fork of the GHC repository on the gitlab instance. No project-specific settings, nothing. I deployed the necessary changes to the infrastructure. All that is left to do is to push https://gitlab.staging.haskell.org/alp/ghc/commit/6f73d339d810604f053d49b1d040fe6aaa3a8b7f to master, AFAICT. I will make that happen and will then close this ticket once this lands on master and is confirmed to work properly for everyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 13:26:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 13:26:12 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.f64a9be90fea6f6297e3f6cd6e5189ff@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): This lint file means you created the files, as dependencies, then something went round and did a touch on them. Having a point of creation is fine, but what's doing the touch? If you don't know their names, how do they get into a list of .o files? Where is that rule? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 16:08:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 16:08:23 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.fdcb618000f5851934cfd5831f416fe0@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > If you don't know their names, how do they get into a list of .o files? Where is that rule? We unpack an archive which contains these `.o` files, here is the command that does this: {{{ build $ target gmpContext (Ar Unpack Stage1) [top -/- gmpPath -/- gmpLibrary] [gmpPath -/- gmpObjectsDir] }}} https://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/hadrian/src/Rules/Gmp.hs#L64-L65 > Having a point of creation is fine, but what's doing the touch? Right now the only place we ever refer to these `.o` files again is here: {{{ gmpPath <- gmpBuildPath need [gmpPath -/- gmpLibraryH] map unifyPath <$> getDirectoryFiles "" [gmpPath -/- gmpObjectsDir -/- "*.o"] }}} https://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/hadrian/src/Rules/Library.hs#L105-L107 Note that `need [gmpPath -/- gmpLibraryH]` records the dependency on the above rule. I initially thought that the reason for the lint failure is that we're using `getDirectoryFiles` instead of `getDirectoryFilesIO`, but we get the same lint error when using the untracked version too. As far as I can see, we never touch or refer to these `.o` files anywhere else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 16:18:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 16:18:15 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.4352aaede7d106109ff67ed2d0dd4b68@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Presumably you {{{need}}} the output of {{{extraObjects}}} at some point? When you do that it records their modification times. The {{{--lint}}} flag causes it to check the modification time at the end, and it spots it is different. Could the insertion into the archive be somehow modifying these files? Do you extract them twice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 16:23:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 16:23:39 -0000 Subject: [GHC] #15986: Poor error message source location reporting with unsaturated type family Message-ID: <050.2e30a951b81def4215389a22cebfd8df@haskell.org> #15986: Poor error message source location reporting with unsaturated type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeErrors | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where newtype WrapChar f = MkWrapChar (f Char) type family F a type family T a type instance T Int = WrapChar F }}} Then you'll get this error message: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:15: error: • The type family ‘F’ should have 1 argument, but has been given none • In the type instance declaration for ‘T’ | 7 | type instance T Int = WrapChar F | ^ }}} The thing is, the location of that caret is rather unfocused. It's pointing at `T`, but the real culprit is `F`! I know that GHC can do better here because other error messages actually get this right. For instance, if you change the `T Int` instance to this: {{{#!hs type instance T Int = F }}} Then GHC will actually point to `F` in the resulting error message: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:23: error: • Expecting one more argument to ‘F’ Expected a type, but ‘F’ has kind ‘* -> *’ • In the type ‘F’ In the type instance declaration for ‘T’ | 7 | type instance T Int = F | ^ }}} If GHC can point to the right place in the source code in this situation, then it ought to get the earlier situation right as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 16:40:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 16:40:53 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.3518d5aba74fb9be985ebf873000461a@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Presumably you `need` the output of `extraObjects` at some point? Ah, yes, we do `need` them in a few places, e.g. in `buildStaticLib`: {{{ objs <- libraryObjects context -- this includes 'extraObjects' removeFile archivePath build $ target context (Ar Pack stage) objs [archivePath] }}} > Could the insertion into the archive be somehow modifying these files? Do you extract them twice? No, we extract GMP object files only once. I'll try to model this situation in a small standalone example to make sense of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 18:25:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 18:25:54 -0000 Subject: [GHC] #15987: GHC sometimes not computing open type family application in kind inference Message-ID: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> #15987: GHC sometimes not computing open type family application in kind inference -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 writing code for type-level lenses, I've run into an issue with kind inference. I've boiled it down to the following oddity: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind(Type) type family FooKind (a :: Type) :: k class Foo (a :: Type) where type FooType a :: FooKind a -- OK type instance FooKind Bool = Type instance Foo Bool where type FooType Bool = Int -- not OK data A type instance FooKind A = Type instance Foo A where type FooType A = Int }}} This produces the following error: • Expected kind ‘FooKind A’, but ‘Int’ has kind ‘Type’ • In the type ‘Int’ In the type instance declaration for ‘FooType’ In the instance declaration for ‘Foo A’ I thought it might be related to the type family FooKind being polymorphic in its return kind, but changing the return kind to 'Type' does not affect this. \\ Changing "FooKind" to be a closed type family fixes this problem. \\ \\ \\ For the context in which this came up, I was writing type-level optics of which one can take the product (with disjointness guaranteed at the type level with type families). Then I needed a type family that chooses which product to use. For instance I have kind annotations: {{{#!hs ( (Index 0 :: Optic (V Int 3) Int) :*: (Index 2 :: Optic (V Int 3) Int) ) :: Optic (V Int 3) (V Int 2) ) type Fields = '[ '("a", Int), '("b", Bool), '("c", Float) ] ( (Name "a" :: Optic (Struct Fields) Int :*: (Name "c" :: Optic (Struct Fields) Float ) :: Optic Fields '[ '("a", Int), '("c", Float) ] }}} The type family :*: thus needs to figure out which product structure to use... in the first case I need to use V Int :: Nat -> Type, and in the second Struct :: [(Symbol,Type)] -> Type. \\ I wanted to use open type families for extensibility of which cartesian structure to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 18:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 18:28:57 -0000 Subject: [GHC] #15987: GHC sometimes not computing open type family application in kind inference In-Reply-To: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> References: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> Message-ID: <059.a4108cd6f2f10d781919152bdd346743@haskell.org> #15987: GHC sometimes not computing open type family application in kind inference -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 19:16:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 19:16:50 -0000 Subject: [GHC] #15956: Linker error building `runghc` In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.688d273c3863445018a80507c924a429@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5404 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:09:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:09:45 -0000 Subject: [GHC] #14451: Need proper SCC analysis of type declarations, taking account of CUSKs In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.675c68f8e673778524255bfaeed5e057@haskell.org> #14451: Need proper SCC analysis of type declarations, taking account of CUSKs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7503 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by RyanGlScott): Amazingly, the original program in this ticket (including the `Comp f g a = f · (g · a)` tweak): {{{#!hs {-# Language KindSignatures, TypeOperators, PolyKinds, TypeOperators, ConstraintKinds, TypeFamilies, DataKinds, TypeInType, GADTs, AllowAmbiguousTypes, InstanceSigs, RankNTypes, UndecidableInstances #-} import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type type Cat ob = ob -> ob -> Type type family Apply (f :: a ~> b) (x :: a) :: b where Apply (CompSym2 f g) a = Comp f g a data CompSym2 :: (b ~> c) -> (a ~> b) -> (a ~> c) type a·b = Apply a b class Varpi (f :: i ~> j) where type Dom (f :: i ~> j) :: Cat i type Cod (f :: i ~> j) :: Cat j varpa :: Dom f a a' -> Cod f (f·a) (f·a') type family Comp (f::k1 ~> k) (g::k2 ~> k1) (a::k2) :: k where Comp f g a = f · (g · a) }}} Appears to have fixed itself at some point between GHC 8.4 and 8.6, since it typechecks on GHC 8.6.2 and HEAD. I'm not sure what commit caused that, but that's cool nonetheless. Let me check to see if the same miracle happened to #7503. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:13:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:13:04 -0000 Subject: [GHC] #15988: Remove Text.Printf and System.Console.GetOpt from base Message-ID: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> #15988: Remove Text.Printf and System.Console.GetOpt from base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This was touched on in brief in a recent mailing list thread found at https://mail.haskell.org/pipermail/libraries/2018-October/029012.html. I propose removing `Text.Printf` and `System.Console.GetOpt` from `base` and moving them into their own packages named `printf` and `getopt` that would be managed by the haskell github organization. These two libraries, when built against newer versions of base, would provide the modules. When built against old versions of base, they would simply reexport the modules. There would be breakage from doing this, but libraries and applications that use these APIs would only need to add a single line to `build-depends` to continue being compatible with all versions of `base`. The benefits of doing this are small. As a matter of principle, it seems unfair that these two APIs are blessed by being a part of base when the would likely struggle to compete if they were in ordinary libraries. In particular, `printf` is less idiomatic and performs worse that the functions from `Numeric` (like `showFFloat`), but its prominent position in `base` encourages users to overlook the more type-safe options available for formatting numbers. More practically, the size of base does occassionally cause problems. In https://github.com/haskell/primitive/issues/218#issuecomment-443534850, Carter writes > base getting bigger actually hurts folk, eg, base recently got big enough that dwarf data gnerated by ghc at -g1 is now sooo much that you can't do a dwarf annotated build of base on mac OS X! anymore Moving these APIs out of `base` makes a small step toward addressing this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:14:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:14:06 -0000 Subject: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs In-Reply-To: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> References: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> Message-ID: <068.dd4fc9e8806188a9d76f6a0ebf1a7e13@haskell.org> #7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by RyanGlScott): Continuing my journey started in https://ghc.haskell.org/trac/ghc/ticket/14451#comment:7, it appears that something changed between GHC 8.4 and 8.6 that affects the programs in this ticket. Amazingly, the original program: {{{#!hs {-# LANGUAGE ExistentialQuantification, DataKinds, PolyKinds, KindSignatures, GADTs #-} module TestConstraintKinds where import GHC.Exts hiding (Any) data WrappedType = forall a. WrapType a data A :: WrappedType -> * where MkA :: forall (a :: *). AW a -> A (WrapType a) type AW (a :: k) = A (WrapType a) type AW' (a :: k) = A (WrapType a) class C (a :: k) where aw :: AW a -- workaround: AW' instance C [] where aw = aw }}} Now typechecks with GHC 8.6.2 and HEAD! Unfortunately, it might be too early to declare victory here, since the program in comment:1: {{{#!hs {-# LANGUAGE ExistentialQuantification, DataKinds, PolyKinds, KindSignatures, GADTs #-} module TestConstraintKinds where data Wrap a -- Wrap :: forall k. k -> * data A a = MkA a (AW a) type AW a = A (Wrap a) type AW2 a = A (Wrap a) class C (a :: k) where aw :: AW a }}} Still refuses to typecheck, even on GHC 8.6.2 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:22:35 -0000 Subject: [GHC] #15777: Ordering of code in file affects compilation In-Reply-To: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> References: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> Message-ID: <061.976ec2ad6b2d44a0f4ae13887ce73991@haskell.org> #15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): One other trick worth noting (that I learned recently from #15561) is that open and closed type families behave differently in SCC analysis, so turning `Rep` into a closed type family actually makes this typecheck. That is to say, the following compiles: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} -- | Conversion between unlifted and lifted datatypes module Packed.Levity ( -- * Types Rep , Levity(..) ) where import Data.Kind (Type) import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) import GHC.Exts (Int#, Word#, ByteArray#) class Levity (a :: Type) where type Unlifted a :: TYPE (Rep a) box :: Unlifted a -> a unbox :: a -> Unlifted a instance Levity Int where type Unlifted Int = Int# box = I# unbox (I# i) = i instance Levity Word where type Unlifted Word = Word# box = W# unbox (W# w) = w instance Levity Stuff where type Unlifted Stuff = Stuff# box = stuff# unbox = unStuff# type family Rep (a :: Type) :: RuntimeRep where Rep Int = IntRep Rep Word = WordRep Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] type Stuff# = (# Int#, Int# #) data Stuff = Stuff Int# Int# stuff# :: (# Int#, Int# #) -> Stuff stuff# (# x, y #) = Stuff x y unStuff# :: Stuff -> (# Int#, Int# #) unStuff# (Stuff x y) = (# x, y #) }}} You may not be able to get away with making `Rep` a closed type family in the actual program that you're writing, but I thought I'd point it out nonetheless, since I was myself unaware of this fact until today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:27:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:27:42 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types In-Reply-To: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> References: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> Message-ID: <061.e41933efc2d846a62794fb5bf3f48df5@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think commit 2257a86daa72db382eb927df12a718669d5491f8 (`Taming the Kind Inference Monster`) fixed this ticket, since the following now compiles after that commit: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where data Proxy k (a :: k) = MkProxy data Proxy2 k a = MkP (Proxy k a) data Proxy2' k a where MkP' :: Proxy k a -> Proxy2' k a data T a where T :: Int -> T Bool type family F a where F Int = True F _ = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:40:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:40:05 -0000 Subject: [GHC] #14668: Ordering of declarations can cause typechecking to fail In-Reply-To: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> References: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> Message-ID: <065.1f44af106fe0267058471bd9fc9e46a9@haskell.org> #14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12088, #12643, | Differential Rev(s): #15561 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12088, #12643, #15561 Comment: This is almost surely a duplicate of #12088 (see also #12643 and #15561, which are other surely-duplicates of #12088). Here are two tricks to making these sorts of programs compile: 1. `TemplateHaskell`. Using an empty Template Haskell splice can often force GHC's SCC analysis to come to its senses and do the right thing. As an example, the following variations of danilo2's program in comment:4 compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Type.Data.Map where import Prelude import Data.Kind type family KeyKind (obj :: Type) :: Type type family ValKind (obj :: Type) :: Type type family Get (key :: KeyKind a) (obj :: a) :: ValKind a data Map (k :: Type) (v :: Type) = Map [(k,v)] type instance KeyKind (Map k v) = k type instance ValKind (Map k v) = v $(pure []) type instance Get k ('Map ('(k,v) ': _)) = v }}} 2. Closed type families. As I discovered recently in #15561, open and closed type families behave differently in SCC analysis, so it turns out that turning `ValKind` into a closed type family makes danilo2's program compile as well: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Type.Data.Map where import Prelude import Data.Kind type family KeyKind (obj :: Type) :: Type type family ValKind (obj :: Type) :: Type where ValKind (Map k v) = v type family Get (key :: KeyKind a) (obj :: a) :: ValKind a data Map (k :: Type) (v :: Type) = Map [(k,v)] type instance Get k ('Map ('(k,v) ': _)) = v type instance KeyKind (Map k v) = k }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:42:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:42:17 -0000 Subject: [GHC] #14668: Ordering of declarations can cause typechecking to fail In-Reply-To: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> References: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> Message-ID: <065.662aa2a7c231f6645612fc7d34f72228@haskell.org> #14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12088, #12643, | Differential Rev(s): #15561, #15987 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #12088, #12643, #15561 => #12088, #12643, #15561, #15987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:46:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:46:37 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.21089c6d29c4228a33c4fa8f73f19f93@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790, #14668, #15561, | #15777, #15987 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11348, #12239, #12643, #13790, #15561, #15777 => #11348, #12239, #12643, #13790, #14668, #15561, #15777, #15987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:48:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:48:25 -0000 Subject: [GHC] #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions In-Reply-To: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> References: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> Message-ID: <059.a865c82029c2b0b31b0559b57245d10b@haskell.org> #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies, GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088, #12643, | Differential Rev(s): #14668, #15987 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12088, #12643, #14668, #15987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:49:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:49:24 -0000 Subject: [GHC] #12643: class declaration works in ghci, but not in a file In-Reply-To: <044.c716074b77b054579b7d856a68677406@haskell.org> References: <044.c716074b77b054579b7d856a68677406@haskell.org> Message-ID: <059.1236bb05b8228cbdc2c1ac4a2eb291c9@haskell.org> #12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | 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: #12088, #14668, | Differential Rev(s): #15561, #15987 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12088, #14668, #15561, #15987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:56:57 -0000 Subject: [GHC] #15987: GHC sometimes not computing open type family application in kind inference In-Reply-To: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> References: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> Message-ID: <059.8e20807b9bec061bb5d2bc5f7ea04e11@haskell.org> #15987: GHC sometimes not computing open type family application in kind inference -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088, #12643, | Differential Rev(s): #14668, #15561 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12088, #12643, #14668, #15561 Comment: Thanks for the bug report. This is essentially a duplicate of #12088, which a long-standing issue in the way that groups of type-level declarations are kind-checked. #12088 itself has many other duplicates—last time I checked, these other tickets are also essentially duplicates of #12008: * #12643 * #14668 * #15561 One thing I did not realize before this ticket is that GHC's SCC analysis treats open and closed type families differently—thanks for that bit of knowledge! Another trick (that you may find useful) is that Template Haskell splices can often force the SCC analysis to come to its senses. For example, this variation on your program also compiles: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind(Type) type family FooKind (a :: Type) :: k class Foo (a :: Type) where type FooType a :: FooKind a -- OK type instance FooKind Bool = Type instance Foo Bool where type FooType Bool = Int -- OK data A type instance FooKind A = Type $(pure []) instance Foo A where type FooType A = Int }}} It's a bit ugly, but it's a serviceable hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 20:59:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 20:59:46 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.727eba7aed3418011d119e9c8dc1e3dc@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790, #14668, #15561, | #15777, #15987 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking,| https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * wikipage: https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking => https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking, https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 21:05:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 21:05:17 -0000 Subject: [GHC] #15987: GHC sometimes not computing open type family application in kind inference In-Reply-To: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> References: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> Message-ID: <059.f7fc591657d5da1c32c27937d2067e80@haskell.org> #15987: GHC sometimes not computing open type family application in kind inference -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088, #12643, | Differential Rev(s): #14668, #15561 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): Thank you very much for that information Ryan. I can confirm that the Template Haskell hack has saved my biscuit. Sorry about the duplicate! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 21:07:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 21:07:56 -0000 Subject: [GHC] #15987: GHC sometimes not computing open type family application in kind inference In-Reply-To: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> References: <044.bbc1837ac298b5ac812cfa920b36ca27@haskell.org> Message-ID: <059.366cefc4c78ac40292995a2d3d998fe7@haskell.org> #15987: GHC sometimes not computing open type family application in kind inference -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088, #12643, | Differential Rev(s): #14668, #15561 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: No worries. To avoid having so many of these sorts of tickets floating around on Trac, I think I'll opt to close this one. If we do ever figure out a solution to #12088, though, we should make sure to add the program from this ticket as a test case, however. (I've added this ticket under the "related" field of #12088 to ensure that's more likely to happen.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 21:09:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 21:09:11 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.520aecb9bae92e6bb2c8685d9fc2f4e6@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790, #14668, #15561, | #15777, #15987 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking,| https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by sheaf): * cc: sheaf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 21:22:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 21:22:33 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.2eb04a66d98e614493fba8b0f4e5de7f@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: TDecki Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14037 | Differential Rev(s): Phab:D5241 Wiki Page: | -------------------------------------+------------------------------------- Changes (by TDecki): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 22:54:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 22:54:13 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure Message-ID: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} import Control.Monad.Reader data T x = T { anX :: x, anInt :: Int } ok :: ( forall x x'. MonadReader (T x) (m x') ) => m y Bool ok = fmap not (pure True) bad :: ( forall x x'. MonadReader (T x) (m x') , forall x. Monad (m x) ) => m y Bool bad = fmap not (pure True) better :: ( forall x x'. MonadReader (T x) (m x') , forall x. Applicative (m x) , forall x. Functor (m x) ) => m y Bool better = fmap not (pure True) }}} `ok` and `better` compile, but `bad` fail to resolve, despite having strictly more in the context than `ok`: {{{ BadQC.hs:15:7: error: • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^^^^^^^^^^^^ BadQC.hs:15:17: error: • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the second argument of ‘fmap’, namely ‘(pure True)’ In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^ Failed, no modules loaded. }}} Also: * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles — the error seems to require two quantified type variables * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an ambiguity error on the constraint, which makes sense; if I turn on `AllowAmbiguousTypes`, it fails with the same error as above — the error isn't caused by MPTCs, and it doesn't matter that `x'` is unused * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the same class hierarchy matters * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on `fmap` (but not `pure`) — which is the superclass doesn't seem to matter -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 22:57:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 22:57:25 -0000 Subject: [GHC] #15986: Poor error message source location reporting with unsaturated type family In-Reply-To: <050.2e30a951b81def4215389a22cebfd8df@haskell.org> References: <050.2e30a951b81def4215389a22cebfd8df@haskell.org> Message-ID: <065.20cb9abf478c6a13af0c7b02b84c185b@haskell.org> #15986: Poor error message source location reporting with unsaturated type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies, | TypeErrors 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 RyanGlScott): Now that I think about this some more, I'm less confident in my declaration that "I know GHC can do better here". That's because the two error messages that I pointed out in the original comments actually come from two entirely different compilation passes. The latter error message (`Expecting one more argument to ‘F’`) arises during typechecking, which works over source code—that is, where everything has a `SrcSpan` attached. The former error message (`The type family ‘F’ should have 1 argument`), however, arises //after// typechecking (during some //post hoc// validity checks in `TcValidity`) when we only have `Type`s floating around. The problem is that `Type`s don't have `SrcSpan`s attached to all of their subcomponents like `HsType GhcRn`s do, so it's harder to tell where to report errors during validity checking. Perhaps this is a sign that this bug can't reasonably be fixed until #15479 is implemented (i.e., when typechecking returns `HsType GhcTc` instead of `Type`). Unless someone can see a better path forward here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 22:59:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 22:59:49 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure In-Reply-To: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> References: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> Message-ID: <058.486b749c0e7746ad33d4dde4821d1d5a@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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 eror): * `( forall x x'. Monad (m x), forall x. Traversable (m x) )` and `( forall x x'. Traversable (m x), forall x. Monad (m x) )` both fail on `fmap` but not `pure`, which makes it look like the problem is in resolving classes that are superclasses of more than one of the constraints. * Using two type variables in both constraints compiles; it looks like the problem arises when the number of quantified type variables is different. But `( forall x. Monad (m x), Monad m y )` compiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 2 23:02:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Dec 2018 23:02:36 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure In-Reply-To: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> References: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> Message-ID: <058.f23e7836e841e69663510be56c862d4a@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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 eror): (Why do I want to use a constraint like this in the first place? I discovered this while trying to write something like {{{ ( forall x x'. x ~ x' => MonadReader (Env x) (m x') , forall x. MonadWriter Log (m x) ) }}} where the two type variables and equality constraint are there to work around #15351.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 00:57:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 00:57:49 -0000 Subject: [GHC] #14298: Let Template Haskell dynamically add something with which to link In-Reply-To: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> References: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> Message-ID: <065.f4415197fd964630056116a2c98ce556@haskell.org> #14298: Let Template Haskell dynamically add something with which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.2.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:D4064 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 02:39:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 02:39:52 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure In-Reply-To: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> References: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> Message-ID: <058.a04bebd24ec69aa8169b1832c112f259@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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: | -------------------------------------+------------------------------------- Description changed by eror: Old description: > {{{ > {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} > > import Control.Monad.Reader > > data T x = T { anX :: x, anInt :: Int } > > ok :: ( forall x x'. MonadReader (T x) (m x') ) > => m y Bool > ok = fmap not (pure True) > > bad :: ( forall x x'. MonadReader (T x) (m x') > , forall x. Monad (m x) ) > => m y Bool > bad = fmap not (pure True) > > better :: ( forall x x'. MonadReader (T x) (m x') > , forall x. Applicative (m x) > , forall x. Functor (m x) ) > => m y Bool > better = fmap not (pure True) > }}} > > `ok` and `better` compile, but `bad` fail to resolve, despite having > strictly more in the context than `ok`: > > {{{ > BadQC.hs:15:7: error: > • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ > from the context: (forall x x'. MonadReader (T x) (m x'), > forall x. Monad (m x)) > bound by the type signature for: > bad :: forall (m :: * -> * -> *) y. > (forall x x'. MonadReader (T x) (m x'), forall > x. Monad (m x)) => > m y Bool > at BadQC.hs:(12,1)-(14,15) > • In the expression: fmap not (pure True) > In an equation for ‘bad’: bad = fmap not (pure True) > | > 15 | bad = fmap not (pure True) > | ^^^^^^^^^^^^^^^^^^^^ > > BadQC.hs:15:17: error: > • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ > from the context: (forall x x'. MonadReader (T x) (m x'), > forall x. Monad (m x)) > bound by the type signature for: > bad :: forall (m :: * -> * -> *) y. > (forall x x'. MonadReader (T x) (m x'), forall > x. Monad (m x)) => > m y Bool > at BadQC.hs:(12,1)-(14,15) > • In the second argument of ‘fmap’, namely ‘(pure True)’ > In the expression: fmap not (pure True) > In an equation for ‘bad’: bad = fmap not (pure True) > | > 15 | bad = fmap not (pure True) > | ^^^^^^^^^ > Failed, no modules loaded. > }}} > > Also: > > * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles > — the error seems to require two quantified type variables > * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an > ambiguity error on the constraint, which makes sense; if I turn on > `AllowAmbiguousTypes`, it fails with the same error as above — the error > isn't caused by MPTCs, and it doesn't matter that `x'` is unused > * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall > x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the > same class hierarchy matters > * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on > `fmap` (but not `pure`) — which is the superclass doesn't seem to matter New description: {{{ {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} import Control.Monad.Reader data T x = T ok :: ( forall x x'. MonadReader (T x) (m x') ) => m y Bool ok = fmap not (pure True) bad :: ( forall x x'. MonadReader (T x) (m x') , forall x. Monad (m x) ) => m y Bool bad = fmap not (pure True) better :: ( forall x x'. MonadReader (T x) (m x') , forall x. Applicative (m x) , forall x. Functor (m x) ) => m y Bool better = fmap not (pure True) }}} `ok` and `better` compile, but `bad` fail to resolve, despite having strictly more in the context than `ok`: {{{ BadQC.hs:15:7: error: • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^^^^^^^^^^^^ BadQC.hs:15:17: error: • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the second argument of ‘fmap’, namely ‘(pure True)’ In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^ Failed, no modules loaded. }}} Also: * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles — the error seems to require two quantified type variables * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an ambiguity error on the constraint, which makes sense; if I turn on `AllowAmbiguousTypes`, it fails with the same error as above — the error isn't caused by MPTCs, and it doesn't matter that `x'` is unused * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the same class hierarchy matters * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on `fmap` (but not `pure`) — which is the superclass doesn't seem to matter -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 02:40:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 02:40:14 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure In-Reply-To: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> References: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> Message-ID: <058.ad9a428c2f670a3a6911819106f299a6@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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: | -------------------------------------+------------------------------------- Description changed by eror: Old description: > {{{ > {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} > > import Control.Monad.Reader > > data T x = T > > ok :: ( forall x x'. MonadReader (T x) (m x') ) > => m y Bool > ok = fmap not (pure True) > > bad :: ( forall x x'. MonadReader (T x) (m x') > , forall x. Monad (m x) ) > => m y Bool > bad = fmap not (pure True) > > better :: ( forall x x'. MonadReader (T x) (m x') > , forall x. Applicative (m x) > , forall x. Functor (m x) ) > => m y Bool > better = fmap not (pure True) > }}} > > `ok` and `better` compile, but `bad` fail to resolve, despite having > strictly more in the context than `ok`: > > {{{ > BadQC.hs:15:7: error: > • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ > from the context: (forall x x'. MonadReader (T x) (m x'), > forall x. Monad (m x)) > bound by the type signature for: > bad :: forall (m :: * -> * -> *) y. > (forall x x'. MonadReader (T x) (m x'), forall > x. Monad (m x)) => > m y Bool > at BadQC.hs:(12,1)-(14,15) > • In the expression: fmap not (pure True) > In an equation for ‘bad’: bad = fmap not (pure True) > | > 15 | bad = fmap not (pure True) > | ^^^^^^^^^^^^^^^^^^^^ > > BadQC.hs:15:17: error: > • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ > from the context: (forall x x'. MonadReader (T x) (m x'), > forall x. Monad (m x)) > bound by the type signature for: > bad :: forall (m :: * -> * -> *) y. > (forall x x'. MonadReader (T x) (m x'), forall > x. Monad (m x)) => > m y Bool > at BadQC.hs:(12,1)-(14,15) > • In the second argument of ‘fmap’, namely ‘(pure True)’ > In the expression: fmap not (pure True) > In an equation for ‘bad’: bad = fmap not (pure True) > | > 15 | bad = fmap not (pure True) > | ^^^^^^^^^ > Failed, no modules loaded. > }}} > > Also: > > * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles > — the error seems to require two quantified type variables > * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an > ambiguity error on the constraint, which makes sense; if I turn on > `AllowAmbiguousTypes`, it fails with the same error as above — the error > isn't caused by MPTCs, and it doesn't matter that `x'` is unused > * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall > x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the > same class hierarchy matters > * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on > `fmap` (but not `pure`) — which is the superclass doesn't seem to matter New description: {{{ {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} import Control.Monad.Reader data T x = T ok :: ( forall x x'. MonadReader (T x) (m x') ) => m y Bool ok = fmap not (pure True) bad :: ( forall x x'. MonadReader (T x) (m x') , forall x. Monad (m x) ) => m y Bool bad = fmap not (pure True) better :: ( forall x x'. MonadReader (T x) (m x') , forall x. Applicative (m x) , forall x. Functor (m x) ) => m y Bool better = fmap not (pure True) }}} `ok` and `better` compile, but `bad` fails to resolve, despite having strictly more in the context than `ok`: {{{ BadQC.hs:15:7: error: • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^^^^^^^^^^^^ BadQC.hs:15:17: error: • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the second argument of ‘fmap’, namely ‘(pure True)’ In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^ Failed, no modules loaded. }}} Also: * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles — the error seems to require two quantified type variables * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an ambiguity error on the constraint, which makes sense; if I turn on `AllowAmbiguousTypes`, it fails with the same error as above — the error isn't caused by MPTCs, and it doesn't matter that `x'` is unused * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the same class hierarchy matters * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on `fmap` (but not `pure`) — which is the superclass doesn't seem to matter -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 03:34:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 03:34:29 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS Message-ID: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since 79d5427e1f9de02c0b171bf5db46b6b49c6f85e3 (which add support for dynamically linking GHC), the default `./hadrian/build.sh` is broken for MacOS. In particular, the `ghc` built always crashes with a "Symbol not found" error. Example: {{{ $ ./hadrian/build.sh -j -c # << fails shortly after building first ghc >> $ _build/stage1/bin/ghc dyld: Symbol not found: _ffi_type_double Referenced from: _build/stage1/lib/../lib/x86_64-osx- ghc-8.7.20181202/libHSghci-8.7-ghc8.7.20181202.dylib Expected in: flat namespace in _build/stage1/lib/../lib/x86_64-osx- ghc-8.7.20181202/libHSghci-8.7-ghc8.7.20181202.dylib [1] 52701 abort _build/stage1/bin/ghc }}} See https://phabricator.haskell.org/rGHC79d5427e1f9de02c0b171bf5db46b6b49c6f85e3 for more discussion. The core of the issue seems to be that `-Wl,-dead_strip_dylibs` accidentally strips some essential libraries (`libffi` is one of these). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 03:48:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 03:48:18 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure In-Reply-To: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> References: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> Message-ID: <058.25501a58ab7b7dcfa834cc61a2281632@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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 eror): This looks to me like the fix to #15244 not properly generalizing to constraints with different `forall`s that actually mean the same thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 06:27:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 06:27:52 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.4d0e77c1cf132b1f0193433cfa35cf35@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I almost finished the analysis implementation (I don't update the .hi file or ModIface yet). I currently have a sanity check that after analysis compares CafInfos computed by TidyPgm with the CafInfos the new analysis computes, and I can see cases when building stage 2 where the results differ. For example, for this definition: (libraries/base/GHC/Base.hs) {{{ GHC.Base.$fFunctor-> [InlPrag=NOUSERINLINE CONLIKE] :: forall r. GHC.Base.Functor ((->) r) [GblId[DFunId], Str=m] = CCS_DONT_CARE GHC.Base.C:Functor! [GHC.Base.. GHC.Base.$fFunctor->_$c<$]; }}} This definition itself is not a CAF, so we look at the free variables `GHC.Base.$fFunctor->_$c<$` and `GHC.Base..`: {{{ GHC.Base.. [InlPrag=INLINE (sat-args=2)] :: forall b c a. (b -> c) -> (a -> b) -> a -> c [GblId, Arity=3, Caf=NoCafRefs, Str=, Unf=OtherCon []] = \r [f_s6N7 g_s6N8 x_s6N9] let { sat_s6Na [Occ=Once] :: b_a2Yb [LclId] = \u [] g_s6N8 x_s6N9; } in f_s6N7 sat_s6Na; }}} This itself is not a CAF and has no free variables, so not CAFFY. {{{ GHC.Base.$fFunctor->_$c<$ :: forall r a b. a -> (r -> b) -> r -> a [GblId, Arity=3, Caf=NoCafRefs, Str=, Unf=OtherCon []] = \r [x_s6Ng eta_s6Nh eta1_s6Ni] x_s6Ng;, }}} This also isn't a CAF itself and has no free variables. So really `fFunctor->` should not be CAFFY, but its `CafInfo` says it may have refs. I don't know which Core pass thinks that this function may have CAF refs, and why. We have more info about what is CAF and what is not in STG so the new analysis may make more things non-CAFFY, which is a good thing. But I still want to understand why a Core pass things this definition is CAFFY. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 08:46:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 08:46:13 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.85988f1ce482aa73e2d2a30bbcfab4e5@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I now built GHC with some debug prints to see what's going on. Here are some numbers: - The new analysis never returns `MayHaveCafRefs` for a binder that previous passes assigned `NoCafRefs`. - There are 9604 binders for which the new analysis returned `NoCafRefs`, but they were assigned `MayHaveCafRefs` by previous passes. I looked at a few of the definitions that were assigned `NoCafRefs` by the new analysis but were previously `MayHaveCafRefs`. Here are a few examples: (see also the example in comment:19) ---- utils/hpc/HpcMarkup.hs: {{{ sat_s7Je :: GHC.Types.Int [LclId] = CCS_DONT_CARE GHC.Types.I#! [68#]; }}} (I don't know why this was previously `MayHaveCafRefs`) ---- libraries/base/GHC/Conc/Sync.hs {{{ sat_s8GJ :: forall a. GHC.Conc.Sync.STM a -> GHC.Conc.Sync.STM a -> GHC.Conc.Sync.STM a [LclId] = \r [eta_B3 eta_B2 void_0E] catchRetry# [eta_B3 eta_B2 GHC.Prim.void#]; }}} This itself is not a CAF. Only free variable is `GHC.Prim.void#` (we don't consider `catchRetry#` as a free variable because it's a primop) which is defined like this {{{ voidPrimId = pcMiscPrelId voidPrimIdName voidPrimTy (noCafIdInfo `setUnfoldingInfo` evaldUnfolding -- Note [evaldUnfoldings] `setNeverLevPoly` voidPrimTy) }}} So this is not CAFFY (again, I don't know why this was previously `MayHaveCafRefs`). ---- I also checked a few other definitions, one interesting binder that was previously `MayHaveCafRefs` and is now `NoCafRefs` is this foreign import: {{{ foreign import ccall unsafe "static stdlib.h &free" c_free_finalizer :: FunPtr (Ptr Word8 -> IO ()) }}} Once again I have no idea why this was previously `MayHaveCafRefs`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 08:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 08:58:45 -0000 Subject: [GHC] #15988: Remove Text.Printf and System.Console.GetOpt from base In-Reply-To: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> References: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> Message-ID: <064.3a275684ab256f2c76678bb428f9f50c@haskell.org> #15988: Remove Text.Printf and System.Console.GetOpt from base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 svenpanne): Replying to [ticket:15988 andrewthad]: > [...] There would be breakage from doing this, but libraries and applications that use these APIs would only need to add a single line to `build-depends` to continue being compatible with all versions of `base`. [...] Hmmm, I don't think it's that easy: If you add the proposed `getopt` package to `build-depends` and compile with current `base`, GHC will see *two* implementations of `System.Console.GetOpt`: One from `base` and one from `getopt`. I really hope that this will result in a compilation error, silently picking one of the two implementations would be really, really bad... I think you will at least have to guard your `build-depends` with a `if impl(ghc >= X.Y)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 09:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 09:13:05 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.678e02f553408c5cd0f458e59746f214@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I think one of the reasons why previosly we had so much more `MayHaveCafRefs` is because `vanillaIdInfo` conservatively assigns `MayHaveCafRefs` to the id, which is used in a lot of places when inventing new Ids. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 09:48:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 09:48:58 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.97405d058df63a567cd5b282b9f4b537@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by adamse): I was wondering if the dynamic GHC building should respect the Hadrian equivalent of {{{DYNAMIC_GHC_PROGRAMS=NO}}}. I don't think the current code will do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 11:47:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 11:47:32 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.4c7c9c9bfa7e2a46afeab39e39c43ede@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 11:50:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 11:50:29 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.53b5a9af28f934b70c99a412570f6988@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In GHC today, the `CafInfo` for top-level bindings is set by `TidyPgm.tidyTopBind`, which in turn uses `hasCafRefs`. Note that `hasCafRefs` returns true if * The binding mentions CAFFy things * The binding ''is'' a CAF Notice the the code in `hasCafRefs` has all kind of wierd stuff to do with integer literals; this vanishes entirely in your new code because the integer-literal expansion is done by the time your new analysis gets to it. But you may need to look at {{{ is_caf = not (arity > 0 || rhsIsStatic (targetPlatform dflags) is_dynamic_name cvt_literal expr) }}} The `rhsIsStatic` code (in `CoreUtils`) is basically looking for a thunk. But it has some kind of special case for DLLs -- you should ensure that your new analysis deals correctly with this. `rhsIsStatic` also has code for dealing with partial applications, which I don't think we need. So I think you only need a MUCH simpler function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 11:51:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 11:51:22 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.8b4784f889c8fbfb857eaf2cab0399b8@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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): Re commment:20 {{{ sat_s7Je :: GHC.Types.Int [LclId] = CCS_DONT_CARE GHC.Types.I#! [68#]; }}} This is introduced in core-to-stg, and perhaps indeed its CAFFy flag is conservative. So that may be a useful improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 11:57:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 11:57:47 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.cde24ef7ee5961a881eaa7bf06346104@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I'm looking into Andrey's suggestion (which I have been meaning to do for a while, ever since we implemented the "new" `Rules.Library` module). I did some profiling myself and the picture becomes even clearer if we hide shake from it: {{{ COST CENTRE MODULE SRC %time %alloc compilePackage Rules.Compile src/Rules/Compile.hs:(13,1)-(36,77) 49.2 78.4 split Data.List.Extra src/Data/List/Extra.hs:(569,1)-(571,48) 41.7 8.6 modifyVar Control.Concurrent.Extra src/Control/Concurrent/Extra.hs:191:1-36 2.3 1.1 buildPackageDependencies Rules.Dependencies src/Rules/Dependencies.hs:(15,1)-(35,52) 1.5 2.9 generatePackageCode Rules.Generate src/Rules/Generate.hs:(102,1)-(150,49) 0.5 1.6 configurePackage Rules.Register src/Rules/Register.hs:(24,1)-(27,38) 0.4 1.5 }}} While Shake itself might benefit from some optimisations for those paths manipulations that are involved here, clearly our number one problem is the enumeration of contexts for `compilePackage` that we do in `Rules.hs`, as you pointed out @snowleopard. I'm going to migrate `Rules.Compile` over to the enumeration-less, parsing-based style the best I can and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:05:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:05:47 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.e6b589fbc46598febdfa5353e9d98867@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > So I think you only need a MUCH simpler function. Indeed, my function is much simpler. The whole analysis is implemented in 69 lines: https://github.com/osa1/ghc/blob/7eeb49f1a034d500cad69151d205985f1fef3f31/compiler/stgSyn/StgCafAnal.hs I just booted GHC with updated iface files. I'll now try to validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:08:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:08:46 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.6b9dd3fba6ed1a0b1e540d26d646e4b8@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): @alpmestan Many thanks for checking my conjecture and going ahead with the implementation! I hope this will bring our zero build times closer to zero :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:14:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:14:45 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.5a3b316eabe3011371946a4ef81db7ca@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Did you check out the bit about DLLs in `CoreUtils.rhsIsStatic`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:41:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:41:31 -0000 Subject: [GHC] #15988: Remove Text.Printf and System.Console.GetOpt from base In-Reply-To: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> References: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> Message-ID: <064.11aec40e308111608086ce1657a991cd@haskell.org> #15988: Remove Text.Printf and System.Console.GetOpt from base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): Sorry, I didn't explain that part clearly. I mean using cabal-the- library's module reexport feature (1) (not GHC's module reexport feature). In the cabal file for the `getopt` library, we would have something like this: {{{ library default-language: Haskell2010 if impl(ghc < 8.8) build-depends: base >= 4.5 (or whenever the module was originally introduced) reexported-modules: System.Console.GetOpt else hs-source-dirs: src exported-modules: System.Console.GetOpt }}} So now on old GHCs, the module really is exported by both libraries, but cabal (or maybe GHC) understands that these are the same module. (1) https://ghc.haskell.org/trac/ghc/wiki/ModuleReexports -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:47:19 -0000 Subject: [GHC] #13256: Warn on out-of-range literals in pattern matches too In-Reply-To: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> References: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> Message-ID: <062.a71efb223b573d5417f62d5c8dcce418@haskell.org> #13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: patch 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): Phab:D5181 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"75a8349b2a7d0142d3d687837caf5a95bbb4368d/ghc" 75a8349/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75a8349b2a7d0142d3d687837caf5a95bbb4368d" Warn on all out-of-range literals in pats/exprs Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:47:19 -0000 Subject: [GHC] #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals In-Reply-To: <046.095a614b9437d6cfe76c234b07042878@haskell.org> References: <046.095a614b9437d6cfe76c234b07042878@haskell.org> Message-ID: <061.55247b879d7726cbddef6b324483bebd@haskell.org> #9505: Bounded instance for Word (and possibly others) uses explicitly unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: ⊥ Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"75a8349b2a7d0142d3d687837caf5a95bbb4368d/ghc" 75a8349/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75a8349b2a7d0142d3d687837caf5a95bbb4368d" Warn on all out-of-range literals in pats/exprs Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:47:19 -0000 Subject: [GHC] #10930: missing empty-Enumeration and out-of-range warning for `Natural` In-Reply-To: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> References: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> Message-ID: <057.5b801f9609465f5b3fd05d305b919e3f@haskell.org> #10930: missing empty-Enumeration and out-of-range warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7881, #10929 | Differential Rev(s): Phab:D1306, Wiki Page: | Phab:D5181 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"75a8349b2a7d0142d3d687837caf5a95bbb4368d/ghc" 75a8349/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75a8349b2a7d0142d3d687837caf5a95bbb4368d" Warn on all out-of-range literals in pats/exprs Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:47:19 -0000 Subject: [GHC] #15985: `pprint EqualityT` infinitely loops In-Reply-To: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> References: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> Message-ID: <065.251e7a381ecc2232298b7144e6c20fa0@haskell.org> #15985: `pprint EqualityT` infinitely loops -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.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:D5403 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"89d80921d9328499ffca9877e7dea540350be9c1/ghc" 89d8092/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89d80921d9328499ffca9877e7dea540350be9c1" Fix embarrassing infinite loop in pprParendType Summary: `pprParendType` was missing an explicit case for `EqualityT`, which caused it to fall through to a catch-all case that invokes `ppr`. But `ppr` itself does not have a case for a partial application of `EqualityT`, so //it// falls back to `pprParendType`, resulting in an infinite loop! The fix is simple: add a case for `EqualityT` in `pprParendType`. While I was in the neighborhood, I removed the catch-call case in `pprParendType` to make this sort of mistake less likely to happen in the future. Test Plan: make test TEST=T15985 Reviewers: bgamari, monoidal, simonpj Reviewed By: monoidal, simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15985 Differential Revision: https://phabricator.haskell.org/D5403 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:47:19 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.79d6df0ca2fad3d51e7b9f9650ab5a14@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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): Phab:D5402 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"2e6cc3d08f8439a2c0b6426e839d80072dbcda2c/ghc" 2e6cc3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2e6cc3d08f8439a2c0b6426e839d80072dbcda2c" Fix #15954 by rejigging check_type's order Summary: Previously, `check_type` (which catches illegal uses of unsaturated type synonyms without enabling `LiberalTypeSynonyms`, among other things) always checks for uses of polytypes before anything else. There is a problem with this plan, however: checking for polytypes requires decomposing `forall`s and other invisible arguments, an action which itself expands type synonyms! Therefore, if we have something like: ```lang=haskell type A a = Int type B (a :: Type -> Type) = forall x. x -> x type C = B A ``` Then when checking `B A`, `A` will get expanded to `forall x. x -> x` before `check_type` has an opportunity to realize that `A` is an unsaturated type synonym! This is the root cause of #15954. This patch fixes the issue by moving the case of `check_type` that detects polytypes to be //after// the case that checks for `TyConApp`s. That way, the `TyConApp` case will properly flag things like the unsaturated use of `A` in the example above before we ever attempt to check for polytypes. Test Plan: make test TEST=T15954 Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15954 Differential Revision: https://phabricator.haskell.org/D5402 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:50:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:50:48 -0000 Subject: [GHC] #15988: Remove Text.Printf and System.Console.GetOpt from base In-Reply-To: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> References: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> Message-ID: <064.5396401e35756625b24f2f644247e6c2@haskell.org> #15988: Remove Text.Printf and System.Console.GetOpt from base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 svenpanne): Ooops, I must have missed that Cabal feature somehow. :-} Then the transition is of course easy for code using `System.Console.GetOpt`: Just unconditionally depend on the upcoming `getopt` package, which is totally OK. Sorry for the confusion... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:56:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:56:09 -0000 Subject: [GHC] #15985: `pprint EqualityT` infinitely loops In-Reply-To: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> References: <050.0434c8f4f8e8a2aff7a88b9909283f69@haskell.org> Message-ID: <065.5398a0d0e9e4c0a341b739ec813c97e3@haskell.org> #15985: `pprint EqualityT` infinitely loops -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15985 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5403 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T15985 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 12:58:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 12:58:21 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.a65e71222591ada443d9933ea61e98e6@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T15954 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => typecheck/should_fail/T15954 * resolution: => fixed * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:05:51 -0000 Subject: [GHC] #10930: missing empty-Enumeration and out-of-range warning for `Natural` In-Reply-To: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> References: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> Message-ID: <057.1033b27a314ab5cdf6e676f62789b24e@haskell.org> #10930: missing empty-Enumeration and out-of-range warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | warnings/should_compile/T10930{,b} Blocked By: | Blocking: Related Tickets: #7881, #10929 | Differential Rev(s): Phab:D1306, Wiki Page: | Phab:D5181 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => warnings/should_compile/T10930{,b} * resolution: => fixed * milestone: => 8.8.1 Comment: harpocrates, do you mind updating wiki:Migration/8.8 with a section about these changes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:06:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:06:40 -0000 Subject: [GHC] #15988: Remove Text.Printf and System.Console.GetOpt from base In-Reply-To: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> References: <049.40fe923d09ce7c6aa41070147d31ac16@haskell.org> Message-ID: <064.6b3c9c9ab87bc49a78bdfcc36c67d80d@haskell.org> #15988: Remove Text.Printf and System.Console.GetOpt from base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): No worries. It's a pretty easy Cabal feature to miss since it's seldom used. Thinking about it more, I've realized that there actually is one small wrinkle to this plan though. Let's say that the original release of `getopt` is version `1.0.0.0`. It could be compatible with `base-4.x`, where `x` is the last time `System.Console.GetOpt` had any public-facing change to the API. If a minor release ever happened that adding anything, however small, to the API (`getopt-1.0.1.0`), this next release would need to drop the whole `module-reexport` clause and all compatibility with versions of `base` less than `4.13` (or whichever `base` the transition happened in). This isn't really a problem since it's no worse than the current situation, but it's worth noting. With the module being in `base`, if a change were made to `System.Console.GetOpt` and someone wrote a library that required the change, they would similarly have to blacklist old versions of `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:07:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:07:36 -0000 Subject: [GHC] #13256: Warn on out-of-range literals in pattern matches too In-Reply-To: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> References: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> Message-ID: <062.349a93e091be50a2af9fc5e9e3b6dbf5@haskell.org> #13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | warnings/should_compile/T13256 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5181 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => warnings/should_compile/T13256 * resolution: => fixed * milestone: => 8.8.1 Comment: harpocrates, do you mind updating wiki:Migration/8.8 with a section about these changes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:10:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:10:13 -0000 Subject: [GHC] #15460: Literals overflow In-Reply-To: <045.4d90b83e8c6931283f442559046619d4@haskell.org> References: <045.4d90b83e8c6931283f442559046619d4@haskell.org> Message-ID: <060.b812f25fdb569925e0fc026c3b154e69@haskell.org> #15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): harpocrates, was this fixed in Phab:D5181, or is there more to do here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:42:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:42:51 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.1bfce56da380884cc460f2ef86ba5b02@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: 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:"03d4852658e1b7407abb4da84b1b03bfa6f6db3b/ghc" 03d48526/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03d4852658e1b7407abb4da84b1b03bfa6f6db3b" Introduce tcTypeKind, and use it In the type checker Constraint and * are distinct; and the function that takes the kind of a type should respect that distinction (Trac #15971). This patch implements the change: * Introduce Type.tcTypeKind, and use it throughout the type inference engine * Add new Note [Kinding rules for types] for the kinding rules, especially for foralls. * Redefine isPredTy ty = tcIsConstraintKind (tcTypeKind ty) (it had a much more complicated definition before) Some miscellaneous refactoring * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp, in favour of TyCoRep.kindRep, kindRep_maybe * Rename Type.getRuntimeRepFromKind_maybe to getRuntimeRep_maybe I did some spot-checks on compiler perf, and it really doesn't budge (as expected). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:49:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:49:11 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.6a24bee6eaedad646131da013ad37da6@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): It validates! I'll check out `rhsIsStatic` business now. One thing I realized that at least some uses of `rhsIsStatic` won't be necessary (e.g. the use in `canFloatFromNoCaf`). I'll check others now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:51:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:51:12 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.1eaa321b424cea448537a936bd65152a@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Branch: Wiki Page: | wip/T15791 -------------------------------------+------------------------------------- Comment (by simonpj): Fixed by this commit (though I put the wrong ticket number in the commit message). In [changeset:"03d4852658e1b7407abb4da84b1b03bfa6f6db3b/ghc" 03d48526/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03d4852658e1b7407abb4da84b1b03bfa6f6db3b" Introduce tcTypeKind, and use it In the type checker Constraint and * are distinct; and the function that takes the kind of a type should respect that distinction (Trac #15971). This patch implements the change: * Introduce Type.tcTypeKind, and use it throughout the type inference engine * Add new Note [Kinding rules for types] for the kinding rules, especially for foralls. * Redefine isPredTy ty = tcIsConstraintKind (tcTypeKind ty) (it had a much more complicated definition before) Some miscellaneous refactoring * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp, in favour of TyCoRep.kindRep, kindRep_maybe * Rename Type.getRuntimeRepFromKind_maybe to getRuntimeRep_maybe I did some spot-checks on compiler perf, and it really doesn't budge (as expected). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 13:52:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 13:52:04 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.04aa12c7cc99d9620d561ab6676c8c89@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.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): Branch: Wiki Page: | wip/T15791 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 14:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 14:09:43 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.babceaf818f4494f7f5af88aaba77572@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm confused about what do cross-DLL references have anything to do with the task at hand. After all we only do changes in the module we're compiling, and we never make any changes in imported ids. I believe those comments about cross-DLL references are either misplaced, or the function was somehow used for other things in the past. I think we can just remove the whole function, and remove the use sites etc. simply because we can now freely float whatever we want without worrying about changing CafInfo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 14:38:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 14:38:31 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.83e7032bc20e44bd170748d056eda97a@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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: closed => new * resolution: wontfix => Comment: Reopening because comment:19 and comment:20 point to a way forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:12:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:12:53 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.b921a1047d89d909f28b76a42202d013@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790, #14668, #15561, | #15777, #15987 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking,| https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:23:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:23:20 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.c3725181f56ac50623749ea229da29c1@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715, #13742 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11715 => #11715, #13742 Comment: Astoundingly, this program appears to have fixed itself between GHC 8.4 and 8.6, since this program: {{{#!hs {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, MultiParamTypeClasses, TypeFamilies #-} import GHC.Exts class NotFound type family F b where F 'False = NotFound F 'True = () }}} Typechecks without issue on GHC 8.6.2 and HEAD. Should we go ahead and add a test case for this, or is this program fragile without a full fix for #11715? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:23:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:23:46 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.6206a4a043bac33c251cd9aa010a0730@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 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: #11621, #13742 | Differential Rev(s): Phab:D3316 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11621, #13742 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:24:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:24:15 -0000 Subject: [GHC] #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 In-Reply-To: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> References: <047.8dc343485a25f502c1d7277dfaedb671@haskell.org> Message-ID: <062.e802bed655ef4a50dddb3893e8765b2c@haskell.org> #13742: Code using ConstraintKinds needs explicit kind signature with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: albertov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: Resolution: | ConstraintKinds, KindSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #11715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11621 => #11621, #11715 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:34:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:34:48 -0000 Subject: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs In-Reply-To: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> References: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> Message-ID: <068.bdcd7b974115375289591ee97e86020e@haskell.org> #7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"aef5d82543bb642a65f63e1f05f245b9cddafd8c/ghc" aef5d825/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aef5d82543bb642a65f63e1f05f245b9cddafd8c" Add test cases for #7503, #14451 At some point between 8.4 and 8.6, two things were fixed: * The entirety of #14451. * One of the test cases in #7503. I've added this as T7503a. The other test case from that ticket still does /not/ work, so we'll have to add T7503b some other day. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:34:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:34:48 -0000 Subject: [GHC] #14451: Need proper SCC analysis of type declarations, taking account of CUSKs In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.f45552bf59afeba3063da9d6cf2d4807@haskell.org> #14451: Need proper SCC analysis of type declarations, taking account of CUSKs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7503 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"aef5d82543bb642a65f63e1f05f245b9cddafd8c/ghc" aef5d825/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aef5d82543bb642a65f63e1f05f245b9cddafd8c" Add test cases for #7503, #14451 At some point between 8.4 and 8.6, two things were fixed: * The entirety of #14451. * One of the test cases in #7503. I've added this as T7503a. The other test case from that ticket still does /not/ work, so we'll have to add T7503b some other day. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:37:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:37:01 -0000 Subject: [GHC] #14451: Need proper SCC analysis of type declarations, taking account of CUSKs In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.f3708a29086d99c082a30723bbfd7b42@haskell.org> #14451: Need proper SCC analysis of type declarations, taking account of CUSKs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14451 Blocked By: | Blocking: Related Tickets: #7503 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => typecheck/should_compile/T14451 * resolution: => fixed * milestone: => 8.6.1 Comment: Alas, #7503 was //not// entirely fixed—see https://ghc.haskell.org/trac/ghc/ticket/7503#comment:10. But this ticket //is// entirely fixed, so we can close this one now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:38:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:38:35 -0000 Subject: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs In-Reply-To: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> References: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> Message-ID: <068.4dd1eec149405bdd1d07ee0d1b7cfd98@haskell.org> #7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T7503a Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T7503a Comment: I've added a test case for the first program in comment:10 as `T7503a`. A test case for the other program—which I'd assume would be called `T7503b`—must wait for another day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 16:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 16:47:19 -0000 Subject: [GHC] #15983: Built-in support for half-floats In-Reply-To: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> References: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> Message-ID: <060.a598417ebb54f1830dc8389a297f690c@haskell.org> #15983: Built-in support for half-floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 carter): I don’t think ghc can support half float any time soon as a built in. 1) for cpu native workloads there’s not a big win afik... because the value in gpu programming is from the bandwidth saving. Aka it’s more of a compact serialization than a representationfor computing. 2) while there is some new hardware with half float or even one bit float suport, those are all seemingly deep learning dedicated hardware. 3) abi concerns - we barely even touch the surface area for handling simd computations with float or double. That stuff needs to be a lot more mature before touching half float. Cause scalar half float isn’t useful from a performance perspective. All in all, the intent is good. But I’d be inclined to Mark this as a won’t fix until ghc simd becomes a lot more mature and commodity hardware has really wide spread support. Which will be years from now at the soonest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:05:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:05:24 -0000 Subject: [GHC] #15983: Built-in support for half-floats In-Reply-To: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> References: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> Message-ID: <060.105093232a5acaa94df91d8885910470@haskell.org> #15983: Built-in support for half-floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In general we don't mark things as "won't fix" unless we actually intend never to fix them. In this case the right response is to just leave the ticket open without a milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:14:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:14:02 -0000 Subject: [GHC] #15980: unpin a mutable byte array In-Reply-To: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> References: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> Message-ID: <064.6db9dbe2fa25312856e56e465a9c7a56@haskell.org> #15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 carter): Hrrrmm. Do you have any examples where you can create excessive fragmentation? That’d be worth a ticket. One issue I see with adding such a primop is that it won’t be possible to respect alignment constraints that may have been expressed at bytearray allocation time. For unaligned bytearrays, you could just copy the buffer over to an unpinned array then copy it into the compact region -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:15:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:15:22 -0000 Subject: [GHC] #15980: unpin a mutable byte array In-Reply-To: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> References: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> Message-ID: <064.76c1900686f5c9b49bc35cd4b6b1261e@haskell.org> #15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 carter): Pinned byte arrays also live in a different world than normal heap objects. So unpinning would be he same as a copy afaict. Which you can easily do in user space already -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:22:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:22:51 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.f55a1071d03ec378cf0675542467ce29@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Ben: you mean the base being too big for macho object format? I agree it’s a problem. I’m confused though : do you mean unwind the stack using the stack walker that only supports ELF FORMATS only at the moment. Or do you mean gdb / lldb being informative for debugging in general? OS X doesn’t get the stack walker at the moment anyways , so that’s only a forward looking issue afaict ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:37:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:37:14 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.c0b4ae03e6f4f2f9be6a94c0f50df377@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 carter): Agreed, -gN flags are supposed to never change the core. This is a bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:39:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:39:38 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.1cc0c946b7e96015453afef798eb55a9@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 carter): The gating / phab stuff on originally adding -g flags / getting them merged in was that core was to never be impacted. Was this change added after the initial merge or was it explicitly accepted? And or what core equivalencies are in the test suite for -g? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 17:40:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 17:40:31 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.41fa029792e373cbc11d368f6dae70be@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:67 simonpj]: > I think there is an option to force GC to happen more frequently, but I can't see it in the manual. Simon Marlow might know. There's `-i`, but that only seems to work in conjunction with `-h`: {{{ -h Heap residency profile (output file .hp) -i Time between heap profile samples (seconds, default: 0.1) }}} Also, even with `-i0.0001s -h` the sampled maximum residency doesn't come close to the 192/196MB above. > In any case, getting an accurate residency profile, by using one generation and frequent gcs, is a Good Thing. when you do that, to the residency profiles of the two versions differ? I didn't understand the figures you show above. Sorry for causing you trouble to understand what I wrote, I really have to figure out better ways to present my results. So, yeah, using one generation and 'just the right GC frequency' is basically what I did in comment:65. I defined 'just the right frequency' by choosing the `-A$iM` setting (which determines the points at which GC happens) for which maximum residency is at its maximum for each of the two candidates. For the `default`, which looks at closure growth, this setting was `-A56M` with a maximum residency of 192MB. For the version where we also lift said `go` function (which we normally would not), maximum residency was at 196MB for `-A76M`. That's worse than the baseline, as I initially expected. The fuzz above was all for nothing, because I once again merely measured the RTS parameterisation. In comment:66 I remembered that despite better runtime measurements with the baseline, counted instructions regressed when 'turning off' GC with `-A128M`. That's strange, but I'll probably refer to runtime measurements in the paper now and ignore counted instructions completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 18:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 18:38:22 -0000 Subject: [GHC] #15983: Built-in support for half-floats In-Reply-To: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> References: <045.621a49aa6d692155d5c442ad875fe03e@haskell.org> Message-ID: <060.2ed121256be1ae1c439779b947b9633a@haskell.org> #15983: Built-in support for half-floats -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 lerkok): @carter I agree that the SIMD support isn't stellar. I still think native support for half-floats (even if it was all software) would be valuable for modeling purposes and for DSL's that can use the base algorithms to generate more interesting code. I think this "feature request" makes sense, but whether there's enough ROI or something more systematic needs to be done first is obviously a GHC-HQ decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 18:46:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 18:46:41 -0000 Subject: [GHC] #15980: unpin a mutable byte array In-Reply-To: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> References: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> Message-ID: <064.8dad603f2cac8ee3024fbeb2005662a7@haskell.org> #15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): Yeah, the fact that they live in a separate part of the heap seems pretty damning. I think I'll just have to accept that this cannot be done. At least, not without large changes to GHC's runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 18:47:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 18:47:36 -0000 Subject: [GHC] #15980: unpin a mutable byte array In-Reply-To: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> References: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> Message-ID: <064.d493a51f27204c5ef77482b14273117a@haskell.org> #15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 andrewthad): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 19:31:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 19:31:22 -0000 Subject: [GHC] #15986: Poor error message source location reporting with unsaturated type family In-Reply-To: <050.2e30a951b81def4215389a22cebfd8df@haskell.org> References: <050.2e30a951b81def4215389a22cebfd8df@haskell.org> Message-ID: <065.f599f03d933b7add3911b6ba199213f0@haskell.org> #15986: Poor error message source location reporting with unsaturated type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: duplicate | Keywords: TypeFamilies, | TypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15479 Comment: This is just one aspect of #15479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 19:31:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 19:31:38 -0000 Subject: [GHC] #15479: Return HsType GhcTc from tc_hs_type In-Reply-To: <048.00ac96140ec7697046679926451177c4@haskell.org> References: <048.00ac96140ec7697046679926451177c4@haskell.org> Message-ID: <063.d13deb399f7061731a0620de0342fa20@haskell.org> #15479: Return HsType GhcTc from tc_hs_type -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15986 | Differential Rev(s): Phab:D5047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15986 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 22:00:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 22:00:22 -0000 Subject: [GHC] #15760: Preserve parens in TH In-Reply-To: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> References: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> Message-ID: <062.be8951903e0384099e0ad07251af8b56@haskell.org> #15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15815, #15824 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * related: #15815 => #15815, #15824 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 22:04:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 22:04:44 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.1eec9669352e114e571661fd177fba76@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): I just added a feature to Shake HEAD when running in diagnostic mode {{{-VVV}}} prints out the number of actions, rules and user rules: {{{ % Number of actions = 0 % Number of builtin rules = 20 [OracleQ Generator,OracleQ ModuleFiles,OracleQ PackageConfigurationKey,FilesQ,FileQ,GetDirectoryFilesQ,OracleQ WindowsPath,OracleQ DirectoryContents,OracleQ KeyValue,OracleQ LookupInPath,OracleQ KeyValues,OracleQ ContextDataKey,DoesDirectoryExistQ,AlwaysRerunQ,GetDirectoryContentsQ,OracleQ (ArgsHash Context Builder),DoesFileExistQ,GetDirectoryDirsQ,OracleQ PackageDataKey,GetEnvQ] % Number of user rule types = 2 % Number of user rules = 36790 }}} The number of user rules at 36K is way higher than Shake can deal with nicely. I see one for every directory (e.g. {{{_build/stage3/libraries/containers/build/cmm}}}, {{{_build/stage3/libraries/containers/build/c}}}, {{{_build/stage3/libraries/containers/build/s}}}) cross product with every extension (e.g. {{{.l_o}}}, {{{.thr_debug_o}}}, {{{.thr_dyn_o}}}). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 22:22:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 22:22:27 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.8ae31cf8864f47523c50f7fd0539b584@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): To measure the performance impact of those rules, I did: * {{{--no-build}}} which takes 0.31s * {{{--no-build -VVV}}} which forces it to count (and thus create) all the rules which takes 9.10s So creating the rules takes about 9s on my machine, and is suggestive of the zero-build performance we would gain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 22:30:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 22:30:36 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.f4bcc0259f03e44f40f28ae2c2d02232@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Thanks Neil -- cool stats :) I believe with Alp's refactoring we'll go below 100 rules for the whole Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 3 22:46:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Dec 2018 22:46:34 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.5087aa2af2ff2e5d0595fc964871b18c@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * cc: watashi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 02:29:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 02:29:13 -0000 Subject: [GHC] #15991: Regression in error message when attempting to let bind an existentially quantified type Message-ID: <047.6c0bc073607f008e73ae28926817d057@haskell.org> #15991: Regression in error message when attempting to let bind an existentially quantified type -------------------------------------+------------------------------------- Reporter: mmailhot | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- When attempting to compile the following (invalid) program: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} data Foo = forall a. Foo a main :: IO () main = let Foo x = Foo 1 in return () }}} GHC 8.6.2.0 (and 8.6.1.0, 8.4.1.0) gives the following complicated error message {{{ Test.hs:7:13: error: • Couldn't match expected type ‘p’ with actual type ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Foo :: forall a. a -> Foo, in a pattern binding at Test.hs:7:9-13 • In the pattern: Foo x In a pattern binding: Foo x = Foo 1 In the expression: let Foo x = Foo 1 in return () | 7 | let Foo x = Foo 1 in | }}} GHC 7.10.1.2 gave a much more helpful and direct error message {{{ Test.hs:7:9: My brain just exploded I can't handle pattern bindings for existential or GADT data constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the pattern: Foo x In a pattern binding: Foo x = Foo 1 In the expression: let Foo x = Foo 1 in return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 05:04:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 05:04:27 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.0d4dfe1ff2384bfcc7597584c052d3be@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Almost done ... I removed the entire cross-DLL stuff, with a lot of other comments and code, and it validates. As said in comment:27 I think the DLL stuff is not relevant to the task (we don't do any cross-module stuff), and the function (`rhsIsStatic`) is not used elsewhere, so it's fine to remove it. I need to do some refactoring, and `ModIface` updates are currently terrible because the `ModIface` type is not easy to update (holds everything in lists). Another problem is I introduced new Stg passes. I'll do some refactoring and then submit a diff to get some comments before doing more refactoring to fix these issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 05:16:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 05:16:52 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.a95297a467f422e5361d0941c2fc14e9@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by osa1): I don't think we have a parameter to force GC to happen more frequently (there's -I but that only applies to idle GC). I think the best you can do is adding a bunch of `performMajorGC`s in your program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 05:57:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 05:57:59 -0000 Subject: [GHC] #15990: Dynamically built GHC crashes on MacOS In-Reply-To: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> References: <050.6283fb43fa14cfae790767126fe51bab@haskell.org> Message-ID: <065.bf08ae257d99046e2ffafe95bbb868b8@haskell.org> #15990: Dynamically built GHC crashes on MacOS -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5409 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5409 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 06:06:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 06:06:57 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.7ae427c93f2e6690b577e1b158275765@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This would be good to fix .. I have a large patch and it'd be good to test it with slow validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 06:13:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 06:13:21 -0000 Subject: [GHC] #15935: TYPE is not generated by genprimops In-Reply-To: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> References: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> Message-ID: <060.59bbf60d5cfb25cc01ec08bfcaf70e7b@haskell.org> #15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.2 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 harpocrates): Replying to [comment:2 bgamari]: > It's not quite that simple; `utils/genprimcode` knows nothing of the `r` tyvar. You will need to introduce such a variable, along with a `primtype` for `RuntimeRep` itself. The `r` variable won't give `utils/genprimopcode` any problems but it won't have a kind annotation `:: RuntimeRep` on it. That's all temporary though. Once the Hi Haddock patch makes it into GHC/Haddock, you should even get the right kind annotation for free. This should all be analogous to the `data (->) a b` patch (https://phabricator.haskell.org/D5167). (With Hi Haddock, that gets rendered as `data (a :: TYPE r) -> (b :: TYPE q)`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 06:22:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 06:22:49 -0000 Subject: [GHC] #15935: TYPE is not generated by genprimops In-Reply-To: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> References: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> Message-ID: <060.17cc7a88ad0cd9bc789d2416e6543a81@haskell.org> #15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.2 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 harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 06:23:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 06:23:21 -0000 Subject: [GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom. In-Reply-To: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> References: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> Message-ID: <066.e9b48f87f704984c0ec0241116b07d4b@haskell.org> #15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 07:15:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 07:15:52 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.a750e7e559e677afca5e2a4fc2206ec5@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | Phab:D5398 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"6090002e19d5c888c2eda0ce06dd84e3c46aa0c9/ghc" 6090002e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6090002e19d5c888c2eda0ce06dd84e3c46aa0c9" Improve test T14452 for Windows Summary: Under Windows all parameters to gcc are enclosed in quotes, opposite to Linux, where the quotes are missing. Therefore in the test, we remove all quotes in the stdout file with sed. Test Plan: make test TEST=T14452 Reviewers: osa1, hvr, bgamari, monoidal, Phyx, simonpj Reviewed By: Phyx Subscribers: rwbarton, carter GHC Trac Issues: #14452 Differential Revision: https://phabricator.haskell.org/D5398 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 07:15:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 07:15:52 -0000 Subject: [GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows In-Reply-To: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> References: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> Message-ID: <062.2922a3d59daf6bb751efcf6575873f62@haskell.org> #15894: Cannot find symbol during interactive linking using new-repl on Windows -----------------------------+---------------------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T15894 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5353 Wiki Page: | -----------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"a8b7cef4d45a5003bf7584e06912f0f632116c71/ghc" a8b7cef4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8b7cef4d45a5003bf7584e06912f0f632116c71" linker: store entire link map and use it. Summary: This fixes a corner case in which we have seen the symbol multiple times in different static libraries, but due to a depencency we end up loading the symbol from a library other than the first one. Previously the runtime linker would only track symbols from the first library and did not store the full link map. In this case it was unable to find the address for the symbols in the second library during delay loading. This change stores the address of all symbols seen so a full link map is generated, such that when we make a different decision later than what was expected we're able to still correctly load the library. Test Plan: ./validate, new testcase T15894 Reviewers: angerman, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15894 Differential Revision: https://phabricator.haskell.org/D5353 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 07:15:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 07:15:52 -0000 Subject: [GHC] #15956: Linker error building `runghc` In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.63f3e15f2f45dcb8dfb19e2641554012@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5404 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"924026e0405396a3f559f163e829b88f30cca49e/ghc" 924026e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="924026e0405396a3f559f163e829b88f30cca49e" Hadrian: include 'findPtr' via find-ptr cabal flag Summary: This is the latest in the 'findPtr' saga. See * 900c47f88784b91517c00be3e1087322e62f698e * 561748cb507505bd5b7bd76bdc57796d896b62a2 for the previous attempts. The problem with re-using the 'debug' cabal flag for the purpose of forcing inclusion of 'findPtr' occurs when 'debug' is one of the RTS ways, but RTS is not being compiled with '-DDEBUG': * the 'debug' flag gets passed to cabal, signalling to build 'rts' with the debug flavour, but also forcing inclusion of the 'findPtr'/'_findPtr' symbol * since '-DDEBUG' isn't enabled, that symbol doesn't show up in the libraries, so executable that depend on 'rts' (everything) will end up always requiring 'findPtr'/'_findPtr' but 'rts' won'y provide it! The fix is simple: create a a new 'find-ptr' cabal-flag whose only purpose is forcing '-Wl,-u,findPtr'/'-Wl,-u,_findPtr'. Then, enable that flag when the RTS is being compiled with '-DDEBUG' Test Plan: ./hadrian/build.sh -c # on mac Reviewers: alpmestan, snowleopard, bgamari, erikd, simonmar, Phyx Reviewed By: alpmestan, snowleopard, Phyx Subscribers: Phyx, rwbarton, carter GHC Trac Issues: #15956 Differential Revision: https://phabricator.haskell.org/D5404 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 07:16:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 07:16:37 -0000 Subject: [GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows In-Reply-To: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> References: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> Message-ID: <062.47d0922f487715ce018d887ebf854a28@haskell.org> #15894: Cannot find symbol during interactive linking using new-repl on Windows -----------------------------+---------------------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T15894 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5353 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 09:14:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 09:14:53 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.07ffe16d3c3de2a30c81e6957bc2daf7@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think the DLL stuff is not relevant to the task (we don't do any cross-module stuff)and the function (rhsIsStatic) is not used elsewhere, so it's fine to remove it. Probably. But be careful here! There is some platform-specific stuff in that function, so it might be fine on your platform but not on others. I see stuff like {{{ Top-level constructor applications can usually be allocated statically, but they can't if the constructor, or any of the arguments, come from another DLL (because we can't refer to static labels in other DLLs). If this happens we simply make the RHS into an updatable thunk, and 'execute' it rather than allocating it statically. }}} and {{{ go (Var f) n_val_args | (platformOS platform /= OSMinGW32) || not (is_dynamic_name (idName f)) }}} I don't fully understand this, but it's all tied up with `isDllConApp`, which in turn is used in `CoreToStg`. I believe that this code in `CoreToStg` nails it: {{{ | StgConApp con args _ <- unticked_rhs , -- Dynamic StgConApps are updatable not (isDllConApp dflags this_mod con args) = -- CorePrep does this right, but just to make sure ASSERT2( not (isUnboxedTupleCon con || isUnboxedSumCon con) , ppr bndr $$ ppr con $$ ppr args) ( StgRhsCon dontCareCCS con args, ccs ) }}} so we don't need to worry in our new (late) CAF analysis. But none of this DLL special casing is properly documented so I don't really understand what is happening. Returning to `rhsIsStatic` we have this: {{{ is_static _ (Lit (LitLabel {})) = False is_static _ (Lit _) = True -- A LitLabel (foreign import "&foo") in an argument -- prevents a constructor application from being static. The -- reason is that it might give rise to unresolvable symbols -- in the object file: under Linux, references to "weak" -- symbols from the data segment give rise to "unresolvable -- relocation" errors at link time This might be due to a bug -- in the linker, but we'll work around it here anyway. -- SDM 24/2/2004 }}} No idea what this is about, but I wouldn't just delete it without thought. Finally, I see {{{ -- A naked un-applied variable is *not* deemed a static RHS -- E.g. f = g -- Reason: better to update so that the indirection gets shorted -- out, and the true value will be seen -- NB: if you change this, you'll break the invariant that THUNK_STATICs -- are always updatable. If you do so, make sure that non-updatable -- ones have enough space for their static link field! }}} I think this is probably again dealt with in `CoreToStg`. If we have a bare variable as the RHS I think we get an updatable thunk. I don't understand the bit about THUNK_STATIC though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 09:43:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 09:43:31 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message In-Reply-To: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> References: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> Message-ID: <065.b1e57ac48e8eb54a56cd7de9cc2985e2@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5377 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dminuoso): `- an orphan module we can report how $df came to be in scope.` You need a transitive closure of depended upon orphan modules and finally some `[ImportedBy]` for each such module. We cannot recover that information from TcGblEnv currently. My code already takes your suggested second approach, but it can't do a full job because the record `mi_deps :: Dependencies` has no field containing the full transitive closure of depended upon modules. It only contains that information for orphan modules. I hope the changes I pushed make my code a bit clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 10:05:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 10:05:53 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.202bcbf88f562d992a5ced566a594155@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I'm hoping I'll be able to report some numbers by tonight. I have most of the parsing and "infrastructure" sorted out already. This will require some refactoring I think (e.g right now, to go straight to the point, I'm importing `Rules.Library` from `Rules.Compile` just to be able to reuse some of my parsers) but the performance improvement should be there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 10:46:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 10:46:27 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message In-Reply-To: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> References: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> Message-ID: <065.bd2a19903bf219ef5d6616d1defddcf9@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5377 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've added more comments to the diff. (`mi_deps` includes more than you think!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 10:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 10:47:19 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.53ef58c694cc2d0fc53d8d879ca7474d@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5300 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 10:50:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 10:50:00 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.9e9884a8e6ec94d2f94f0e46353db91e@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): I investigated further, the issue is that adding a user rule match is ''O(n)'', so adding ''n'' rules is ''O(n^2^)''. I have raised a ticket to fix that at https://github.com/ndmitchell/shake/issues/632, so in time the construction in Hadrian might become efficient. But I still recommend fixing it since it's better to not enumerate all the possible paths in advance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 11:13:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 11:13:07 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.8d02c5a0f13ea9f14d3f21e5554332d7@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): I actually managed to eliminate the ''O(n^2^)'' much more easily than expected. Now both builds take the same 0.31s. Having many rules is still going to be expensive for every file you match, but the cost is now not prohibitive. I'd still encourage the refactoring Alp is doing. I'll release a new Shake later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 12:55:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 12:55:12 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler In-Reply-To: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> References: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> Message-ID: <061.4e46b7923f1c13c6325b814c85fb87ed@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Profiling | 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: #8308, #9405 | Differential Rev(s): Phab:D5392 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Just for future references: I think at least `ENT_DYN_THK_MANY_ctr` and `UPDF_PUSHED_ctr` are flawed. I discovered this while inspecting improvements in `queens` to due `-fstg-lift-lams`. With `-fno-stg-lift-lams`, these counters go down, which should not be the case since we don't ever destroy sharing or introduce any kind of additional thunks (like partial applications). On the other hand, this could happen because we no longer can use one of the generic apply functions (like `stg_ap_2`) after lifting, which AFAIK aren't represented at all in ticky numbers. Either way: Fix these counters by - Not using generic apply functions with `-ticky` - Identify and fix accidental misascription like in Phab:D5392 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 13:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 13:28:08 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.8f4d2a65de8568e9df29e16b30372a9e@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry I'm so slow, but I still don't understand the details of comment:68. But no matter! * I think we need a way to get accurate residency profiles, which in turn mean doing frequent, major garbage collections. Then we can present meaningful results, rather than fumble around in the dark. * To do this, either we need to add a RTS flag or... doesn't it happen anyway when we have a very small nursery? Each time the nursery runs out, we GC, and with -G1 that's a major GC. What am I missing? Then I believe you are saying "Ignoring closure growth has no effect on residency". Is that right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 15:26:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 15:26:32 -0000 Subject: [GHC] #15608: Segfault in retainer profiling In-Reply-To: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> References: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> Message-ID: <058.2d2c78bcba5ced43b3cbcc2c4c711d03@haskell.org> #15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.5 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:D5134 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.4.5 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 15:29:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 15:29:25 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.65dad3008b3c13432c14fa5adce7349c@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.4.5 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 15:29:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 15:29:33 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.f320853200a2ab8c82df83534845398f@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.4.5 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 15:29:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 15:29:42 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.8bbda50694b7a69cb4328385836d19a0@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.3 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by osa1): * milestone: 8.4.5 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 15:56:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 15:56:13 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.8a54b70ce2b8347283b980cdb6c59b7c@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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): Re "Finally I see" Simon M pointed out the that the code generator has a special case for indirection bindings `f = g`: {{{ cgTopRhsClosure dflags rec id ccs upd_flag args body = ... where -- special case for a indirection (f = g). We create an IND_STATIC -- closure pointing directly to the indirectee. This is exactly -- what the CAF will eventually evaluate to anyway, we're just -- shortcutting the whole process, and generating a lot less code -- (#7308) -- -- Note: we omit the optimisation when this binding is part of a -- recursive group, because the optimisation would inhibit the black -- hole detection from working in that case. Test -- concurrent/should_run/4030 fails, for instance. -- gen_code dflags _ closure_label | StgApp f [] <- body, null args, isNonRec rec = ... }}} We decided that: * The code generator makes an IND_STATIC for these * So `f` itself is not a CAF * But it might still be CAFFY if `g` is. Hence the CAF analysis could (and probably should) take advantage of this special case (alas, still a form of prediction!) provided it points to a specific Note about it in the code generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:24:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:24:30 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.e4711c6c641968911fab876a105e656c@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): osa1: This was already merged to 8.6, does this mean we don't pursue [comment:13 comment:13]? If so, the ticket can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:25:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:25:59 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.42e2df4d554852a02bc1682c9bf6a9ce@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:16 simonmar]: > The rationale for the naming is described in Will's paper [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.4124]. The distinction between `spectral` and `imaginary` is mainly size: the `imaginary` programs are microbenchmarks, whereas `spectral` programs are algorithmic kernels - larger than microbenchmarks but not real programs. I think it's a useful distinction. > > Perhaps we also want another distinction - programs that run for long enough that we can obtain reliable timing results. However that's an orthogonal dimension, and we can't sensibly use both dimensions for organising the directory structure. So I suggest we just have a flag per benchmark that is true if it runs for long enough, and have a simple way to run just those benchmarks. > I think flagging offending benchmarks is the last resort to get reliable measurements, but sadly I don't see any way around that for ''some'' benchmarks. Let me elaborate. I experienced fluctuations (random improvements and regressions) for benchmarks with either of the following traits: 1. Runtime too short, so that we mostly measure system overhead (partly addressed by Phab:D4989, in response to #15357) 2. Programs like `paraffins`, `binary-trees`, etc., which consist of a relatively long and allocation intensive build-up phase, followed by a fold that immediately collapses the maximum residency. These kind of benchmarks are very sensitive to changes in allocations. Also see #15333. 3. Microbenchmarks like the `real/eff` suite, which optimise to a very small counting loop. Even when they run long enough for runtime measurements to be reproducible (e.g. `VSM` runs for about 670ms-700ms on my machine), a mostly irrelevant change in `base` leads to wibbles. = System overhead = Easy to fix and Phab:D4989 did most (if not all?) of the work. = GC = The GC parameterisation is much harder to remove from the equation. There's an example in #15333 and https://ghc.haskell.org/trac/ghc/ticket/9476#comment:55 ff. The idea is the following: Varying allocations leads to different points in time at which nursery and gen 2 heap run out of space, in turn triggering GC at different points in time. I.e. imagine that because of an overall reduction in allocations, the 5th major GC run happens ''immediately before'' the entire structure is collapsed, when without the reduction the 5th run would happen some time earlier (left baseline, right less total allocations): [[Image(https://i.imgur.com/C5224Ua.jpg, 300px)]] [[Image(https://i.imgur.com/C05SC5K.jpg, 300px)]] The residency at the 5th GC run would approach the maximum residency (not the number sampled by GC, but the one depending on program semantics), which entails a maximally costly GC run, for an impact of as much as 10% on total runtime. This is something that could be tuned by profile-guided optimisation, but otherwise there is no way to predict when a program will hit its maximum residency. The above profile is from `paraffins`, which has the typical structure of an allocating Haskell benchmark: Build up and then consume a large data structure. Although total allocations can be measured realiably on them, these benchmarks aren't particularly indicative of runtime performance and contribute to nofib's noise. I can think of ways to fix the situation without flagging them away, but not without leaving the respective benchmarks untouched: 1. Modify every benchmark in a way that at least one collection will happen at the point where we think maximum residency is hit, through `performMajorGC` or some other kind of allocation in a loop. Yuck. 2. Iterate every benchmark $n times from within the same Haskell process. In particular, this won't reset the GC between runs and will lead to better distribution of heap samples without actually changing the characteristics of the benchmark. We could shrink input problems to get $n sufficiently high, while still running in acceptable time (e.g. 0.5-5s). TODO Identify them = Microbenchmarks = I blame non-determinism in code layout or some other caching effect until I have a better hypothesis. These are the candidats we want to flag away for runtime measurements, especially `real/eff`, or make them actually do something meaningful. TODO: Identify them -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:29:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:29:29 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.79b7c0af045b16f06af8a3fa9fd51150@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): There won't be an 8.4.5 so if this is already merged to 8.6.3 then we can close this. Can anyone confirm that this is merged to 8.6.3 branch and close this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:43:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:43:56 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.4cda8dbaa07fe1b6ae4dd151681b7276@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not sure what you mean by "8.6.3 branch". There's only a `ghc-8.6` branch, and two tagged released (`ghc-8.6.1-release` and `ghc-8.6.2-release`) based on it. If there is an upcoming 8.6.3 release, then presumably it will use the latest commit in the `ghc-8.6` branch, which does contain the commit in question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:45:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:45:47 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.563a1ae67b2371adb9ef7a3d09cf2441@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: merge => closed Comment: The commit 76a233143 is in `ghc-8.6.1-release` branch, so I'm closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:56:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:56:49 -0000 Subject: [GHC] #15460: Literals overflow In-Reply-To: <045.4d90b83e8c6931283f442559046619d4@haskell.org> References: <045.4d90b83e8c6931283f442559046619d4@haskell.org> Message-ID: <060.52ae0c0e25dce56b8744658cdb65a4a9@haskell.org> #15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: harpocrates Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | warnings/should_compile/T15460 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => warnings/should_compile/T15460 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 16:57:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 16:57:06 -0000 Subject: [GHC] #15460: Literals overflow In-Reply-To: <045.4d90b83e8c6931283f442559046619d4@haskell.org> References: <045.4d90b83e8c6931283f442559046619d4@haskell.org> Message-ID: <060.ac58843ad16300d280b54c72c523d8b7@haskell.org> #15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: harpocrates Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | warnings/should_compile/T15460 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D5181 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => ​Phab:D5181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 17:07:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 17:07:19 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.054b5f25dce7c3dd11495a81800d783f@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:70 simonpj]: > * To do this, either we need to add a RTS flag or... doesn't it happen anyway when we have a very small nursery? Each time the nursery runs out, we GC, and with -G1 that's a major GC. What am I missing? Yes, doing `-G1` and varying the initial heap size with `-A$iM` was exactly what I have been doing to find out a close approximation of the maximum residency (the one of related to program semantics, not GC samples). (Note that when a GC happens with `-G1`, the heap is resized to 2*bytes copied according to `-S`, so the 'nursery' grows in `-G1`. Also I don't think that we can vary GC frequency through an RTS flag, because to my knowledge, the decision when to GC is entirely made by the mutator) Example: Let's say I start with `-A40M` (always `-G1` from now on) and let's assume that the picture shows the actual heap profile (e.g., with maximum sampling frequency), where the points in time at which GC runs are indicated in red: [[Image(https://i.imgur.com/RpeuCXc.jpg, 400px)]] The maximum residency observed by GC is smaller than the actual maximum residency, which I call the maximum working set for the remainder of this post for disambiguation. How can we make the sampled maximum residency approximate the maximum working set? We can vary the GC frequency by setting the initial heap size to a different value. It turns out that within the integer range of 1 to 200, `-A56M` seems to be the candidate with the closest approximation (closest meaning it sampled the highest maximum residency): [[Image(https://i.imgur.com/BfvbKSl.jpg, 400px)]] In particular, we don't really care how often major GC happens, only that one major GC happens ''immediately before'' the working set collapses. The `-A56M` is highly specific to the program (in this case, `default` above) and doesn't really matter, it's just the parameterisation where the sampled maximum residency most closely approximates the actual maximum working set. It's similar to modular arithmetic, if that's of any help: Imagine you want to find a number below 20 with the closest multiple to 73 (prime), but not larger than that. There's 8*9=72 or 6*12 or 4*18, etc. It doesn't really matter which factor you choose, point is that you get close to 73. The specific parameterisation for `allow-cg` to approximate its maximum working set was `-A76M -G1`, but it doesn't matter; what matters is that the sampled maximum residency for `default` was lower than `allow-cg` (192 vs. 196MB), so everything as expected. > Then I believe you are saying "Ignoring closure growth has no effect on residency". Is that right? Well, it's hard to tell how close those samples are to the actual maximum working set, but under the assumption that they are close enough, I'd say that ignoring closure growth indeed leads to a bigger working set in this case (as to be expected), although it doesn't really manifest itself in the majority of GC parameterisations I sampled (cf. the second-to-last paragraph in comment:65). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 18:24:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 18:24:50 -0000 Subject: [GHC] #15992: Alternative instance for Data.Functor.Compose causes <>s with some types Message-ID: <049.ae8a3cfc7f1c1bffefd1223381efd24c@haskell.org> #15992: Alternative instance for Data.Functor.Compose causes <>s with some types -------------------------------------+------------------------------------- Reporter: glaebhoerl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | 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: -------------------------------------+------------------------------------- `many` and `some` are [http://hackage.haskell.org/package/base-4.12.0.0/docs/src/Data.Functor.Compose.html#line-119 omitted] and are filled in by their defaults from `Alternative`, instead of re-using the definitions provided for `f`; this manifests as infinite grammars being created in the case of the Earley parsing library, resulting in `<>` errors at runtime. The fix is just to add: {{{#!hs many = Compose . fmap sequenceA . many . getCompose some = Compose . fmap sequenceA . some . getCompose }}} Related twitter thread: https://twitter.com/ollfredo/status/1067498140100628480 (It seems like this bug has been around for some time: https://github.com/feuerbach/regex-applicative/issues/19) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 20:00:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 20:00:02 -0000 Subject: [GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible In-Reply-To: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> References: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> Message-ID: <060.6e00cc56ac64051432b8e449c151636a@haskell.org> #15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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 malo): I'm having a similar issue using GHC 8.6.2. Posting as a comment on this ticket since I expect it's related. Here's a minimal example: {{{ -- test.hs {-# LANGUAGE RankNTypes, QuantifiedConstraints #-} import Data.Coerce data Foo i = Foo i data Bar f i = Bar (f i) -- When I ask that we can lift coercions through the functor... class (forall i j. Coercible i j => Coercible (f i) (f j)) => MyFunctor f where -- ... -- ... this works fine. instance MyFunctor Foo -- When I try to ask that we can lift coercions through a higher functor... class (forall f g. (forall i. Coercible (f i) (g i)) => (forall i. Coercible (x f i) (x g i))) => MyHigherFunctor x where -- ... -- ...this fails instance MyHigherFunctor Bar -- Output from ghci: -- -- Prelude> :l test.hs -- [1 of 1] Compiling Main ( test.hs, interpreted ) -- -- test.hs:21:10: error: -- • Couldn't match representation of type ‘f’ with that of ‘g’ -- arising from the superclasses of an instance declaration -- ‘f’ is a rigid type variable bound by -- a quantified context -- at test.hs:1:1 -- ‘g’ is a rigid type variable bound by -- a quantified context -- at test.hs:1:1 -- • In the instance declaration for ‘MyHigherFunctor Bar’ -- | -- 21 | instance MyHigherFunctor Bar -- | ^^^^^^^^^^^^^^^^^^^ -- Failed, no modules loaded. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 20:34:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 20:34:36 -0000 Subject: [GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible In-Reply-To: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> References: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> Message-ID: <060.faf07570ce660530b9e5346e6bda2f11@haskell.org> #15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 simonpj]: > Can you explain more about this example? I think that it is important that > > * You give a role signature for `Yeah`. (What is the inferred signature?) The inferred signature is `type role Yeah phantom` > * You export the type constructor for `Yeah` but not the data constructor. Yes. The export isn't really as relevant as the import it enables; when a newtype constructor is in scope that changes the coercion axioms the type checker uses for the type. > But I'm a bit lost about what you expect to happen. Can you amplify? Why do you think it should typecheck? It'd probably help to give the declaration for `Coercion` too, for those of us who do not use it daily. The declaration of `Coercion` is {{{#!hs data Coercion a b where Coercion :: Coercible a b => Coercion a b }}} The situation is {{{#!hs yeahCoercible :: ((forall a b. Coercible (Yeah a) (Yeah b)) => r) -> r yeahCoercible r = r -- Fishy2.hs yeah :: Coercion [Yeah a] [Yeah b] yeah = yeahCoercible Coercion }}} We call `yeahCoercible` with `Coercion`. For this to typecheck, we need {{{#!hs Coercion :: (forall a b. Coercible (Yeah a) (Yeah b)) => Coercion [Yeah a] [Yeah b] }}} Put another way, we need `Coercible (Yeah a) (Yeah b)` to imply `Coercible [Yeah a] [Yeah b]`. Under normal circumstances, that would follow from the fact that `[]`'s parameter has a representational role. But the constraint solver isn't figuring that out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 21:05:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 21:05:46 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.05068b972fb1ac3a31cefd43cccdceca@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => Phab:D5412 Comment: Got a patch up at https://phabricator.haskell.org/D5412. This cuts the pauses quite significantly, as expected. From 45-60s down to <5s, when resuming the build from a similar point. With Neil's shake changes mentionned above (which I have not tried yet), I'm confident we won't be seeing those pauses again before quite some time. The next bottleneck seems to be our program lookup in `Rules.Program.buildProgram`. We're also still doing a similarly "big" (not as big as the `compilePackage` one that my patch fixes) listing of contexts and generation of rules in `Rules.hs`, see `vanillaContexts`. Finally, my patch does require to lookup the `Package` from its `pkgPath` that we parse from the file path, but at least it's not at rule generation time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 21:08:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 21:08:59 -0000 Subject: [GHC] #15937: CI strategy for Gitlab In-Reply-To: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> References: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> Message-ID: <063.1b8924201f1dff9f0a2a95e8d3f68a46@haskell.org> #15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: task | Status: closed Priority: normal | Milestone: Component: Continuous | Version: Integration | 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 alpmestan): * status: new => closed * resolution: => fixed Comment: Seems to be working fine. I'm closing this ticket, we can open a new one if we run into a specific problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 22:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 22:59:56 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.cfb353c2a427df2138545711613c815d@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Wizek): * cc: Wizek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 4 23:47:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Dec 2018 23:47:14 -0000 Subject: [GHC] #15993: Bitwise-oriented semigroup and monoid newtype wrappers for Data.Bits.Bits instances Message-ID: <043.79bde8d664ad8d829e358c93054a6419@haskell.org> #15993: Bitwise-oriented semigroup and monoid newtype wrappers for Data.Bits.Bits instances -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've found myself needing these often, and given the existence of similar newtypes for directing `(<>)` and `mempty` for a range of other types, these are conspicuous by their absence. Additionally, while `oneBits` isn't technically necessary, it's a lot more concise than `complement zeroBits`, and I found myself needing it often. To that end, I've sketched up this implementation. Technically speaking, GND isn't needed, but it means I don't have to repeat myself a lot. These could be made even more concise with `coerce`, but I decided not to do that, since that would require `TypeApplications`. I've limited derivation to methods that are specifically about bitwise operations, rather than stuff like `Num`. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Data.Bits.Extra where import Data.Bits ( Bits(..) , FiniteBits(..) ) -- | Monoid under bitwise AND. newtype Conj a = Conj { getConj :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Conj a) where (Conj x) <> (Conj y) = Conj (x .&. y) instance (Bits a) => Monoid (Conj a) where mempty = Conj . complement $ zeroBits -- | Monoid under bitwise OR. newtype Disj a = Disj { getDisj :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Disj a) where (Disj x) <> (Disj y) = Disj (x .|. y) instance (Bits a) => Monoid (Disj a) where mempty = Disj zeroBits -- | Semigroup under bitwise XOR. newtype Xor a = Xor { getXor :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Xor a) where (Xor x) <> (Xor y) = Xor (x `xor` y) -- | Semigroup under bitwise \'equality\'; defined as '1' if the corresponding -- bits match, '0' otherwise. newtype Iff a = Iff { getIff :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Iff a) where (Iff x) <> (Iff y) = Iff . complement $ (x `xor` y) -- not strictly necessary, but would be a big help -- probably should be INLINE oneBits :: (Bits a) => a oneBits = complement zeroBits }}} Potentially this could include more, such as instances of `Ord` based on lexicographic ordering on the bits, rather than defaulting to the underlying one (such as the one for `Int`, which I believe is numeric). However, that's a separate issue. I also don't know if these belong in `Data.Bits` or `Data.Semigroup` (or `Data.Monoid` I guess). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 05:39:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 05:39:08 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.638189f39755b803d2bb1384ab3a7417@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579 Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mnguyen): > > {{{#!hs > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > {-# LANGUAGE TypeInType #-} > module Bug where > > import Data.Kind > import Data.Proxy > > newtype Wat (x :: Proxy (a :: Type)) = MkWat (Maybe a) > deriving Eq > > newtype Glurp a = MkGlurp (Wat ('Proxy :: Proxy a)) > > instance Eq a => Eq (Glurp a) where > (==) = coerce @(Wat ('Proxy @a) -> Wat ('Proxy @a) -> Bool) > @(Glurp a -> Glurp a -> Bool) > (==) > }}} > I try this with my current VKA and it fails {{{#!hs T14579a.hs:15:32: error: Not in scope: type variable ‘a’ T14579a.hs:15:51: error: Not in scope: type variable ‘a’ T14579a.hs:16:25: error: Not in scope: type variable ‘a’ T14579a.hs:16:44: error: Not in scope: type variable ‘a’ }}} ??? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 10:07:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 10:07:03 -0000 Subject: [GHC] #15994: Duplicate entries in -ddump-minimal-imports Message-ID: <046.88a9af819dfcf472c705a5200c69b937@haskell.org> #15994: Duplicate entries in -ddump-minimal-imports -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider {{{ module Foo where import System.IO f = [ReadMode, ReadMode] }}} We get this: {{{ $ ghc -c -ddump-minimal-imports Foo.hs $ cat Foo.imports import System.IO ( IOMode(ReadMode, ReadMode) ) }}} Notice that `ReadMode` appears twice. Turns out this is because of a refactoring in `RnNames` {{{ commit 6353efc7694ba8ec86c091918e02595662169ae2 Author: David Eichmann Date: Thu Nov 22 14:48:05 2018 -0500 Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely }}} (which I wrote -- don't blame David!). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 10:32:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 10:32:57 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.57c53f84837291f9277283fdbf86db15@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579 Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've responded to comment:16 at https://phabricator.haskell.org/D5229#inline-42631. (The code is very nearly correct; you just need some minor tweaks to make it compile). Also, thanks for adding a test case for this! Once the VKA patch lands, I can look into tweaking `GeneralizedNewtypeDeriving` itself such that it generates code with visible kind applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 10:34:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 10:34:02 -0000 Subject: [GHC] #15994: Duplicate entries in -ddump-minimal-imports In-Reply-To: <046.88a9af819dfcf472c705a5200c69b937@haskell.org> References: <046.88a9af819dfcf472c705a5200c69b937@haskell.org> Message-ID: <061.bcc5b73bb24563e802387e1ba64d9f8a@haskell.org> #15994: Duplicate entries in -ddump-minimal-imports -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"84cba4bce65ffc99e2356b3621cf91258b055cad/ghc" 84cba4b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="84cba4bce65ffc99e2356b3621cf91258b055cad" Remove duplicates in -ddump-minimial-imports This fixes Trac #15994. Previously RdrName.gresToAvailInfo assumed that the input list of GREs had no duplicates. I accidentally broke this precondition in this refactoring: commit 6353efc7694ba8ec86c091918e02595662169ae2 Date: Thu Nov 22 14:48:05 2018 -0500 Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely (There was an ASSERT, but it's usually switched off in stage2. It tripped when I switched stage2 assertions on.) The fix is straightforward: account for dups in gresToAvailInfo. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 10:36:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 10:36:03 -0000 Subject: [GHC] #15994: Duplicate entries in -ddump-minimal-imports In-Reply-To: <046.88a9af819dfcf472c705a5200c69b937@haskell.org> References: <046.88a9af819dfcf472c705a5200c69b937@haskell.org> Message-ID: <061.9383b175c6725538b07d3bffa69fe318@haskell.org> #15994: Duplicate entries in -ddump-minimal-imports -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T15994 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_compile/T15994 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 10:44:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 10:44:14 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.62f1c67ab69dc0a02430583c7e84e9cc@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715, #13742 | Differential Rev(s): Phab:D5413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5413 Comment: I decided to be bold and just submit a patch for this. See Phab:D5413. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 11:47:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 11:47:58 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.2175ff9344d60c267fefc86fa34e56a7@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I ran a (profiled) hadrian build with shake `0.17.3` _and_ [https://phabricator.haskell.org/D5412 D5412], stopped it while hadrian was building `_build/stage1/libraries/base/`, resumed it and killed the program one I saw the first `| Run [...]` appear. I excluded all profiling symbols but the ones from hadrian itself (and only toplevel functions), and here is what the top of the profile looks like for that last short run I mentionned: {{{ Wed Dec 5 12:38 2018 Time and Allocation Profiling Report (Final) hadrian +RTS -I0 -qg -p -RTS --lint --directory /home/alp/WT /ghc-landing -j8 total time = 1.96 secs (7280 ticks @ 1000 us, 8 processors) total alloc = 4,152,119,656 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc buildProgram Rules.Program src/Rules/Program.hs:(19,1)-(73,51) 39.9 43.4 generatePackageCode Rules.Generate src/Rules/Generate.hs:(102,1)-(150,49) 6.1 2.9 buildPackageDependencies Rules.Dependencies src/Rules/Dependencies.hs:(15,1)-(35,52) 5.5 3.1 libraryObjects Rules.Library src/Rules/Library.hs:(113,1)-(127,67) 5.3 3.2 textFileOracle Hadrian.Oracles.TextFile src/Hadrian/Oracles/TextFile.hs:(88,1)-(100,83) 4.9 1.6 configurePackage Rules.Register src/Rules/Register.hs:(24,1)-(27,38) 3.2 1.7 argsHashOracle Hadrian.Oracles.ArgsHash src/Hadrian/Oracles/ArgsHash.hs:(47,1)-(51,36) 2.2 1.9 readContextData Hadrian.Oracles.Cabal src/Hadrian/Oracles/Cabal.hs:34:1-44 2.2 2.4 get Hadrian.Oracles.Cabal.Type src/Hadrian/Oracles/Cabal/Type.hs:43:15-20 2.2 1.5 ? Hadrian.Expression src/Hadrian/Expression.hs:(74,1)-(76,30) 1.7 2.1 unifyPath Hadrian.Utilities src/Hadrian/Utilities.hs:132:1-36 1.7 3.2 main Main src/Main.hs:(20,1)-(58,65) 1.4 3.8 == Hadrian.Oracles.TextFile src/Hadrian/Oracles/TextFile.hs:70:23-24 1.2 0.0 readPackageData Hadrian.Oracles.Cabal src/Hadrian/Oracles/Cabal.hs:28:1-44 1.1 0.9 lookupValue Hadrian.Oracles.TextFile src/Hadrian/Oracles/TextFile.hs:30:1-55 1.1 1.7 <> Hadrian.Expression src/Hadrian/Expression.hs:35:5-46 0.9 1.1 -/- Hadrian.Utilities src/Hadrian/Utilities.hs:(136,1)-(139,34) 0.8 2.4 input Hadrian.Expression src/Hadrian/Expression.hs:134:1-35 0.6 1.2 rtsPackageArgs Settings.Packages src/Settings/Packages.hs:(170,1)-(301,73) 0.4 1.0 mappend Hadrian.Expression src/Hadrian/Expression.hs:40:5-18 0.4 1.1 cabalOracle Hadrian.Oracles.Cabal.Rules src/Hadrian/Oracles/Cabal/Rules.hs:(38,1)-(60,58) 0.3 1.2 get Hadrian.Oracles.ArgsHash src/Hadrian/Oracles/ArgsHash.hs:41:15-20 0.2 2.2 }}} `buildProgram` stands out, as we seem to be spending more than a third of our time there. Everything else looks perfectly reasonable. I will give a very quick shot at trying to understand why we spend so much time in `buildProgram`, and if I do understand and see a way to cut this down, I'll write a patch, otherwise we can probably work with few-seconds pauses for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 13:30:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 13:30:31 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.b75f4f23685e127ba3513e78105af32f@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: closed Priority: high | Milestone: 8.8.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: #15393 | Differential Rev(s): Phab:D5312 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've added some text to the 8.8 Migration Guide in wiki:Migration/8.8?version=7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 13:44:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 13:44:02 -0000 Subject: [GHC] #15762: ghci command: report function's inferred visible type applications In-Reply-To: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> References: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> Message-ID: <066.70fd849f1a149d70f50ecb580f69e136@haskell.org> #15762: ghci command: report function's inferred visible type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13480 #15610 | Differential Rev(s): #15613 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #15610 #15613 => #13480 #15610 #15613 Comment: Is this a duplicate of #13480? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 13:44:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 13:44:24 -0000 Subject: [GHC] #13480: GHCi display visible type application In-Reply-To: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> References: <051.3355deef794e43c9dbb04fa5a1a371e8@haskell.org> Message-ID: <066.aa72fe2dc60f5a38a231a84e79f3f9e6@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, #15762 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #8751 => #8751, #15762 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 15:47:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 15:47:10 -0000 Subject: [GHC] #15995: Make Control.Concurrent.QSem a newtype Message-ID: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> #15995: Make Control.Concurrent.QSem a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 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: -------------------------------------+------------------------------------- {{{#!hs data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} I think this should be a newtype. The strictness annotations on the outter `MVar` could just be at each site where pattern matching on the `QSem`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 15:53:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 15:53:51 -0000 Subject: [GHC] #15996: Add Unlifted List type to base Message-ID: <046.6e24f84a6ceaff74937c7d525d35fc71@haskell.org> #15996: Add Unlifted List type to base -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 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: -------------------------------------+------------------------------------- {{{#!hs data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a }}} This would guarantee that values stored inside the list would not be thunks. It would likely live in something like GHC.List.Unlifted, since it uses GHC-specific things. An example of something it might improve is the implementation of Control.Concurrent.QSem.QSem: {{{#!hs data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} this could instead be: {{{#!hs type MVarIO = MVar# RealWorld -- type synonym for brevity data QSem = QSem (MVarIO (Int, UList (MVarIO ()), UList (MVarIO ()))) }}} Note that in this example the tuple inside the outermost `MVarIO` boxes the `Int` - this tuple could be represented as a datatype which ensures the unboxing on the `Int`. The main idea here though is that now you can use `MVar#` inside of the `UList`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:00:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:00:33 -0000 Subject: [GHC] #15997: EventManager could benefit from Data.Primitive.UnliftedArray Message-ID: <046.f897af973678b96078aff1fbbad9789a@haskell.org> #15997: EventManager could benefit from Data.Primitive.UnliftedArray -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 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: -------------------------------------+------------------------------------- {{{#!hs -- | The event manager state. data EventManager = EventManager { emBackend :: !Backend , emFds :: {-# UNPACK #-} !(Array Int (MVar (IntTable [FdData]))) , emState :: {-# UNPACK #-} !(IORef State) , emUniqueSource :: {-# UNPACK #-} !UniqueSource , emControl :: {-# UNPACK #-} !Control , emLock :: {-# UNPACK #-} !(MVar ()) } }}} the field in question is an `Array Int (MVar (IntTable [FdData]))`. `EventManager` could instead be: {{{#!hs type MVarIO = MVar# RealWorld -- type synonym for brevity -- | The event manager state. data EventManager = EventManager { emBackend :: !Backend , emFds :: {-# UNPACK #-} !(UnliftedArray (MVarIO (IntTable [FdData]))) , emState :: {-# UNPACK #-} !(IORef State) , emUniqueSource :: {-# UNPACK #-} !UniqueSource , emControl :: {-# UNPACK #-} !Control , emLock :: {-# UNPACK #-} !(MVar ()) } }}} now the `UnliftedArray` contains non-thunks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:10:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:10:27 -0000 Subject: [GHC] #11962: Support induction recursion In-Reply-To: <047.045273ef2ac55a0385e215af795b4757@haskell.org> References: <047.045273ef2ac55a0385e215af795b4757@haskell.org> Message-ID: <062.335b9b455d83247b395ff30d002911da@haskell.org> #11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9269 | Blocking: Related Tickets: #12612, #13901, | Differential Rev(s): #15942 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #12612, #13901 => #12612, #13901, #15942 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:10:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:10:41 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types In-Reply-To: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> References: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> Message-ID: <066.42b3b309bf96713c981071fba1a19e52@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | 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: #11962, #15942 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11962 => #11962, #15942 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:12:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:12:32 -0000 Subject: [GHC] #15942: Associated type family can't be used at the kind level within other parts of parent class (was: Type family used invisibly (with Visible Kind Applications)) In-Reply-To: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> References: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> Message-ID: <066.8b6a6eda6eccc2e481ad38df33f1fd2b@haskell.org> #15942: Associated type family can't be used at the kind level within other parts of parent class -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962, #12612 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11962, #12612 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:21:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:21:53 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.178406cf577e071a12ed293f6362a88e@haskell.org> #9091: print and/or apply constraints when showing info for typed holes -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9479, #14273, | Differential Rev(s): #15677 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #9479, #14273 => #9479, #14273, #15677 Comment: I believe Example 3 is another occurrence of #15677 (in deep disguise). I'll keep that ticket open, since it contains more information how one might want to implement a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:23:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:23:30 -0000 Subject: [GHC] #15677: Valid hole fits and GADT type variable names In-Reply-To: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> References: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> Message-ID: <065.c710bad7b3f91c7252d3d0cc0a5a2527@haskell.org> #15677: Valid hole fits and GADT type variable names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles, | GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #9091 Comment: Example 3 in #9091 is likely another example of this phenomenon: {{{#!hs data X a where Y :: X Int h :: X a -> a -> a h Y x = _ }}} {{{ Found hole ‘_’ with type: Int Relevant bindings include x :: a (bound at THC.hs:13:5) h :: X a -> a -> a (bound at THC.hs:13:1) In the expression: _ In an equation for ‘h’: h Y x = _ }}} Note that in the list of relevant bindings, in reports that `x` is of type `a`, although it would be more informative to report it as having type `Int` due to the GADT pattern match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:25:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:25:44 -0000 Subject: [GHC] #15998: GHC.Event.Thread.eventManager has a lot of indirections Message-ID: <046.c1a4a50d15b7cb78b0d20ecacec2e37f@haskell.org> #15998: GHC.Event.Thread.eventManager has a lot of indirections -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 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: -------------------------------------+------------------------------------- Current `eventManager`: {{{#!hs eventManager :: IORef (IOArray Int (Maybe (ThreadId, EventManager))) eventManager = unsafePerformIO $ do ... }}} That's a lot of indirections just to grab your thread's event manager. Consider the following, which I believe would improve the performance of this: {{{#!hs data UnliftedIORef :: TYPE 'UnliftedRep -> Type where UnliftedIORef :: MutVar# RealWorld a -> UnliftedIORef a eventManager :: UnliftedIORef (MutableArray# RealWorld Things) data Things = Things !ThreadId !EventManager }}} I think the Maybe can be eliminated. I'm unsure. What makes me think it can be is the following snippet: {{{#!hs getSystemEventManager :: IO (Maybe EventManager) getSystemEventManager = do t <- myThreadId (cap, _) <- threadCapability t eventManagerArray <- readIORef eventManager mmgr <- readIOArray eventManagerArray cap return $ fmap snd mmgr getSystemEventManager_ :: IO EventManager getSystemEventManager_ = do Just mgr <- getSystemEventManager return mgr {-# INLINE getSystemEventManager_ #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:28:06 -0000 Subject: [GHC] #15677: Valid hole fits and GADT type variable names In-Reply-To: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> References: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> Message-ID: <065.bf75293da67b158c921cdea811bd5cad@haskell.org> #15677: Valid hole fits and GADT type variable names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles, | GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Well, at least the situation for #9091 is a bit better now, with constraints shown by default: {{{ tritlo at nietzsche:~/Code$ ghc t9091.hs -XGADTs [1 of 1] Compiling T9091 ( t9091.hs, t9091.o ) t9091.hs:7:9: error: • Found hole: _ :: Int • In the expression: _ In an equation for ‘h’: h Y x = _ • Relevant bindings include x :: a (bound at t9091.hs:7:5) h :: X a -> a -> a (bound at t9091.hs:7:1) Constraints include a ~ Int (from t9091.hs:7:3) Valid hole fits include x :: a (bound at t9091.hs:7:5) maxBound :: forall a. Bounded a => a with maxBound @Int (imported from ‘Prelude’ at t9091.hs:1:8-12 (and originally defined in ‘GHC.Enum’)) minBound :: forall a. Bounded a => a with minBound @Int (imported from ‘Prelude’ at t9091.hs:1:8-12 (and originally defined in ‘GHC.Enum’)) | 7 | h Y x = _ }}} but this is still an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:30:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:30:47 -0000 Subject: [GHC] #15677: Valid hole fits and GADT type variable names In-Reply-To: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> References: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> Message-ID: <065.ac85b2a53144446a2e04d098e5cc15fb@haskell.org> #15677: Valid hole fits and GADT type variable names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles, | GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oops! I missed the `a ~ Int` part. Indeed, that's much better (and I might even go as far as saying that that fixes that particular buglet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:31:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:31:53 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.7dafce5a4e42b53e85ea2fc2500b817a@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I guess https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38 should have been posted here, as this ticket is clearly more focused on runtime measurements. Just posting this here for reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:41:56 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.b1a1da4f07eca9ff449c8aa4bc6355dc@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: AndreasK => (none) Comment: I opened this one to track the work I ended up doing in Phab:D4989. Which was essentially an excercise in number tweaking and which I consider done. There is no reason why we can't expand the scope of this ticket by the points raised in your other comment though if you feel they are better suited to be discussed seperately form making nofib awesome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:48:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:48:10 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.748af40b2fda67e01e8233f6f20490d1@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Phab:D5351 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"5f1d949ab9e09b8d95319633854b7959df06eb58/ghc" 5f1d949/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f1d949ab9e09b8d95319633854b7959df06eb58" Remove explicit recursion in retainer profiling (fixes #14758) Retainer profiling contained a recursion that under certain circumstances could lead to the stack overflow in C code. The idea of the improvement is to keep an explicit stack for the object, more precise to reuse existing stack, but allow new type of objects to be stored there. There is no reliable reproducer that is not a big program but in some cases foldr (+) 0 [1..10000000] can work. Reviewers: bgamari, simonmar, erikd, osa1 Reviewed By: bgamari, osa1 Subscribers: osa1, rwbarton, carter GHC Trac Issues: #14758 Differential Revision: https://phabricator.haskell.org/D5351 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:48:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:48:36 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.7c0375d00a3884104d5678042c3094b9@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Phab:D5351 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 16:59:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 16:59:54 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.3d58f475739adb9b56e0441c83166a9c@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: patch => closed * resolution: => fixed Comment: Right. Let's close this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:08:34 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.b08a2a21c9a76f558ea7147b4cd16049@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by davide): My commit (79d5427e1f9d) breaks the hadrian build in some cases. When building the default flavour, the ghc binary is linked with -lffi. When there is no system wide libffi .so installed, this will fail, even though there should be a locally built libffi. Here is an example of the command line generated by hadrian: {{{ $ _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -fPIC -dynamic -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-package-id array-0.5.2.0' '-package-id base-4.12.0.0' '-package-id bytestring-0.10.9.0' '-package-id containers-0.6.0.1' '-package-id deepseq-1.4.4.0' '-package-id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id ghc-8.7' '-package-id ghc-boot-8.7' '-package-id ghc-prim-0.5.3' '-package-id ghci-8.7' '-package-id haskeline-0.7.4.3' '-package-id process-1.6.3.0' '-package-id time-1.9.2' '-package-id transformers-0.5.5.0' '-package-id unix-2.7.2.2' -i -i_build/stage1/ghc/build -i_build/stage1/ghc/build/ghc/autogen -ighc/. -Iincludes -I_build/generated -I_build/stage1/ghc/build -I/nix/store /x5ms5m9ga6v7vy3akc58yx279ggfnbnl-ghc-build-environment/include -I/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64-linux- ghc-8.7.20181205/ghc-8.7/include -I/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64-linux- ghc-8.7.20181205/process-1.6.3.0/include -I/home/david/MEGA/File_Dump /Well-Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64 -linux-ghc-8.7.20181205/unix-2.7.2.2/include -I/home/david/MEGA/File_Dump /Well-Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64 -linux-ghc-8.7.20181205/time-1.9.2/include -I/home/david/MEGA/File_Dump /Well-Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64 -linux-ghc-8.7.20181205/bytestring-0.10.9.0/include -I/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64-linux- ghc-8.7.20181205/base-4.12.0.0/include -I/nix/store /x5ms5m9ga6v7vy3akc58yx279ggfnbnl-ghc-build-environment/include -I/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64-linux- ghc-8.7.20181205/integer-gmp-1.0.2.0/include -I/home/david/MEGA/File_Dump /Well-Typed/GHC/_nosync_git/_build/T-15837_default/stage1/lib/x86_64 -linux-ghc-8.7.20181205/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/ghc/build/ghc/autogen/cabal_macros.h -optc-fno-stack- protector -optP-DGHCI -odir _build/stage1/ghc/build -hidir _build/stage1/ghc/build -stubdir _build/stage1/ghc/build -dynamic -optl- Wl,-rpath -optl-Wl,$ORIGIN/../lib/x86_64-linux-ghc-8.7.20181205 -no-auto- link-packages -no-hs-main -optl-lgmp -Wnoncanonical-monad-instances -optc- Werror=unused-but-set-variable -optc-Wno-error=inline _build/stage1/ghc/build/c/hschooks.o _build/stage1/ghc/build/Main.o _build/stage1/ghc/build/GHCi/Leak.o _build/stage1/ghc/build/GHCi/UI.o _build/stage1/ghc/build/GHCi/UI/Info.o _build/stage1/ghc/build/GHCi/UI/Monad.o _build/stage1/ghc/build/GHCi/UI/Tags.o -o _build/stage1/bin/ghc -O2 -H32m -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno-warn-name-shadowing -threaded -XHaskell2010 -XNoImplicitPrelude -ghcversion- file=/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -I_build/stage1/compiler/build -Wcpp-undef }}} Note that there is no mention of libffi (i.e. no use of `-lffi`). Ghc sees rts as a dependency, and sees `hs-libraries: HSrts-1.0 Cffi` in the ghc- pkg database and then adds `-lffi` to the linking command. Further more, bgamari has suggested that we may not be supposed to link with libffi. We build libffi via hadrian but don't generate a .so. Instead we copy the same .a file as as both an .a and an .so for all flavours {{{ | Copy file: _build/stage1/libffi/build/inst/include/ffi.h => _build/stage1/rts/build/ffi.h | Copy file: _build/stage1/libffi/build/inst/include/ffitarget.h => _build/stage1/rts/build/ffitarget.h | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_p.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi-ghc8.7.20181126.so | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_thr.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_thr_p.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_debug_p.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_thr_debug_p.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_l.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_thr_l.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_debug.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi_thr_debug.a | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi-ghc8.7.20181126_thr.so | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi-ghc8.7.20181126_debug.so | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi-ghc8.7.20181126_l.so | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi-ghc8.7.20181126_thr_debug.so | Copy file (untracked): _build/stage1/libffi/build/inst/lib/libffi.a => _build/stage1/rts/build/libCffi-ghc8.7.20181126_thr_l.so }}} Though this may work for the .a files, it wont work for the .so. It's an easy fix to also build the .so and copy that instead: * modify `hadrian/src/Settings/Builders/Configure.hs` to use `--enable- shared=yes` when the way is dynamic. * modify `hadrian/src/Rules/Libffi.hs` to copy .so instead of .a when the way is dynamic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:09:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:09:24 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.fae3690aeb2969b654294c1d923960b3@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Changes (by davide): * status: closed => new * owner: davide => (none) * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:09:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:09:42 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.a2d6e884482152d32dd56caae2ccfd22@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:18:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:18:16 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements Message-ID: <044.a19ed52539721cf2881ee184b716feca@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: 8.6.2 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5793 #9476 | #15333 #15357 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With Phab:D4989 (cf. #15357) having hit `nofib` master, there are still many benchmarks that are unstable. I identified three causes for unstability in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38. With system overhead mostly out of the equation, there are still two related tasks left: 1. Identify benchmarks with GC wibbles. Plan: Look at counted instructions while varying heap size with just one generation. A wibbling benchmark should have quite diverse sampled maximum residency (as opposed to a microbenchmark, which should have quite stable instruction count). Then fix these by iterating `main` 'often enough'. Maybe look at total bytes allocated for that, we want this to be monotonically declining as the initial heap size grows. 2. Now, all benchmarks should have stable instruction count. If not, maybe there's another class of benchmarks I didn't identify yet in #5793. Of these benchmarks, there are a few, like `real/eff/CS`, that still have highly unstable runtimes. Fix these 'microbenchmarks' by hiding them behind a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:20:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:20:44 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.96f940bbc4e074170f6a6db724129e8e@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > I blame non-determinism in code layout or some other caching effect until I have a better hypothesis. These are the candidats we want to flag away for runtime measurements, especially real/eff, or make them actually do something meaningful. They generally compile down to a loop of a handfull of instructions. So flipping an `if` (invert the condition, swap then and else expressions) can already lead to noteable differences as the cpu might need proccess one more instruction. For the really small loops we can also get counterintuitive behaviour. Eg I reduced on of them by one instruction and performance got slower because of instruction sheduling effects. Having an "effective runtime" modus that excludes these seems worthwhile. But I'm torn on excluding them by default. Ideally people would see these unexpected results. Then look at the generated code and be able to tell if the code is actually worse or if it's just one of these edge cases. But that requires a lot of low level knowledge, which not everyone has. So people might throw out perfectly good ideas/patches because of missleading nofib results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:36:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:36:27 -0000 Subject: [GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter Message-ID: <046.07a20fc376700f524edfc9f92497a641@haskell.org> #16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently (as of GHC 8.6.2), error messages that suggest RankNTypes also suggest Rank2Types, but Rank2Types are deprecated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 17:48:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 17:48:02 -0000 Subject: [GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter In-Reply-To: <046.07a20fc376700f524edfc9f92497a641@haskell.org> References: <046.07a20fc376700f524edfc9f92497a641@haskell.org> Message-ID: <061.01868167883afdeffc858a555453a22f@haskell.org> #16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Sorry if this seems trivial, I don't mean for it to sound demanding. I do intend to do this myself. I wanted to do so once GHC moves to GitLab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 19:41:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 19:41:02 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly Message-ID: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 Wed Dec 5 19:41:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 19:41:20 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly In-Reply-To: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> References: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> Message-ID: <060.8cfb0f075bd0ac60035dde7efddde742@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): doesn't seem to be any way for the user to set this as a flag -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 21:44:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 21:44:45 -0000 Subject: [GHC] #15995: Make Control.Concurrent.QSem a newtype In-Reply-To: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> References: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> Message-ID: <061.cabbb7a3ac514d9528030b303dbd41dd@haskell.org> #15995: Make Control.Concurrent.QSem a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: libraries/base | Version: 8.6.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 chessai): this goes for `QSemN` too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 22:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 22:58:37 -0000 Subject: [GHC] #15203: Wrong location reported for kind error In-Reply-To: <047.8501454750f2e11a207588647ae72525@haskell.org> References: <047.8501454750f2e11a207588647ae72525@haskell.org> Message-ID: <062.cefd354df4a04a902d2558f48539e841@haskell.org> #15203: Wrong location reported for kind error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): The location of this error has changed in GHC HEAD (perhaps due to 2257a86daa72db382eb927df12a718669d5491f8?): {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:24: error: • Couldn't match ‘k1’ with ‘k2’ • In the type synonym declaration for ‘T’ | 7 | type T (a :: k1) (b :: k2) = (a ~ b, Show (Proxy (a :: k1)), Show (Proxy (b :: k2))) | ^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:17:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:17:13 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) Message-ID: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: TypeFamilies | 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: -------------------------------------+------------------------------------- Here's a program: {{{#!hs {-# LANGUAGE TypeFamilies #-} module TypeFamilies where data A type family B (x :: *) :: * where A x = x }}} One would hope that GHC would reject that nonsensical equation for `B` that references `A`. On GHC 7.8 through 8.4, that is the case: {{{ $ /opt/ghc/8.4.4/bin/ghci Bug.hs GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling TypeFamilies ( Bug.hs, interpreted ) Bug.hs:6:3: error: • Mismatched type name in type family instance. Expected: B Actual: A • In the type family declaration for ‘B’ | 6 | A x = x | ^^^^^^^ }}} But GHC 8.6.2 and HEAD actually //accept// this program! Thankfully, GHC appears to just treat `A x = x` as though you had written `B x = x`, so it's not like this breaks type safety or anything. Still, this most definitely ought to be rejected. One interesting observation is that `B` having a CUSK appears to be important. If `B` doesn't have a CUSK, as in the following variant: {{{#!hs {-# LANGUAGE TypeFamilies #-} module TypeFamilies where data A type family B x where A x = x }}} Then GHC properly catches the mismatched use of `A`: {{{ $ /opt/ghc/8.6.2/bin/ghci Bug.hs GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling TypeFamilies ( Bug.hs, interpreted ) Bug.hs:6:3: error: • Mismatched type name in type family instance. Expected: B Actual: A • In the type family declaration for ‘B’ | 6 | A x = x | ^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:24:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:24:12 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.37919669b77607ee3748c2661d6cc2bf@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715, #13742 | Differential Rev(s): Phab:D5413 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I wish it was really fixed, but it isn't. Try this {{{ type family F2 b where F2 'True = () F2 'False = NotFound }}} That elicits {{{ T11621.hs:12:14: error: * Expected a type, but `NotFound' has kind `Constraint' * In the type `NotFound' In the type family declaration for `F2' | 12 | F 'False = NotFound | ^^^^^^^^ }}} GHC is generally very good about being robustly order-independent; nothing depends on the order in which the type inference engine encounters code. But this is a rare counter example. The hack is described in `Note [Inferring tuple kinds]` in `TcHsType`. In `F`, GHC sees `NotFound` first, and that tells it that the answer is `Constraint`. IN `F2` it sees `()` first and guesses (wrongly) `*`. So I would say not-fixed. I can think of ad-hoc ways to fix this -- such as having a built-in constraint `TK k` which means `k` must be either `*` or `Constraint`. But I have thus far lacked the time and energy to think it through enough or implement it. Especially since #11715 is still open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:25:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:25:34 -0000 Subject: [GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible In-Reply-To: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> References: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> Message-ID: <060.7983b181ce63af9639e9f59d4baa7436@haskell.org> #15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Let's go through this [http://downloads.haskell.org/~ghc/8.6.2/docs/html/users_guide/glasgow_exts.html #instance-lookup according to the user's guide]: > In the light of the overlap decision, instance lookup works like this when trying to solve a class constraint `C t` > > 1. First see if there is a given un-quantified constraint `C t`. If so, use it to solve the constraint. > 2. If not, look at all the available given quantified constraints; if exactly one one matches `C t`, choose it; if more than one matches, report an error. > 3. If no quantified constraints match, look up in the global instances, as described in ... When type checking the use of the `Coercion` constructor in `yeah`, we want `Coercible [Yeah a] [Yeah b]`. There are no given constraints (quantified or otherwise) matching that, so we use the global instance `Coercible x y => Coercible [x] [y]`, producing the wanted `Coercible (Yeah a) (Yeah b)`. We have no matching unquantified givens, so we look for quantified givens. We (should) have a match: `forall a b. Coercible (Yeah a) (Yeah b)`, which should solve the wanted. However, it ''appears'' that GHC is instead choosing the global instance `forall a b. Coercible a b => Coercible (Yeah a) (Yeah b)`, leading to an unsatisfiable `Coercible a b`. So I don't ''think'' the current behavior matches the user's guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:37:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:37:30 -0000 Subject: [GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible In-Reply-To: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> References: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> Message-ID: <060.0c4fd10ee4d218f80003eb532e7647bf@haskell.org> #15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): malo, I don't think the problem you're encountering is related at all. You're hoping that `forall i. Coercible (f i) (g i)` will satisfy the `type role Bar representational nominal` requirement. But we don't have such an extensionality rule. Perhaps we could add one somehow, but that would be quite independent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:38:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:38:08 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.daa0f0e1b26d5f9522d20c51bb6522ef@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715, #13742 | Differential Rev(s): Phab:D5413 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Good catch. Alas, I had a feeling this was too good to be true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:41:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:41:07 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family In-Reply-To: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> References: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> Message-ID: <066.3f54e131562506e6423627aab995e9fc@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11715, #13742 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => new * differential: Phab:D5413 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 5 23:59:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Dec 2018 23:59:32 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.695caf927d9471d532331161e24a0835@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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): This regression was introduced in commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 00:23:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 00:23:53 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.e82724b0db36c53475e2f78f7df60b35@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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): Ah, it's due to this change: {{{#!diff kcLTyClDecl :: LTyClDecl GhcRn -> TcM () -- See Note [Kind checking for type and class decls] kcLTyClDecl (L loc decl) + | hsDeclHasCusk decl + = traceTc "kcTyClDecl skipped due to cusk" (ppr tc_name) + | otherwise = setSrcSpan loc $ tcAddDeclCtxt decl $ - do { traceTc "kcTyClDecl {" (ppr (tyClDeclLName decl)) + do { traceTc "kcTyClDecl {" (ppr tc_name) ; kcTyClDecl decl - ; traceTc "kcTyClDecl done }" (ppr (tyClDeclLName decl)) } + ; traceTc "kcTyClDecl done }" (ppr tc_name) } + where + tc_name = tyClDeclLName decl }}} Note that `kcTyClDecl` (which performs the validity check needed to reject `A x = x` above) is only invoked when a type family declaration lacks a CUSK! NB: This code no longer exists in GHC HEAD, as it has since been refactored into [http://git.haskell.org/ghc.git/blob/5f1d949ab9e09b8d95319633854b7959df06eb58:/compiler/typecheck/TcTyClsDecls.hs#l484 kcTyClGroup]: {{{#!hs kcTyClGroup decls = do { ... ; let (cusk_decls, no_cusk_decls) = partition (hsDeclHasCusk . unLoc) decls ; ... ; mapM_ kcLTyClDecl no_cusk_decls ; ... } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 00:31:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 00:31:37 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.fecb86ff4a28518ddeaf91820bcf4c9d@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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): (Interestingly, this exact bit of code was also [https://ghc.haskell.org/trac/ghc/ticket/15116#comment:2 responsible] for causing #15116.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 04:33:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 04:33:48 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly In-Reply-To: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> References: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> Message-ID: <060.e842ea2eeb65bf54f37091bdaf3b8857@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates, snowleopard, alpmestan (added) Comment: Frustratingly enough, there isn't a direct way to do this in the Make system either (you're responsible for re-configuring `./libraries/integer- gmp/configure --with-intree-gmp`). I think this means that we'll need to tweak the toplevel `configure.ac`/`aclocal.m4` scripts to support `--with-intree-gmp` (and `--with-gmp-framework-preferred` while we're at it). My main question is: do we also need to make sure these new options do something for the old Make system too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 05:44:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 05:44:55 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.7188c516fdda1fdea9f498ff4eeb0af0@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): OK so it turns out I made a mistake in my testing and end up not testing anything. I submitted Phab:D5416 to fix a confusing variable naming which is what confused me. Currently I'm stuck with a weird error caused when I add one more `hscWriteIface` call after code generation, without changing the interface file (so I'm just writing the same interface file again, later in compilation). The diff to reproduce is: {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index a9e486c94a..c614d7f102 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -193,7 +193,7 @@ compileOne' m_tc_result mHscMessage o_time <- getModificationUTCTime object_filename let linkable = LM o_time this_mod [DotO object_filename] return hmi0 { hm_linkable = Just linkable } - (HscRecomp cgguts summary, HscInterpreted) -> do + (HscRecomp cgguts summary _iface, HscInterpreted) -> do (hasStub, comp_bc, spt_entries) <- hscInteractive hsc_env cgguts summary @@ -214,14 +214,14 @@ compileOne' m_tc_result mHscMessage let linkable = LM unlinked_time (ms_mod summary) (hs_unlinked ++ stub_o) return hmi0 { hm_linkable = Just linkable } - (HscRecomp cgguts summary, _) -> do + (HscRecomp cgguts summary iface, _) -> do output_fn <- getOutputFilename next_phase (Temporary TFL_CurrentModule) basename dflags next_phase (Just location) -- We're in --make mode: finish the compilation pipeline. _ <- runPipeline StopLn hsc_env (output_fn, - Just (HscOut src_flavour mod_name (HscRecomp cgguts summary))) + Just (HscOut src_flavour mod_name (HscRecomp cgguts summary iface))) (Just basename) Persistent (Just location) @@ -1104,13 +1104,13 @@ runPhase (HscOut src_flavour mod_name result) _ dflags = do basename = dropExtension input_fn liftIO $ compileEmptyStub dflags hsc_env' basename location mod_name return (RealPhase StopLn, o_file) - HscRecomp cgguts mod_summary + HscRecomp cgguts mod_summary iface -> do output_fn <- phaseOutputFilename next_phase PipeState{hsc_env=hsc_env'} <- getPipeState (outputFilename, mStub, foreign_files) <- liftIO $ - hscGenHardCode hsc_env' cgguts mod_summary output_fn + hscGenHardCode hsc_env' cgguts mod_summary iface output_fn stub_o <- liftIO (mapM (compileStub hsc_env') mStub) foreign_os <- liftIO $ mapM (uncurry (compileForeign hsc_env')) foreign_files diff --git a/compiler/main/HscMain.hs b/compiler/main/HscMain.hs index d7cebd00fc..198865d6e0 100644 --- a/compiler/main/HscMain.hs +++ b/compiler/main/HscMain.hs @@ -763,7 +763,7 @@ finish summary tc_result mb_old_hash = do desugared_guts <- hscSimplify' plugins desugared_guts0 (iface, changed, details, cgguts) <- liftIO $ hscNormalIface hsc_env desugared_guts mb_old_hash - return (iface, changed, details, HscRecomp cgguts summary) + return (iface, changed, details, HscRecomp cgguts summary iface) else mk_simple_iface liftIO $ hscMaybeWriteIface dflags iface changed summary return @@ -1292,10 +1292,10 @@ hscWriteIface dflags iface no_change mod_summary = do writeIfaceFile dynDflags dynIfaceFile' iface -- | Compile to hard-code. -hscGenHardCode :: HscEnv -> CgGuts -> ModSummary -> FilePath +hscGenHardCode :: HscEnv -> CgGuts -> ModSummary -> ModIface -> FilePath -> IO (FilePath, Maybe FilePath, [(ForeignSrcLang, FilePath)]) -- ^ @Just f@ <=> _stub.c is f -hscGenHardCode hsc_env cgguts mod_summary output_filename = do +hscGenHardCode hsc_env cgguts mod_summary iface output_filename = do let CgGuts{ -- This is the last use of the ModGuts in a compilation. -- From now on, we just use the bits we need. cg_module = this_mod, @@ -1327,6 +1327,11 @@ hscGenHardCode hsc_env cgguts mod_summary output_filename = do prof_init = profilingInitCode this_mod cost_centre_info foreign_stubs = foreign_stubs0 `appendStubC` prof_init + + ------ Overwrite iface file with new info ------------ + -- Generating iface again + hscWriteIface dflags iface False mod_summary + ------------------ Code generation ------------------ -- The back-end is streamed: each top-level function goes diff --git a/compiler/main/HscTypes.hs b/compiler/main/HscTypes.hs index d57d69bda6..15c7b1fb03 100644 --- a/compiler/main/HscTypes.hs +++ b/compiler/main/HscTypes.hs @@ -222,7 +222,7 @@ data HscStatus | HscUpToDate | HscUpdateBoot | HscUpdateSig - | HscRecomp CgGuts ModSummary + | HscRecomp CgGuts ModSummary !ModIface -- ----------------------------------------------------------------------------- -- The Hsc monad: Passing an environment and warning state }}} It looks large but all I'm doing is passing the `ModIface` to the code generator, and overwriting the interface file (without changing anything) after STG generation. If I build GHC with this patch I get weird errors like: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id ghc-prim-0.5.3 -hide-all-packages -i -ilibraries /ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim /dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O -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 -dynamic-too -c libraries /ghc-prim/./GHC/CString.hs -o libraries/ghc-prim/dist- install/build/GHC/CString.o -dyno libraries/ghc-prim/dist- install/build/GHC/CString.dyn_o libraries/ghc-prim/GHC/CString.hs:23:1: error: Bad interface file: libraries/ghc-prim/dist-install/build/GHC/Types.hi mismatched interface file ways (wanted "", got "dyn") | 23 | import GHC.Types | ^^^^^^^^^^^^^^^^ }}} I also tried writing the interface file _twice_ when we write it for the first time, just to make sure this isn't because we see a file and take a different code path and break things etc. but that's not the case, it works fine. So somehow if I overwrite it right after writing it, it's fine. But if I overwrite it later in compilation (after STG generation) things break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 07:22:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 07:22:36 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.20e2d51d26c967462102cafeafc60d86@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 07:35:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 07:35:24 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.0b10e1ab4a865ffcc1228ec0eec30688@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9883 Related Tickets: #9883 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) Comment: Lovely design in comment:11. I don't think anything stops us from extending it to support pattern matching and ranges by adding more classes for these features. Another use case that I have in mind is `NonEmpty`. As it stands, using it with `OverloadedLists` is unsafe, as `[]` will fail at run-time instead of compile-time. With the design of comment:11 we could do this: {{{#!hs instance Cons (NonEmpty a) where type Head (NonEmpty a) = a type Tail (NonEmpty a) = [a] cons = (:|) instance TypeError ... => Nil (NonEmpty a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 08:29:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 08:29:48 -0000 Subject: [GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible In-Reply-To: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> References: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> Message-ID: <060.a0b6a60079ebdff926440f0d47176e85@haskell.org> #15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So I don't think the current behavior matches the user's guide. That's probably true. The built-in rules for `Coercible` apply first. So we reduce `Coercible (Yeah a) (Yeah b)` to `Coercible a (Yeah b)` and thence to `Coercible a b`. All this before we even start to consider instances. It's a bit like type-class overlap. GHC doesn't have backtracking, and just picks one path. If you have overlap (as here, in this case between a quantified constraint and a built-in equality-decomposition rule) then GHC just picks one (in this case the built-in rule). The best thing is to avoid overlap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 08:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 08:36:25 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.b20a306f184665171d40ca8ab8aa2731@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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): Ah yes, good catch. I think the Right Thing is to move the test out of `kcTyFamInstEqn` and put it in `RnSource.rnFamInstEqn`. That way it'll be nailed by the renamer, which has plenty of information to give a good error message. Would you consider doing that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:04:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:04:22 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.fd5f637e4bda31b791c588c80d6a3002@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I propose dividing Step 2 into two. * '''Step 2a''': make `tcTypeKind` monadic, and get rid of the `naked` functions. This will fix #15799 and #15918. * '''Step 2b''': make `substTy` monadic too. After Step 2a, we still have * Invariant `(ForallInv)`: in a 'forall' type `forall a. blah`, all occurrences of `a` should still be visible in `blah` without zonking. So we don't need to make `substTy` monadic in Step 2a. Personally I think that Step 2b might not be worth the bother. Maintaining `(ForallInv)` is really not hard, whereas maintaining `Note [The well-kinded type invariant]` is extremely tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:07:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:07:58 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.d2320edb2ce44fa7d3bdbad3e4d30189@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): #15999 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #15357 #15333 => #15357 #15333 #15999 Comment: I opened #15999 to track the implicit task in comment:38. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:16:11 -0000 Subject: [GHC] #12893: Profiling defeats stream fusion when using vector library In-Reply-To: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> References: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> Message-ID: <062.99d3b383226bca7e282e39d42531cfc8@haskell.org> #12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: stream-fusion | profiling Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guaraqe): I think the problem that the OP is reporting is that there are no cost centers in the program, yet no optimization is done. There are no manual `SCC`s and compilation is done with `-fno-prof-count-entries -fno-prof- cafs -fno-prof-auto -O2`, so we would expect that there would be no barriers for optimization. This can be wrong if for some reason the GHC flags are not passed to the `vector` library, and it is still being compiled with automatic cost centers, which would indeed block fusion. If that is the case, it would be nice to have a way to pass these flags all the way down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:18:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:18:25 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.af28e21a40c15daea2552e06e5811cf9@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): When we execute Step 2a, there are two differences between `typeKind` and `tcTypeKind`: 1. `tcTypeKind` respects the distinction between `Constraint` and `Type`. Concretely, this means that `typeKind` uses `coreView` and `tcTypeKind` uses `tcView`; and the treatment of `FunTy` differs too. 2. `tcTypeKind` is monadic. This key change lets us remove some `zonkTcType`s, and all the `naked` business. These are separate issues. In `TcErrors`, for example, the types are all zonked, so (2) is not important; and yet making things monadic is a pain. So here's an idea: * '''Make `typeKind` respect the `Constraint`/`Type` distinction.''' So `typeKind (Eq Int)` would return `Constraint` rather than `Type`. But that doesn't matter! In Core-land, those two types are treated identically, so it doesn't matter if `typeKind` returns one vs the other! Then in `TcErrors` we can safely call the (pure) `typeKind`. --------------- To make `tcTypeKind` monadic we need a monadic version of `tcEqType`, because `tcEqType` calls `tcTypeKind` to compare the kinds of the two types. That may in any case be advantageous, because a monadic `tcEqType` will return True more often. We probably want to keep the pure version for occasions where we know the types are zonked. --------------- A couple of notes about `tcEqType`: * `tcEqType` currently returns `Maye Bool` to indicate that, when the types differ, whether they differ only in an invisible position. This is used just once, in `TcErrors`. Rather than return `Maybe Bool`, whith its assocaited allocation etc, I suggest we pass in a `Bool` flag saying whether to take invisible args into account. Then in `TcErrors` we can call `tcEqType` twice (with the flag set to True and False) and behave appropriately. This is only needed for the pure version (used in `TcErrors`). The monadic version ignores this visiblity stuff. * `tc_eq_type` currently takes a "view" function which is always `tcView`. Let's specialise to `tcView`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:30:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:30:31 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly In-Reply-To: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> References: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> Message-ID: <060.0ef6d8119ab506b62af924b6e66fcbee@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) Comment: In the make system you can uncomment/add {{{libraries/integer- gmp_CONFIGURE_OPTS += --configure-option=--with-intree-gmp}}} to your {{{mk/build.mk}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:30:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:30:48 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.d1bc4dac7b96a51decac2142ecafd190@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Old description: > The type checker currently maintains two invariants, documented in `Note > [The well-kinded type invariant]` in TcType and `Note [The tcType > invariant]` in TcHsType. These are a pain to maintain, and Simon and I > cooked up a plan not to. > > Step 1. The tcType invariant is all about `tcInferApps`, at least > according to the Note. Previously, we couldn't zonk in `tcInferApps`, > because types were knot-tied. But now we can! So, `tcInferApps` could > take the type only (not its kind), zonk it, then get the type's (zonked) > kind. This might also mean that `tc_infer_hs_type` no longer needs to > return a type/kind pair, but could just return a type. > > After this is done, we can likely remove all the zonks that are in > service to the tcType invariant, findable by a search. > > Step 2. The well-kinded type invariant is also about the need to zonk > sometimes. But, instead, we could just always zonk on-the-fly. That is, > we introduce new functions like `tcTypeKind` and `tcSubstTy` that zonk as > they go. To make sure we're calling the right function at the right time, > we introduce `newtype TcType = TcType { unTcType :: Type }`. Then, we're > forced to call monadic functions on `TcType`s. This will likely lead to > code duplication between `Type` and `TcType`, but we might be able to > banish `zonkTcType` (and its many friends) entirely. Also gone would be > the `naked` functions, which are all about maintaining the well-kinded > type invariant. This step would, as a side effect, fix #15799 and #15918, > which is about treating `TcType`s differently from `Type`s. New description: The type checker currently maintains two invariants, documented in `Note [The well-kinded type invariant]` in TcType and `Note [The tcType invariant]` in TcHsType. These are a pain to maintain, and Simon and I cooked up a plan not to. Step 1. The tcType invariant is all about `tcInferApps`, at least according to the Note. Previously, we couldn't zonk in `tcInferApps`, because types were knot-tied. But now we can! So, `tcInferApps` could take the type only (not its kind), zonk it, then get the type's (zonked) kind. This might also mean that `tc_infer_hs_type` no longer needs to return a type/kind pair, but could just return a type. After this is done, we can likely remove all the zonks that are in service to the tcType invariant, findable by a search. Step 2. The well-kinded type invariant is also about the need to zonk sometimes. But, instead, we could just always zonk on-the-fly. That is, we introduce new functions like `tcTypeKind` and `tcSubstTy` that zonk as they go. To make sure we're calling the right function at the right time, we introduce `newtype TcType = TcType { unTcType :: Type }`. Then, we're forced to call monadic functions on `TcType`s. This will likely lead to code duplication between `Type` and `TcType`, but we might be able to banish `zonkTcType` (and its many friends) entirely. Also gone would be the `naked` functions, which are all about maintaining the well-kinded type invariant. This step would, as a side effect, fix #15799 and #15918, which is about treating `TcType`s differently from `Type`s. '''Work in progress on `wip/T15952`''' -- Comment (by simonpj): Commits on `wip/T15952`: {{{ commit b169960c5ed45a7b6fa35d2dbcb66f44128f6a38 Author: Simon Peyton Jones Date: Wed Dec 5 08:43:59 2018 +0000 Start on Trac #15952 Actually it's working pretty well. Just one error message regression in typecheck/should_fail/T15629. }}} and {{{ commit 79d031326d614f6ca637b67a11949dab64afe728 Author: Simon Peyton Jones Date: Wed Dec 5 12:25:14 2018 +0000 Remove TcKind result for tc_infer_hs_type More cleaning up All works except a couple or piResultTys crashes in polykinds/T11399 polykinds/T14174a due to using substTy (rather than nakedSubstTy) in piResultTys }}} and {{{ commit a99a43bbb7a8a506f31307591b3ee8e9ba3c4c6f Author: Simon Peyton Jones Date: Thu Dec 6 09:24:44 2018 +0000 Make tcTypeKind monadic This patch is work in progress on Trac #15952. IT DOES NOT COMPILE. The main payload is progress towards making tcTypeKind monadic. However I have not yet made a monadic version of tcEqType, nor changed all those tcEqType calls to a monadic context. Hence, it won't compile as-is. I'm just parking the work I've done, on a branch, until I've had a chance to agree the path with Richard. (The previous patches on this branch /do/ compile and almost-completely validate.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 09:59:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 09:59:06 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.bbbd41de8ded40b42ac01b0837f4553f@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by davide): Note that the make build system succeeds and can be used as a reference here. Here is the verbose (-v3) output of the make build command that builds/links the ghc binary: {{{ # Model ghc build (make default) "inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -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 array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.9.0 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.1 -package-id filepath-1.4.2.1 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id ghc-prim-0.5.3 -package-id ghci-8.7 -package-id haskeline-0.7.4.3 -package-id process-1.6.3.0 -package-id time-1.9.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno- warn-name-shadowing -threaded -XHaskell2010 -XNoImplicitPrelude -O2 -haddock -Wcpp-undef -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -fPIC -dynamic -H32m -O -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 array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.9.0 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.1 -package-id filepath-1.4.2.1 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id ghc-prim-0.5.3 -package-id ghci-8.7 -package-id haskeline-0.7.4.3 -package-id process-1.6.3.0 -package-id time-1.9.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno-warn-name-shadowing -threaded -XHaskell2010 -XNoImplicitPrelude -O2 -haddock -Wcpp-undef -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -fno-use-rpaths -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../haskeline-0.7.4.3' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../stm-2.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-8.7' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../terminfo-0.4.1.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../process-1.6.3.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../hpc-0.6.0.3' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghci-8.7' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../transformers-0.5.5.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../template-haskell-2.15.0.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../pretty-1.1.3.6' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc- heap-8.7' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-boot-8.7' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-boot-th-8.7' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../directory-1.3.3.1' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../unix-2.7.2.2' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../time-1.9.2' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../filepath-1.4.2.1' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../binary-0.8.6.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../containers-0.6.0.1' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../bytestring-0.10.9.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../deepseq-1.4.4.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../array-0.5.2.0' -optl-Wl,-rpath -optl- Wl,'$ORIGIN/../base-4.12.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN /../integer-gmp-1.0.2.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc- prim-0.5.3' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts' -optl-Wl,-zorigin ghc/stage2/build/Main.dyn_o ghc/stage2/build/GHCi/Leak.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 Glasgow Haskell Compiler, Version 8.7.20181205, stage 1 booted by GHC version 8.4.4 Using binary package database: /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/inplace/lib/package.conf.d/package.cache package flags [-package-id array-0.5.2.0{unit array-0.5.2.0 True ([])}, -package-id base-4.12.0.0{unit base-4.12.0.0 True ([])}, -package-id bytestring-0.10.9.0{unit bytestring-0.10.9.0 True ([])}, -package-id containers-0.6.0.1{unit containers-0.6.0.1 True ([])}, -package-id deepseq-1.4.4.0{unit deepseq-1.4.4.0 True ([])}, -package-id directory-1.3.3.1{unit directory-1.3.3.1 True ([])}, -package-id filepath-1.4.2.1{unit filepath-1.4.2.1 True ([])}, -package-id ghc-8.7{unit ghc-8.7 True ([])}, -package-id ghc-boot-8.7{unit ghc-boot-8.7 True ([])}, -package-id ghc-prim-0.5.3{unit ghc-prim-0.5.3 True ([])}, -package-id ghci-8.7{unit ghci-8.7 True ([])}, -package-id haskeline-0.7.4.3{unit haskeline-0.7.4.3 True ([])}, -package-id process-1.6.3.0{unit process-1.6.3.0 True ([])}, -package-id time-1.9.2{unit time-1.9.2 True ([])}, -package-id transformers-0.5.5.0{unit transformers-0.5.5.0 True ([])}, -package-id unix-2.7.2.2{unit unix-2.7.2.2 True ([])}, -package-id array-0.5.2.0{unit array-0.5.2.0 True ([])}, -package-id base-4.12.0.0{unit base-4.12.0.0 True ([])}, -package-id bytestring-0.10.9.0{unit bytestring-0.10.9.0 True ([])}, -package-id containers-0.6.0.1{unit containers-0.6.0.1 True ([])}, -package-id deepseq-1.4.4.0{unit deepseq-1.4.4.0 True ([])}, -package-id directory-1.3.3.1{unit directory-1.3.3.1 True ([])}, -package-id filepath-1.4.2.1{unit filepath-1.4.2.1 True ([])}, -package-id ghc-8.7{unit ghc-8.7 True ([])}, -package-id ghc-boot-8.7{unit ghc-boot-8.7 True ([])}, -package-id ghc-prim-0.5.3{unit ghc-prim-0.5.3 True ([])}, -package-id ghci-8.7{unit ghci-8.7 True ([])}, -package-id haskeline-0.7.4.3{unit haskeline-0.7.4.3 True ([])}, -package-id process-1.6.3.0{unit process-1.6.3.0 True ([])}, -package-id time-1.9.2{unit time-1.9.2 True ([])}, -package-id transformers-0.5.5.0{unit transformers-0.5.5.0 True ([])}, -package-id unix-2.7.2.2{unit unix-2.7.2.2 True ([])}] loading package database /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.15.0.0 wired-in package ghc mapped to ghc-8.7 ("getPreloadPackagesAnd pkgids:",[]) ("getPreloadPackagesAnd preload:",["haskeline-0.7.4.3","stm-2.5.0.0","ghc","terminfo-0.4.1.2","process-1.6.3.0","hpc-0.6.0.3","ghci-8.7","transformers-0.5.5.0 ","template-haskell","pretty-1.1.3.6","ghc-heap-8.7","ghc-boot-8.7","ghc- boot- th-8.7","binary-0.8.6.0","directory-1.3.3.1","unix-2.7.2.2","time-1.9.2","filepath-1.4.2.1","containers-0.6.0.1","bytestring-0.10.9.0","deepseq-1.4.4.0","array-0.5.2.0","base ","integer-wired-in","ghc-prim","rts"]) Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. Created temporary directory: /run/user/1000/ghc13514_0 *** C Compiler: /nix/store/qanjz18apdwi0vl98sdrvyf4z4hv65df-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -c /run/user/1000/ghc13514_0/ghc_1.c -o /run/user/1000/ghc13514_0/ghc_2.o -no-pie -fPIC -U__PIC__ -D__PIC__ -I/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/rts/dist/build -I/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/includes -I/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/includes/dist- derivedconstants/header ("getPreloadPackagesAnd pkgids:",[]) ("getPreloadPackagesAnd preload:",["haskeline-0.7.4.3","stm-2.5.0.0","ghc","terminfo-0.4.1.2","process-1.6.3.0","hpc-0.6.0.3","ghci-8.7","transformers-0.5.5.0 ","template-haskell","pretty-1.1.3.6","ghc-heap-8.7","ghc-boot-8.7","ghc- boot- th-8.7","binary-0.8.6.0","directory-1.3.3.1","unix-2.7.2.2","time-1.9.2","filepath-1.4.2.1","containers-0.6.0.1","bytestring-0.10.9.0","deepseq-1.4.4.0","array-0.5.2.0","base ","integer-wired-in","ghc-prim","rts"]) @@@ Stripping prefix for "Cffi" to "ffi" for package "rts" ("collectLinkOpts",(["-lHShaskeline-0.7.4.3-ghc8.7.20181205","-lHSstm-2.5.0.0-ghc8.7.20181205","-lHSghc-8.7-ghc8.7.20181205","-lHSterminfo-0.4.1.2-ghc8.7.20181205","-lHSprocess-1.6.3.0-ghc8.7.20181205","-lHShpc-0.6.0.3-ghc8.7.20181205","-lHSghci-8.7-ghc8.7.20181205","-lHStransformers-0.5.5.0-ghc8.7.20181205 ","-lHStemplate- haskell-2.15.0.0-ghc8.7.20181205","-lHSpretty-1.1.3.6-ghc8.7.20181205 ","-lHSghc-heap-8.7-ghc8.7.20181205","-lHSghc-boot-8.7-ghc8.7.20181205 ","-lHSghc-boot- th-8.7-ghc8.7.20181205","-lHSbinary-0.8.6.0-ghc8.7.20181205","-lHSdirectory-1.3.3.1-ghc8.7.20181205","-lHSunix-2.7.2.2-ghc8.7.20181205","-lHStime-1.9.2-ghc8.7.20181205","-lHSfilepath-1.4.2.1-ghc8.7.20181205","-lHScontainers-0.6.0.1-ghc8.7.20181205","-lHSbytestring-0.10.9.0-ghc8.7.20181205","-lHSdeepseq-1.4.4.0-ghc8.7.20181205","-lHSarray-0.5.2.0-ghc8.7.20181205","-lHSbase-4.12.0.0-ghc8.7.20181205 ","-lHSinteger-gmp-1.0.2.0-ghc8.7.20181205","-lHSghc- prim-0.5.3-ghc8.7.20181205","-lHSrts_thr- ghc8.7.20181205","-lffi"],["-ltinfo","-lrt","-lutil","-ldl","-lgmp","-lm","-lrt","-ldl","-lnuma"],["-Wl,-u,base_GHCziTopHandler_runIO_closure","-Wl,-u,base_GHCziTopHandler_runNonIO_closure","-Wl,-u,ghczmprim_GHCziTuple_Z0T_closure","-Wl,-u,ghczmprim_GHCziTypes_True_closure","-Wl,-u,ghczmprim_GHCziTypes_False_closure","-Wl,-u,base_GHCziPack_unpackCString_closure","-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure","-Wl,-u,base_GHCziIOziException_stackOverflow_closure","-Wl,-u,base_GHCziIOziException_heapOverflow_closure","-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure","-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure","-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure","-Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure","-Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure","-Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure","-Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure","-Wl,-u,base_Controlz iExceptionziBase_nonTermination_closure","-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure","-Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure","-Wl,-u,base_GHCziConcziSync_runSparks_closure","-Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure","-Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure","-Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure","-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure","-Wl,-u,base_GHCziTopHandler_runMainIO_closure","-Wl,-u,ghczmprim_GHCziTypes_Czh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Izh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info","-Wl,-u,base_GHCziPtr_Ptr_con_info","-Wl,-u,base_GHCziPtr_FunPtr_con_info","-Wl,-u,base_GHCziInt_I8zh_con_info","-Wl,-u,base_GHCziInt_I16zh_con_info","-Wl,-u,base_GHCziInt_I32zh_con_info","-Wl,-u,base_GHCziInt_I64zh_con_info","-Wl,-u,base_GHCziWord_W8zh_con_info","-Wl,-u,base_GHCziWord_W16 zh_con_info","-Wl,-u,base_GHCziWord_W32zh_con_info","-Wl,-u,base_GHCziWord_W64zh_con_info","-Wl,-u,base_GHCziStable_StablePtr_con_info","-Wl,-u,hs_atomic_add8","-Wl,-u,hs_atomic_add16","-Wl,-u,hs_atomic_add32","-Wl,-u,hs_atomic_add64","-Wl,-u,hs_atomic_sub8","-Wl,-u,hs_atomic_sub16","-Wl,-u,hs_atomic_sub32","-Wl,-u,hs_atomic_sub64","-Wl,-u,hs_atomic_and8","-Wl,-u,hs_atomic_and16","-Wl,-u,hs_atomic_and32","-Wl,-u,hs_atomic_and64","-Wl,-u,hs_atomic_nand8","-Wl,-u,hs_atomic_nand16","-Wl,-u,hs_atomic_nand32","-Wl,-u,hs_atomic_nand64","-Wl,-u,hs_atomic_or8","-Wl,-u,hs_atomic_or16","-Wl,-u,hs_atomic_or32","-Wl,-u,hs_atomic_or64","-Wl,-u,hs_atomic_xor8","-Wl,-u,hs_atomic_xor16","-Wl,-u,hs_atomic_xor32","-Wl,-u,hs_atomic_xor64","-Wl,-u,hs_cmpxchg8","-Wl,-u,hs_cmpxchg16","-Wl,-u,hs_cmpxchg32","-Wl,-u,hs_cmpxchg64","-Wl,-u,hs_atomicread8","-Wl,-u,hs_atomicread16","-Wl,-u,hs_atomicread32","-Wl,-u,hs_atomicread64","-Wl,-u,hs_atomicwrite8","-Wl,-u,hs_atomicwrite16","-Wl,-u,hs_atomicwrite32","-Wl ,-u,hs_atomicwrite64"])) *** C Compiler: /nix/store/qanjz18apdwi0vl98sdrvyf4z4hv65df-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -c /run/user/1000/ghc13514_0/ghc_4.s -o /run/user/1000/ghc13514_0/ghc_5.o ("getPreloadPackagesAnd pkgids:",[]) ("getPreloadPackagesAnd preload:",["haskeline-0.7.4.3","stm-2.5.0.0","ghc","terminfo-0.4.1.2","process-1.6.3.0","hpc-0.6.0.3","ghci-8.7","transformers-0.5.5.0 ","template-haskell","pretty-1.1.3.6","ghc-heap-8.7","ghc-boot-8.7","ghc- boot- th-8.7","binary-0.8.6.0","directory-1.3.3.1","unix-2.7.2.2","time-1.9.2","filepath-1.4.2.1","containers-0.6.0.1","bytestring-0.10.9.0","deepseq-1.4.4.0","array-0.5.2.0","base ","integer-wired-in","ghc-prim","rts"]) @@@ Stripping prefix for "Cffi" to "ffi" for package "rts" ("collectLinkOpts",(["-lHShaskeline-0.7.4.3-ghc8.7.20181205","-lHSstm-2.5.0.0-ghc8.7.20181205","-lHSghc-8.7-ghc8.7.20181205","-lHSterminfo-0.4.1.2-ghc8.7.20181205","-lHSprocess-1.6.3.0-ghc8.7.20181205","-lHShpc-0.6.0.3-ghc8.7.20181205","-lHSghci-8.7-ghc8.7.20181205","-lHStransformers-0.5.5.0-ghc8.7.20181205 ","-lHStemplate- haskell-2.15.0.0-ghc8.7.20181205","-lHSpretty-1.1.3.6-ghc8.7.20181205 ","-lHSghc-heap-8.7-ghc8.7.20181205","-lHSghc-boot-8.7-ghc8.7.20181205 ","-lHSghc-boot- th-8.7-ghc8.7.20181205","-lHSbinary-0.8.6.0-ghc8.7.20181205","-lHSdirectory-1.3.3.1-ghc8.7.20181205","-lHSunix-2.7.2.2-ghc8.7.20181205","-lHStime-1.9.2-ghc8.7.20181205","-lHSfilepath-1.4.2.1-ghc8.7.20181205","-lHScontainers-0.6.0.1-ghc8.7.20181205","-lHSbytestring-0.10.9.0-ghc8.7.20181205","-lHSdeepseq-1.4.4.0-ghc8.7.20181205","-lHSarray-0.5.2.0-ghc8.7.20181205","-lHSbase-4.12.0.0-ghc8.7.20181205 ","-lHSinteger-gmp-1.0.2.0-ghc8.7.20181205","-lHSghc- prim-0.5.3-ghc8.7.20181205","-lHSrts_thr- ghc8.7.20181205","-lffi"],["-ltinfo","-lrt","-lutil","-ldl","-lgmp","-lm","-lrt","-ldl","-lnuma"],["-Wl,-u,base_GHCziTopHandler_runIO_closure","-Wl,-u,base_GHCziTopHandler_runNonIO_closure","-Wl,-u,ghczmprim_GHCziTuple_Z0T_closure","-Wl,-u,ghczmprim_GHCziTypes_True_closure","-Wl,-u,ghczmprim_GHCziTypes_False_closure","-Wl,-u,base_GHCziPack_unpackCString_closure","-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure","-Wl,-u,base_GHCziIOziException_stackOverflow_closure","-Wl,-u,base_GHCziIOziException_heapOverflow_closure","-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure","-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure","-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure","-Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure","-Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure","-Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure","-Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure","-Wl,-u,base_Controlz iExceptionziBase_nonTermination_closure","-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure","-Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure","-Wl,-u,base_GHCziConcziSync_runSparks_closure","-Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure","-Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure","-Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure","-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure","-Wl,-u,base_GHCziTopHandler_runMainIO_closure","-Wl,-u,ghczmprim_GHCziTypes_Czh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Izh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info","-Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info","-Wl,-u,base_GHCziPtr_Ptr_con_info","-Wl,-u,base_GHCziPtr_FunPtr_con_info","-Wl,-u,base_GHCziInt_I8zh_con_info","-Wl,-u,base_GHCziInt_I16zh_con_info","-Wl,-u,base_GHCziInt_I32zh_con_info","-Wl,-u,base_GHCziInt_I64zh_con_info","-Wl,-u,base_GHCziWord_W8zh_con_info","-Wl,-u,base_GHCziWord_W16 zh_con_info","-Wl,-u,base_GHCziWord_W32zh_con_info","-Wl,-u,base_GHCziWord_W64zh_con_info","-Wl,-u,base_GHCziStable_StablePtr_con_info","-Wl,-u,hs_atomic_add8","-Wl,-u,hs_atomic_add16","-Wl,-u,hs_atomic_add32","-Wl,-u,hs_atomic_add64","-Wl,-u,hs_atomic_sub8","-Wl,-u,hs_atomic_sub16","-Wl,-u,hs_atomic_sub32","-Wl,-u,hs_atomic_sub64","-Wl,-u,hs_atomic_and8","-Wl,-u,hs_atomic_and16","-Wl,-u,hs_atomic_and32","-Wl,-u,hs_atomic_and64","-Wl,-u,hs_atomic_nand8","-Wl,-u,hs_atomic_nand16","-Wl,-u,hs_atomic_nand32","-Wl,-u,hs_atomic_nand64","-Wl,-u,hs_atomic_or8","-Wl,-u,hs_atomic_or16","-Wl,-u,hs_atomic_or32","-Wl,-u,hs_atomic_or64","-Wl,-u,hs_atomic_xor8","-Wl,-u,hs_atomic_xor16","-Wl,-u,hs_atomic_xor32","-Wl,-u,hs_atomic_xor64","-Wl,-u,hs_cmpxchg8","-Wl,-u,hs_cmpxchg16","-Wl,-u,hs_cmpxchg32","-Wl,-u,hs_cmpxchg64","-Wl,-u,hs_atomicread8","-Wl,-u,hs_atomicread16","-Wl,-u,hs_atomicread32","-Wl,-u,hs_atomicread64","-Wl,-u,hs_atomicwrite8","-Wl,-u,hs_atomicwrite16","-Wl,-u,hs_atomicwrite32","-Wl ,-u,hs_atomicwrite64"])) *** Linker: /nix/store/qanjz18apdwi0vl98sdrvyf4z4hv65df-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE '-Wl,--hash-size=31' -Wl,--reduce- memory-overheads -Wl,--no-as-needed -Wl,-rpath '-Wl,$ORIGIN/../haskeline-0.7.4.3' -Wl,-rpath '-Wl,$ORIGIN/../stm-2.5.0.0' -Wl,-rpath '-Wl,$ORIGIN/../ghc-8.7' -Wl,-rpath '-Wl,$ORIGIN/../terminfo-0.4.1.2' -Wl,-rpath '-Wl,$ORIGIN/../process-1.6.3.0' -Wl,-rpath '-Wl,$ORIGIN/../hpc-0.6.0.3' -Wl,-rpath '-Wl,$ORIGIN/../ghci-8.7' -Wl,-rpath '-Wl,$ORIGIN/../transformers-0.5.5.0' -Wl,-rpath '-Wl,$ORIGIN/../template- haskell-2.15.0.0' -Wl,-rpath '-Wl,$ORIGIN/../pretty-1.1.3.6' -Wl,-rpath '-Wl,$ORIGIN/../ghc-heap-8.7' -Wl,-rpath '-Wl,$ORIGIN/../ghc-boot-8.7' -Wl,-rpath '-Wl,$ORIGIN/../ghc-boot-th-8.7' -Wl,-rpath '-Wl,$ORIGIN/../directory-1.3.3.1' -Wl,-rpath '-Wl,$ORIGIN/../unix-2.7.2.2' -Wl,-rpath '-Wl,$ORIGIN/../time-1.9.2' -Wl,-rpath '-Wl,$ORIGIN/../filepath-1.4.2.1' -Wl,-rpath '-Wl,$ORIGIN/../binary-0.8.6.0' -Wl,-rpath '-Wl,$ORIGIN/../containers-0.6.0.1' -Wl,-rpath '-Wl,$ORIGIN/../bytestring-0.10.9.0' -Wl,-rpath '-Wl,$ORIGIN/../deepseq-1.4.4.0' -Wl,-rpath '-Wl,$ORIGIN/../array-0.5.2.0' -Wl,-rpath '-Wl,$ORIGIN/../base-4.12.0.0' -Wl,-rpath '-Wl,$ORIGIN /../integer-gmp-1.0.2.0' -Wl,-rpath '-Wl,$ORIGIN/../ghc-prim-0.5.3' -Wl,-rpath '-Wl,$ORIGIN/../rts' -Wl,-zorigin -o ghc/stage2/build/tmp/ghc- stage2 -lm -no-pie -fPIC -U__PIC__ -D__PIC__ -Wl,--gc-sections ghc/stage2/build/Main.dyn_o ghc/stage2/build/GHCi/Leak.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 -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/haskeline/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/haskeline/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/stm /dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/stm /dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/compiler/stage2/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/compiler/stage2/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/terminfo/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/terminfo/dist-install/build -L/nix/store/x5ms5m9ga6v7vy3akc58yx279ggfnbnl-ghc-build-environment/lib -Xlinker -rpath-link -Xlinker /nix/store/x5ms5m9ga6v7vy3akc58yx279ggfnbnl- ghc-build-environment/lib -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/process/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/process/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/hpc /dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/hpc /dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/ghci/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/ghci/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/transformers/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/transformers/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries /template-haskell/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries /template-haskell/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/pretty/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/pretty/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/ghc- heap/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/ghc- heap/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/ghc-boot/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/ghc-boot/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/ghc- boot-th/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/ghc- boot-th/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/binary/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/binary/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/directory/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/directory/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/unix /dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/unix /dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/time/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/time/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/filepath/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/filepath/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/containers/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/containers/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/bytestring/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/bytestring/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/deepseq/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/deepseq/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/array/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/array/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/base /dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/base /dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/integer-gmp/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/libraries/integer-gmp/dist-install/build -L/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/ghc- prim/dist-install/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/libraries/ghc- prim/dist-install/build -L/home/david/MEGA/File_Dump/Well- Typed/GHC/_nosync_git/ghc/rts/dist/build -Xlinker -rpath-link -Xlinker /home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/rts/dist/build /run/user/1000/ghc13514_0/ghc_2.o /run/user/1000/ghc13514_0/ghc_5.o -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,ghczmprim_GHCziTuple_Z0T_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure -Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure -Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure -Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runMainIO_closure -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziInt_I8zh_con_info -Wl,-u,base_GHCziInt_I16zh_con_info -Wl,-u,base_GHCziInt_I32zh_con_info -Wl,-u,base_GHCziInt_I64zh_con_info -Wl,-u,base_GHCziWord_W8zh_con_info -Wl,-u,base_GHCziWord_W16zh_con_info -Wl,-u,base_GHCziWord_W32zh_con_info -Wl,-u,base_GHCziWord_W64zh_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,hs_atomic_add8 -Wl,-u,hs_atomic_add16 -Wl,-u,hs_atomic_add32 -Wl,-u,hs_atomic_add64 -Wl,-u,hs_atomic_sub8 -Wl,-u,hs_atomic_sub16 -Wl,-u,hs_atomic_sub32 -Wl,-u,hs_atomic_sub64 -Wl,-u,hs_atomic_and8 -Wl,-u,hs_atomic_and16 -Wl,-u,hs_atomic_and32 -Wl,-u,hs_atomic_and64 -Wl,-u,hs_atomic_nand8 -Wl,-u,hs_atomic_nand16 -Wl,-u,hs_atomic_nand32 -Wl,-u,hs_atomic_nand64 -Wl,-u,hs_atomic_or8 -Wl,-u,hs_atomic_or16 -Wl,-u,hs_atomic_or32 -Wl,-u,hs_atomic_or64 -Wl,-u,hs_atomic_xor8 -Wl,-u,hs_atomic_xor16 -Wl,-u,hs_atomic_xor32 -Wl,-u,hs_atomic_xor64 -Wl,-u,hs_cmpxchg8 -Wl,-u,hs_cmpxchg16 -Wl,-u,hs_cmpxchg32 -Wl,-u,hs_cmpxchg64 -Wl,-u,hs_atomicread8 -Wl,-u,hs_atomicread16 -Wl,-u,hs_atomicread32 -Wl,-u,hs_atomicread64 -Wl,-u,hs_atomicwrite8 -Wl,-u,hs_atomicwrite16 -Wl,-u,hs_atomicwrite32 -Wl,-u,hs_atomicwrite64 -lHShaskeline-0.7.4.3-ghc8.7.20181205 -lHSstm-2.5.0.0-ghc8.7.20181205 -lHSghc-8.7-ghc8.7.20181205 -lHSterminfo-0.4.1.2-ghc8.7.20181205 -lHSprocess-1.6.3.0-ghc8.7.20181205 -lHShpc-0.6.0.3-ghc8.7.20181205 -lHSghci-8.7-ghc8.7.20181205 -lHStransformers-0.5.5.0-ghc8.7.20181205 -lHStemplate-haskell-2.15.0.0-ghc8.7.20181205 -lHSpretty-1.1.3.6-ghc8.7.20181205 -lHSghc-heap-8.7-ghc8.7.20181205 -lHSghc-boot-8.7-ghc8.7.20181205 -lHSghc-boot-th-8.7-ghc8.7.20181205 -lHSbinary-0.8.6.0-ghc8.7.20181205 -lHSdirectory-1.3.3.1-ghc8.7.20181205 -lHSunix-2.7.2.2-ghc8.7.20181205 -lHStime-1.9.2-ghc8.7.20181205 -lHSfilepath-1.4.2.1-ghc8.7.20181205 -lHScontainers-0.6.0.1-ghc8.7.20181205 -lHSbytestring-0.10.9.0-ghc8.7.20181205 -lHSdeepseq-1.4.4.0-ghc8.7.20181205 -lHSarray-0.5.2.0-ghc8.7.20181205 -lHSbase-4.12.0.0-ghc8.7.20181205 -lHSinteger-gmp-1.0.2.0-ghc8.7.20181205 -lHSghc-prim-0.5.3-ghc8.7.20181205 -lHSrts_thr-ghc8.7.20181205 -lffi -ltinfo -lrt -lutil -ldl -lgmp -lm -lrt -ldl -lnuma *** Deleting temp files: Deleting: /run/user/1000/ghc13514_0/ghc_1.c /run/user/1000/ghc13514_0/ghc_3.rsp /run/user/1000/ghc13514_0/ghc_4.s /run/user/1000/ghc13514_0/ghc_6.rsp /run/user/1000/ghc13514_0/ghc_7.rsp /run/user/1000/ghc13514_0/ghc_2.o /run/user/1000/ghc13514_0/ghc_5.o *** Deleting temp dirs: Deleting: /run/user/1000/ghc13514_0 }}} Note that **make also uses `-lffi`**. Hence I will proceed under the assumption that `-lffi` is correct, and the problem that needs to be solved in getting the linker to correctly find the locally built libffi .so file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 10:03:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 10:03:53 -0000 Subject: [GHC] #16003: Average and maximum residency numbers in nofib broken Message-ID: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> #16003: Average and maximum residency numbers in nofib broken -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: 8.6.2 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 5793 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Measuring average and maximum residency in nofib is currently broken: {{{ < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 10:05:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 10:05:07 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.b0667fb356161a0b1d48333a2f986f9c@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): > what matters is that the sampled maximum residency for default was lower than allow-cg (192 vs. 196MB) Interesting. So the (fairly complicated) closure-growth analysis busy us only 2% reduction in residency. That raises the question of whether the gain is worth the pain. We should explore that in the paper -- and of course measure more programs. We don't want a tricky analysis that doesn't pay its way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 10:19:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 10:19:37 -0000 Subject: [GHC] #16003: Average and maximum residency numbers in nofib broken In-Reply-To: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> References: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> Message-ID: <059.adedaede84da8cdb8e7aab4ab1652f00@haskell.org> #16003: Average and maximum residency numbers in nofib broken -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: 5793 => #5793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 10:35:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 10:35:21 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 Message-ID: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Hello. With the following code, I can observe a performance regression between ghc 8.4 and 8.6: {{{#!haskell {-# LANGUAGE ScopedTypeVariables #-} module Main where import qualified Data.Vector.Unboxed.Mutable as Vector import qualified Data.Vector.Unboxed as VectorU import Data.Foldable (for_) main :: IO () main = do let n = 1000 let vUnmutable :: VectorU.Vector Double = VectorU.generate (n * n) (\i -> fromIntegral i) v :: Vector.IOVector Double <- VectorU.unsafeThaw vUnmutable for_ [0..(n - 1)] $ \k -> do for_ [0..(n - 1)] $ \i -> do for_ [0..(n - 1)] $ \j -> do a <- Vector.unsafeRead v (i * n + k) b <- Vector.unsafeRead v (k * n + j) c <- Vector.unsafeRead v (i * n + j) Vector.unsafeWrite v (i * n + j) (min (a + b) c) }}} Built with `-O2` and with / without `-fllvm`. I'm using `vector-0.12.0.1`. Here are the timing results: GHC 8.2.2 no llvm: 1.7s llvm: 1.0s GHC 8.4.4 no llvm: 1.6s llvm: 0.9s GHC 8.6.2 no llvm: 4.8s llvm: 4.3s I'm using the following bash + nix script to gather theses timings: {{{#!bash nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' -p llvm_39 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' -p llvm_5 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' -p llvm_6 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 11:10:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 11:10:39 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.ee52d1b0a9bc3574fc6ee1a44433ab73@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 11:16:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 11:16:46 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.85d9cea5b4ab237c05a7c34ed037b728@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Amazing.. I can build this with hadrian but not with make. I wonder what's causing this different behavior.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 11:31:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 11:31:02 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly In-Reply-To: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> References: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> Message-ID: <060.ddbfc560efe5f88aa13af35d538535dc@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): We could perhaps add a flag? We already have {{{ --integer-simple Build GHC with integer-simple library. }}} after all, where we're using integer-gmp (currently assuming system wide libgmp if I'm not mistaken?) as a default, when this flag is not given. We could instead perhaps have: {{{ --integer-simple --system-gmp --in-tree-gmp }}} with `--system-gmp` being the default? The last two would imply the use of integer-gmp, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 11:42:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 11:42:34 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.0b09195edf61d99091ab045bfe37a7fa@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by davide): The locally built libffi is bundled with the rts package. As libffi is ''not'' a haskell library, the naming convention is to call the library `Cffi` in `rts/rts.cabal.in` (see specifically the line `extra-bundled- libraries: Cffi`). When ghc is calculating the linker options, ghc sees that `Cffi` is bundled with rts and tries to link with it. The "C" prefix is striped, but unlike haskell libraries a version number is not suffixed (this logic is in `compiler/main/Packages.hs:packageHsLibs`). Hence ghc links with the `-lffi` option instead of e.g. `-lCffi` or `-lCffi-7.0`. This means the linker is looking for a corresponding .so file named `libffi.so`. As per comment:14 it is easy to produce the `libffi.so` file, but it isn't in the correct location at the moment. There are 2 relevant steps that hadrian takes here: 1. After building libffi, copy the .so from `_build/stage1/libffi/build/inst/lib/libffi.so` to `_build/stage1/rts/build/X`. 2. "Install" the .so by copying it from `_build/stage1/rts/build/` to `_build/stage1/lib/x86_64-linux-ghc-8.7.20181205/X` Currently X in 1 and 2 uses a naming convention convention of e.g .`libCffi-ghc8.7.20181126_thr_debug.so`. This naming convention does **not** match ghc's as described before. It seems that changing X to match the ghc naming convention would solve the problem, but is that the correct solution? Changing the naming convention for the static libffi libraries also sounds necessary, but I thought the the static build been working so far. How is that possible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 12:19:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 12:19:57 -0000 Subject: [GHC] #15677: Valid hole fits and GADT type variable names In-Reply-To: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> References: <050.cc002e198458d754a5b83d9b7f8d65ce@haskell.org> Message-ID: <065.02679d0d3b425da79a838983357b4c7e@haskell.org> #15677: Valid hole fits and GADT type variable names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles, | GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Interestingly, it also works for example 1 in #9091, but not for example 2 (possibly because a0 is made up by the type checker?). So if we fix that, we can at least close #9091. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 12:25:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 12:25:55 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly In-Reply-To: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> References: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> Message-ID: <060.8e114d7bb2dab484667f12088f33aee0@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5417 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5417 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 12:43:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 12:43:57 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.d83bd3065a334d478c3eaa068ff2d18f@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by davide): When looking at the output of make I get: {{{ $ find . -name "*ffi*.so*" -or -name "*ffi*.a*" ./libffi/build/x86_64-unknown-linux-gnu/.libs/libffi_convenience.a ./libffi/build/x86_64-unknown-linux-gnu/.libs/libffi.so.7.1.0 ./libffi/build/x86_64-unknown-linux-gnu/.libs/libffi.so.7 ./libffi/build/x86_64-unknown-linux-gnu/.libs/libffi.so ./libffi/build/x86_64-unknown-linux-gnu/.libs/libffi.a ./libffi/build/inst/lib/libffi.so.7.1.0 ./libffi/build/inst/lib/libffi.so.7 ./libffi/build/inst/lib/libffi.so ./libffi/build/inst/lib/libffi.a ./rts/dist/build/libCffi_p.a ./rts/dist/build/libffi.so ./rts/dist/build/libffi.so.7 ./rts/dist/build/libffi.so.7.1.0 ./rts/dist/build/libCffi_l.a ./rts/dist/build/libCffi_debug.a ./rts/dist/build/libCffi_thr.a ./rts/dist/build/libCffi_thr_debug.a ./rts/dist/build/libCffi_thr_l.a ./rts/dist/build/libCffi_thr_p.a ./rts/dist/build/libCffi_thr_debug_p.a ./rts/dist/build/libCffi_debug_p.a ./rts/dist/build/libCffi.a }}} Note that all the `libCffi*.a` files are identical, and all `libCffi*.so` files are identical. == Dynamic This matches closely with my previous comments, but with the addition of some extra versioned .so files. Note the symlinks: {{{ $ ls -l _build/stage1/libffi/build/inst/lib/libffi.so* lrwxrwxrwx 1 david david 15 Dec 6 10:28 _build/stage1/libffi/build/inst/lib/libffi.so -> libffi.so.7.1.0 lrwxrwxrwx 1 david david 15 Dec 6 10:28 _build/stage1/libffi/build/inst/lib/libffi.so.7 -> libffi.so.7.1.0 -rwxr-xr-x 1 david david 70232 Dec 6 10:28 _build/stage1/libffi/build/inst/lib/libffi.so.7.1.0 }}} == Static This matches hadrians behavior w.r.t static libffi. On that grounds I'm going to leave the static libs behavior as is, but add a note about possible simplification here: only copy a single .a file as we will do with the dynamic version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 13:15:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 13:15:14 -0000 Subject: [GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum In-Reply-To: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> References: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> Message-ID: <064.30cb0360ed60364fdeb92e83d50f564e@haskell.org> #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | 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 Thu Dec 6 13:18:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 13:18:18 -0000 Subject: [GHC] #14727: Unboxed sum performance surprisingly poor In-Reply-To: <045.2f36bcb58aa862841131b518b7ebd355@haskell.org> References: <045.2f36bcb58aa862841131b518b7ebd355@haskell.org> Message-ID: <060.0109ee1e0ed117af5233d86c7443a4a8@haskell.org> #14727: Unboxed sum performance surprisingly poor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: UnboxedSums 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 Thu Dec 6 13:19:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 13:19:55 -0000 Subject: [GHC] #15989: Adding extra quantified constraints leads to resolution failure In-Reply-To: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> References: <043.b7b3c15232625afc809905bf33cb1941@haskell.org> Message-ID: <058.20cffdacd621bf2a44e901f78ca824db@haskell.org> #15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.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): I agree that it is confusing that adding extra quantified constraints leads to failure. And yet it is [https://downloads.haskell.org/~ghc/8.6.2/docs/html/users_guide/glasgow_exts.html#overlap documented in the user manual]. The issue described there is that two quantified constraints may both claim to prove a constraint, but have different contexts, so picking one over the other would yield unpredictable behaviour. In your particular case, however, the available 'Givens' look like this {{{ [G] df_a2ra {0}:: forall x. Functor (m_a2aR[sk:1] x) [G] df_a2r9 {0}:: forall x. Applicative (m_a2aR[sk:1] x) [G] df_a2aV {0}:: forall x. Monad (m_a2aR[sk:1] x) [G] df_a2r8 {0}:: forall x x'. Functor (m_a2aR[sk:1] x') [G] df_a2r7 {0}:: forall x x'. Applicative (m_a2aR[sk:1] x') [G] df_a2r6 {0}:: forall x x'. Monad (m_a2aR[sk:1] x') [G] df_a2aU {0}:: forall x x'. MonadReader (T x) (m_a2aR[sk:1] x') }}} So there are two ways to prove `Functor (m y)` from `df_a2ra` and `df_a2r8`. So GHC takes neither. In this particular case, picking one would ''not'' get stuck, since they both have an empty context. In general, if one has a subset of the context of the other, we could pick that one. This additional check would save the day in this case. But is it sufficiently general to be worth it? The fix in #15244 (See `Note [Do not add duplicate quantified instances]` in `TcSMonad`) is indeed a special case. It looks for ''identical'' givens, and (as you can see above) they aren't quite identical. Perhaps I could prune the quantified variables (you can see that `x` is redundant); and that would solve this particular example. Note that the identical-given idea works on the ''givens themselves'', when adding them to the inert set, rather the ''matching instances'' following a lookup. For example, consider {{{ f :: ( forall a. D a Int , forall b c. D [b] c) => blah }}} These are not identical. But if we seek `D [ty] Int` it'll match both; but since both have an empty context we could pick eitehr. The empty context is easy but it's probably more often like this: {{{ g :: ( forall a. Eq a => D a Int , forall b. Eq b => D [b] c) => blah }}} Now if we wanted to solve `D [ty] Int`, we'll need `Eq [ty]` for the first one, and `Eq ty` for the second. We know that these are equivalent, but it's more of a stretch for GHC to figure that out during instance selection. I'm not sure how clever to try to be here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 13:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 13:30:29 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.c23cb61cb6b9aa5721c9caea821880f4@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): If I add these two lines to `mk/build.mk` I can build with make too: {{{ DYNAMIC_GHC_PROGRAMS=NO DYNAMIC_TOO=NO }}} so I somehow broke something with dyn_o/dyn_hi builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 13:49:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 13:49:29 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.f25f5d0c26a46d2a2ad2f735e5f1de35@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I already wrote something down in [https://github.com/sgraf812/late-lam- lift/blob/master/paper.pdf section 4 here]. Table 2 turns off closure growth, in particular. The results are fairly inconclusive, but I argue that we want to avoid arbitrary increases in allocations in order to stay predictable. For example `wheel-sieve1`, with a nearly 30% increase in allocation, had an increase in residency by 5.7%. I imagine that there are programs that could trigger some exponential worst case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:09:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:09:22 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.93efd401bcb260bdc8f6a580b33cbe41@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Ouch! Thanks for reporting this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:16:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:16:04 -0000 Subject: [GHC] #15996: Add Unlifted List type to base In-Reply-To: <046.6e24f84a6ceaff74937c7d525d35fc71@haskell.org> References: <046.6e24f84a6ceaff74937c7d525d35fc71@haskell.org> Message-ID: <061.1750f8e1b7aa5de0336c27758dcc6701@haskell.org> #15996: Add Unlifted List type to base -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: libraries/base | Version: 8.6.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 carter): Hey Daniel: do you have any examples where the timing measurements would be improved by these changes to qsem? Or where unlifted list would be faster ? I agree that they might reduce indirections, but having concrete programs which benefit measurably from the change helps ground things. Also let’s us measure the impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:24:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:24:26 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types In-Reply-To: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> References: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> Message-ID: <061.4fc2fff24f3669011308933d99e02b06@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I think this is fixed. I'll add a test case. Thanks for spotting this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:26:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:26:49 -0000 Subject: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs In-Reply-To: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> References: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> Message-ID: <068.7ffb385c28cbc53d31e2d417906df804@haskell.org> #7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T7503a Blocked By: | Blocking: Related Tickets: #14451, #12088 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by simonpj): * related: #14451 => #14451, #12088 Comment: #12088 seems to be in the same territory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:27:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:27:13 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.40162cb32c49a97378e2160aed678dba@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #7503, #11348, | Differential Rev(s): Phab:D2272 #12239, #12643, #13790, #14668, | #15561, #15777, #15987 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking,| https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by simonpj): * related: #11348, #12239, #12643, #13790, #14668, #15561, #15777, #15987 => #7503, #11348, #12239, #12643, #13790, #14668, #15561, #15777, #15987 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:44:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:44:19 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types In-Reply-To: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> References: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> Message-ID: <061.d510470345c0bb0269f0041531871685@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"91c4e71f633ebc81671fbfc752fc35b84883e744/ghc" 91c4e71f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91c4e71f633ebc81671fbfc752fc35b84883e744" Tests Trac #14847 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 14:45:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 14:45:05 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types In-Reply-To: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> References: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> Message-ID: <061.256c538874faac892870773e73ab243d@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14847 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14847 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 15:09:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 15:09:58 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.e0eaa5d49bf8d495e3c2ed07670d361c@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit 3d38e8284b7382844f9862e8d8afbae9c7248b09 (`Do not unpack class dictionaries with INLINABLE`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 15:38:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 15:38:25 -0000 Subject: [GHC] #16005: Don't use a generic apply thunk for known calls Message-ID: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> #16005: Don't use a generic apply thunk for known calls -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5414 | Wiki Page: -------------------------------------+------------------------------------- Currently, an AP thunk like `sat = f a b c` will not have its own entry point and info pointer and will instead reuse a generic apply thunk like `stg_ap_4_upd`. That's great from a code size perspective, but if `f` is a known function, a specialised entry point with a plain call can be much faster than figuring out the arity and doing dynamic dispatch. ---- I prepared a patch over at Phab:D5414 that fixes this by checking if the arity of `f` is unknown (e.g. 0). If not, it will no longer delegate to a generic apply thunk and generate regular entry code and info tables instead. No impact on allocations, but on counted instructions and code size. Significant changes to counted instructions: ||cryptarithm1 || -2.5%|| ||lcss || -2.3%|| ||paraffins || -3.8%|| ||wheel-sieve2 || -3.4%|| |||||| ||Min || -3.8%|| ||Max || +0.0%|| || Geometric Mean || -0.2%|| And changes to binary size greater than 0.1% (all the other programs, basically): || Program ||Size || Instrs|| || anna ||+0.3% ||-0.2%|| || expert ||+0.2% ||-0.0%|| || fluid ||+0.2% ||-0.1%|| || grep ||+0.2% ||-0.0%|| || infer ||+0.2% ||-0.4%|| || last-piece ||+0.2% ||-0.1%|| || lift ||+0.2% ||-0.0%|| || paraffins ||+0.2% ||-3.8%|| || prolog ||+0.2% ||-0.1%|| || scs ||+0.3% ||-0.0%|| || transform ||+0.2% ||-0.2%|| || veritas ||+0.2% ||+0.0%|| |||||||| || Min ||+0.1% ||-3.8%|| || Max ||+0.3% ||+0.0%|| || Geometric Mean ||+0.1% ||-0.2%|| -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 15:38:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 15:38:59 -0000 Subject: [GHC] #16005: Don't use a generic apply thunk for known calls In-Reply-To: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> References: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> Message-ID: <059.e94cd10f3c800f690ec170d2f4d55043@haskell.org> #16005: Don't use a generic apply thunk for known calls -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5414 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 15:40:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 15:40:27 -0000 Subject: [GHC] #16005: Don't use a generic apply thunk for known calls In-Reply-To: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> References: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> Message-ID: <059.85dad339a49556eacb774dcd7b5b4648@haskell.org> #16005: Don't use a generic apply thunk for known calls -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5414 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"dc54c07cf18356a64cbe04aa9772c7f4c9fbc11d/ghc" dc54c07/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc54c07cf18356a64cbe04aa9772c7f4c9fbc11d" Don't use a generic apply thunk for known calls Summary: Currently, an AP thunk like `sat = f a b c` will not have its own entry point and info pointer and will instead reuse a generic apply thunk like `stg_ap_4_upd`. That's great from a code size perspective, but if `f` is a known function, a specialised entry point with a plain call can be much faster than figuring out the arity and doing dynamic dispatch. This looks at `f`s arity to figure out if it is a known function and if so, it will not lower it to a generic apply function. Benchmark results are encouraging: No changes to allocation, but 0.2% less counted instructions. Test Plan: Validates locally Reviewers: simonmar, osa1, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #16005 Differential Revision: https://phabricator.haskell.org/D5414 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 15:54:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 15:54:38 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.943b08a8c2a805123e96c6ba2dc75b00@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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:D5420 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5420 Comment: Moving the check to the renamer seems to work pretty well! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 16:42:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 16:42:28 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.d3ffff3159e6c3f179c008e08c811824@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): The `-F1 -A1M` trick (hat tip in direction of Simon Marlow) for measuring residency discussed on [https://mail.haskell.org/pipermail/ghc- devs/2018-December/016639.html ghc-dev] is much more accurate. It seems that the difference in residency isn't as big as I thought; In the `./paraffins 19` setup, it's 196MB in both cases, with just a little bit more residency (I measured 300kb difference, I'm not confident this is really accurate or measurable) when we ignore possible closure growth. For `wheel-sieve1`, the difference in residency also is about 300kb, of 12.6MB. (Still, 30% more allocations in total.) So it seems that we produce significantly more garbage in some cases, but residency stays about the same. On the other hand, producing more garbage means more frequent Gen 0 collects. That's also evident by the number of collections in `-F1 -A1M`: 42 vs. 55 when ignoring closure growth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 17:08:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 17:08:05 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.9cbe412947d5ddd76b28dfe90b61500b@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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:D5420 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): should this fix go into a 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 17:20:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 17:20:03 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.eb1a49e7be31a10a1d447454b26dbe64@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): whats the current state of play for this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 17:44:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 17:44:23 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.0d9182d0320cd1f0d0a5d03a00729555@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.3 Component: Compiler | Version: 8.4.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 18:09:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 18:09:35 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.ecf7eb647dcd49081ae3b3e67f3c25eb@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Reproduced with 8.4.3 and 8.6.1 For the original code using -fno-full-laziness performance is almost the same for 8.4 and 8.6, and what little difference there is probably comes from using a different branch order at the Cmm level. {{{ $ ~/bench-exe.exe ./test-8.6-nofloat.exe -- ./test-8.4.exe benchmarking execute: ./test-8.6-nofloat.exe time 1.632 s (1.352 s .. 1.859 s) 0.997 R² (0.988 R² .. 1.000 R²) mean 1.629 s (1.600 s .. 1.658 s) std dev 49.03 ms (0.0 s .. 49.85 ms) variance introduced by outliers: 19% (moderately inflated) benchmarking execute: ./test-8.4.exe time 1.646 s (1.493 s .. 1.863 s) 0.998 R² (0.994 R² .. NaN R²) mean 1.597 s (1.560 s .. 1.622 s) std dev 37.88 ms (0.0 s .. 43.65 ms) variance introduced by outliers: 19% (moderately inflated) }}} The difference between full-laziness not seems to be that with full- laziness we float out the creation of the [0..n] list, instead of transforming the code into a simple loop as intended. So we end up with this inner loop that passes around the list explicitly. I assume deforestation fails here? {{{ joinrec { go2_s7mc go2_s7mc ds3_X6W3 eta2_X3r = case ds3_X6W3 of { [] -> jump exit2_XF eta2_X3r; : y3_X6Yn ys2_X6Yq -> case readDoubleArray# (ipv1_a6zy `cast` ) (+# (*# x1_a5F9 1000#) x_a69v) (eta2_X3r `cast` ) of { (# ipv4_X6am, ipv5_X6ao #) -> case y3_X6Yn of { I# y4_X6c8 -> case writeDoubleArray# (ipv1_a6zy `cast` ) (+# (*# x1_a5F9 1000#) y4_X6c8) ipv5_X6ao ipv4_X6am of s'#1_X6b3 { __DEFAULT -> jump go2_s7mc ys2_X6Yq (s'#1_X6b3 `cast` ) } } } }; } }}} Not an export in the deforestation machinery so leaving that for someone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 18:17:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 18:17:04 -0000 Subject: [GHC] #15998: GHC.Event.Thread.eventManager has a lot of indirections In-Reply-To: <046.c1a4a50d15b7cb78b0d20ecacec2e37f@haskell.org> References: <046.c1a4a50d15b7cb78b0d20ecacec2e37f@haskell.org> Message-ID: <061.1948df748b2f12cc7fa6ac2634cc283c@haskell.org> #15998: GHC.Event.Thread.eventManager has a lot of indirections -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: libraries/base | Version: 8.6.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 carter): Chessai: have you done any benchmarks / or experiments for this thesis? I do have the slightly worry that this sort of optimization/unboxing might back fire on these high concurrency data structures. Or have minimal impact. The workloads which have these be the bottle neck are gonna be exactly those which have the data structure already in cache I believe. These sorts of representation changes really need to be motivated by clear benchmarkable wins. One spot that’s related which I believe would benefit from some data structure optimization is the priority heap queue used by the timer manager. It’s a pretty simple implementation and for web facing applications I think timers are used quite heavily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 18:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 18:23:57 -0000 Subject: [GHC] #15996: Add Unlifted List type to base In-Reply-To: <046.6e24f84a6ceaff74937c7d525d35fc71@haskell.org> References: <046.6e24f84a6ceaff74937c7d525d35fc71@haskell.org> Message-ID: <061.4af9841c96c7884dee789f124da6c320@haskell.org> #15996: Add Unlifted List type to base -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: libraries/base | Version: 8.6.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 carter): Additionally: these are all types you can workshop writing in users space. And these sorts of changes only make sense if you can make a measurable performance impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 19:21:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 19:21:42 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.0152eaf6f23aff73d84b734865782f9e@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Phab:D5351 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 19:22:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 19:22:09 -0000 Subject: [GHC] #15866: libiserv's version number is hard-coded In-Reply-To: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> References: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> Message-ID: <065.8436d6e5ffee6abf006d5adc569c3e40@haskell.org> #15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5302 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I didn't merge this verbatim but rather just updated the version numbers manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 19:22:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 19:22:14 -0000 Subject: [GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows In-Reply-To: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> References: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> Message-ID: <062.75dc6581890695273d7fbe60df9bc2f8@haskell.org> #15894: Cannot find symbol during interactive linking using new-repl on Windows -----------------------------+---------------------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T15894 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5353 Wiki Page: | -----------------------------+---------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 19:22:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 19:22:36 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.1909bd9d5d8f82f5c42a819e9a4fe462@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 20:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 20:29:46 -0000 Subject: [GHC] #15956: Linker error building `runghc` In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.adac4cfc4fe105991bb02b149a989a88@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 20:31:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 20:31:33 -0000 Subject: [GHC] #16005: Don't use a generic apply thunk for known calls In-Reply-To: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> References: <044.5792847da8e101a8478b52c38fbac09e@haskell.org> Message-ID: <059.ad136f26042c87bc05b9f9c11a8f5e36@haskell.org> #16005: Don't use a generic apply thunk for known calls -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5414 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.6.3 => 8.8.1 Comment: Given this isn't strictly speaking a bug fix I'm going to defer this to 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 20:35:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 20:35:52 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.a8811ac3e97d68b2efa68bd0a097e519@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15525 | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I'm going to punt this to 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 21:28:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 21:28:10 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.84f57796aa9f38ed10212846d0977c57@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5383 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ef90f990da90036d481c830d8832e21b8f1571b/ghc" 1ef90f99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ef90f990da90036d481c830d8832e21b8f1571b" Windows: Use the "big" PE object format on amd64 Test Plan: Do full build on Windows. Reviewers: AndreasK, Phyx Reviewed By: AndreasK Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15934 Differential Revision: https://phabricator.haskell.org/D5383 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 21:28:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 21:28:26 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.4b29c8f710f7fcefc8f547f3539c7d27@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: TDecki Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14037 | Differential Rev(s): Phab:D5241 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fb669f51b3f2cae79511ac3d1c43939d951b1f69/ghc" fb669f51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb669f51b3f2cae79511ac3d1c43939d951b1f69" Add fusion rules for the zipWith functions in base (#15263) This patch will allow `zip3` and `zipWith3` in `GHC.List` as well as `zipWith4`, `zipWith5`, `zipWith6` and `zipWith7` in `Data.OldList` to fuse. These rules are kept in a similar style as the rules for `zip` and `zipWith`. Added a corresponding test case. Test Plan: validate Reviewers: hvr, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rockbmb, rwbarton, carter GHC Trac Issues: #15263 Differential Revision: https://phabricator.haskell.org/D5241 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 21:35:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 21:35:02 -0000 Subject: [GHC] #15639: Surprising failure combining QuantifiedConstraints with Coercible In-Reply-To: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> References: <045.f2a49699aa20c0c2dd0e1c77d1b17a24@haskell.org> Message-ID: <060.8a501d123fb99ffb19f7d63e261d1870@haskell.org> #15639: Surprising failure combining QuantifiedConstraints with Coercible -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 simonpj]: > The best thing is to avoid overlap. This is a very good general principle (and the reason I was concerned about bundling implication constraints with quantified constraints). But I think the special case of `Coercible` deserves some special consideration. Overlap is very often (perhaps usually) unavoidable when using quantified constraints with `Coercible`. There's just no way to hide the global mechanism. So I think it pays to consider how we can refine the overlap rules to make these constraints as useful as possible. I ''conjecture'' that we will get strictly or almost strictly better results by applying quantified constraints before and between built-in rules (other than symmetry, which I imagine does some global canonicalization). We seem to already do something special to allow things to work as expected when pattern matching on `Coercion`s to locally reveal `Coercible` instances. Can we do something similar for quantified constraints? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 21:48:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 21:48:26 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.bd8b0a9bbe4b7e033c13572ff55bb16a@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > with full-laziness we float out the creation of the [0..n] list, This particular thing is quite delicate. Consider {{{ f xs = map (\x -> foo x [1..100]) xs }}} Should we float that `[1..100]` out to top level, and share it among all the calls that `map` makes? Or should we reconstruct it on every call. In the latter case we might be able to fuse it with the consumer (perhaps we inline `foo`). But even if we fuse away the list we might still allocate heap objects for `I# 1`, `I# 2`, ... `I# 100`, for each element of `xs` rather sharing those values between all those calls. Or, perhaps, we get to fuse away those `I#` boxes too! It all depends on `foo`. I don't really have a good answer here. Sometimes full laziness is a win, sometimes not. There is more discussion in #7206. I'd love someone to work on this a bit. Somehow we should do better than we are doing. PS: I have no idea why the particular commit that made this test worse did make it worse; that might be worth investigation. Another thing that would be v useful is to distil the example into a standalone test case. `vector` is a complicated library, but David's analysis above isolates the issue well. Maybe someone can turn that into a repro case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 22:11:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 22:11:09 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.8a3fe39d02d99f465a1acb0adce36dcb@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Simon,I think you mean Andreas, not David ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 22:35:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 22:35:32 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.75527de366f285de66d194a1a2c4ef34@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: TDecki Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14037 | Differential Rev(s): Phab:D5241 Wiki Page: | -------------------------------------+------------------------------------- Changes (by TDecki): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 23:04:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 23:04:13 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.0731b8812a015177a305b3fa2bc0dd47@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guibou): Simon: Is the following example without `vector` interesting as a standalone test case: {{{#!haskell import Data.Foldable (for_) main :: IO () main = do let n = 1000 for_ [0 :: Int ..(n - 1)] $ \_k -> do for_ [0 :: Int ..(n - 1)] $ \_i -> do for_ [0 :: Int ..(n - 1)] $ \_j -> do pure () }}} Timings: ghc 8.2.2: 0.667s ghc 8.4.4: 0.357s ghc 8.6.2: 1.007s Note that I have only included the results without using `-fllvm` because apparently the llvm backend is "smart" enough to understand that the loops can be removed and results in a runtime of 0.001s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 6 23:57:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Dec 2018 23:57:12 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.da3deb463a9dec95694f48926cfce632@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's great. I think we know why this is happening too. Can someone try the patch in #7206, specifically `wip/cheap-build-osa1`, and see if it nails this case? And perhaps do a new nofib run. The conclusion on #7206 was that we should probably accept the patch -- and if it cures this vector problem that'd be a strong positive reason to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 06:23:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 06:23:20 -0000 Subject: [GHC] #16006: Framework failures when validating Message-ID: <043.59ba316e797f664777821326c3e2f316@haskell.org> #16006: Framework failures when validating -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just tried to validate and got this: {{{ Framework failures: . ./perf/should_run/all.T [] (name 'stats_num_field' is not defined) }}} Tree based on fb669f51b3f2cae79511ac3d1c43939d951b1f69. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 08:42:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 08:42:41 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.bdf8207e71ca8e2e0bd78041742c9816@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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 was thinking about what we discussed the other day about compilations that stop after generating an interface file, such as `-fno-code`. Since this will now affect the ABI, we must include `-fno-code` when we fingerprint the flags, here: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler%2Fiface%2FFlagChecker.hs$37-64 Possible this can be refined to "-fno-code is relevant only when -fno- omit-iface-pragmas". Are there any other flags that should be in this category? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 09:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 09:12:35 -0000 Subject: [GHC] #16007: Implement `-Os` Message-ID: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #16005 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Popular C compilers like GCC or clang allow to optimise for binary size. Since there are multiple ways in which GHC trades code size for faster programs, it might make sense to follow suit. This ticket is for tracking which optimisations/hacks in the compiler might be affected, as well as Feel free to add items to the following list: - +0.1% increase in code size due to known calls instead of re-using generic apply thunks in #16005 - -0.1% due to `-fstg-lift-lams` #9476 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 09:43:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 09:43:22 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.971da9c2cef039282f7626d938515b98@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alp Mestanogullari ): In [changeset:"eee1b61f85d949aa7c4bc496b5579cf759d1861e/ghc" eee1b61/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eee1b61f85d949aa7c4bc496b5579cf759d1861e" hadrian: optimise Rules.Compile Previously, as reported in #15938, resuming a build "in the middle", e.g when building _build/stage1/libraries/base/, hadrian would take up to a whole minute to get started doing actual work, building code. This was mostly due to a big enumeration that we do in Rules.hs, to generate all the possible patterns for object files for 1) all ways, 2) all packages and 3) all stages. Since rule enumeration is always performed, whatever the target, we were always paying this cost, which seemed to grow bigger the farther in the build we stopped and were resuming from. Instead, this patch borrows the approach that we took for Rules.Library in https://github.com/snowleopard/hadrian/pull/571, which exposes all the relevant object files under as few catch-all rules as possible (8 here), and parses all the information we need out of the object's path. The concrete effect of this patch that I have observed is to reduce the 45-60 seconds pause to <5 seconds. Along with the Shake performance improvements that Neil mentions in #15938, most of the pause should effectively disappear. Reviewers: snowleopard, bgamari, goldfire Reviewed By: snowleopard Subscribers: rwbarton, carter GHC Trac Issues: #15938 Differential Revision: https://phabricator.haskell.org/D5412 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 11:27:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 11:27:07 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.8aba5cfc2404ad0e131d4ad37a91e7e5@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412, Wiki Page: | Phab:D5422 -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: Phab:D5412 => Phab:D5412, Phab:D5422 Comment: I just submitted [https://phabricator.haskell.org/D5422 D5422] which kills all the big enumerations but the ones for `Rules.Generate`. That last module is more involved so it probably deserves its own patch, and it's perhaps less urgent now that we got rid of hundreds of rules already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 11:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 11:28:42 -0000 Subject: [GHC] #16007: Implement `-Os` In-Reply-To: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> References: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> Message-ID: <059.f35f463165654119ea74a0723065f63a@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16005 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Other obvious things: * Specialization * Inlining should trigger less often. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 11:33:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 11:33:44 -0000 Subject: [GHC] #15951: Hadrian test doesn't show testsuite output by default In-Reply-To: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> References: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> Message-ID: <061.3ddbfde733f2eed5e565c9374189c50a@haskell.org> #15951: Hadrian test doesn't show testsuite output by default -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 alpmestan): * status: new => closed * resolution: => fixed Comment: Landed as 93e86d6103757b43017535c92bc6970e9e2315a5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 12:10:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 12:10:10 -0000 Subject: [GHC] #16007: Implement `-Os` In-Reply-To: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> References: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> Message-ID: <059.de4845fd5881cc56a7b139f0f84f8328@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16005 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Popular C compilers like GCC or clang allow to optimise for binary size. > > Since there are multiple ways in which GHC trades code size for faster > programs, it might make sense to follow suit. This ticket is for tracking > which optimisations/hacks in the compiler might be affected, as well as > > Feel free to add items to the following list: > > - +0.1% increase in code size due to known calls instead of re-using > generic apply thunks in #16005 > - -0.1% due to `-fstg-lift-lams` #9476 New description: Popular C compilers like GCC or clang allow to optimise for binary size. Since there are multiple ways in which GHC trades code size for faster programs, it might make sense to follow suit. This ticket is for tracking which optimisations/hacks in the compiler might be affected, as well as Feel free to add items to the following list: - potentially huge impact due to specialisation, liberate case and inlining - +0.1% increase in code size due to known calls instead of re-using generic apply thunks in #16005 - -0.1% due to `-fstg-lift-lams` #9476 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 12:11:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 12:11:33 -0000 Subject: [GHC] #16003: Average and maximum residency numbers in nofib broken In-Reply-To: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> References: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> Message-ID: <059.dda10bb6c61b70de054fc60a466a7952@haskell.org> #16003: Average and maximum residency numbers in nofib broken -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Phab:D5418 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * differential: => Phab:D5418 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 12:24:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 12:24:17 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.62a86f71796ccb96817a5974892e51ea@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I figured out a more useful metric to identify GC wibbles: Watching productivity rate change while increasing the nursery. Here's the current state of affairs for `paraffins`: [[Image(https://i.imgur.com/XxdNJQ8.png)]] While there are some wibbles due to short running time, it's clear that the function is highly discontinuous. We want something more like this: [[Image(https://i.imgur.com/fA4S38S.png)]] That's a much smoother curve (which of course is subject to measuring inaccuracy). I got this just by iterating `main` 100 times. Obviously, this has implications on running time of the benchmark, so the `*MODE`s have to be adjusted accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 14:44:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 14:44:41 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.18d15226de172ba78523b10da3f12deb@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15828 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5b7ca03995c1d5fbd29ba0e327bb2a1f344c9419/ghc" 5b7ca039/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b7ca03995c1d5fbd29ba0e327bb2a1f344c9419" Wibble to Taming the Kind Inference Monster I had allowed rename/should_fail/T15828 (Trac #15828) to regress a bit. The main payload of this patch is to fix that problem, at the cost of more contortions in checkConsistentFamInst. Oh well, at least they are highly localised. I also update the -ddump-types code in TcRnDriver to print out some more expicit information about each type constructor, thus instead of DF{3} :: forall k. * -> k -> * we get data family DF{3} :: forall k. * -> k -> * Remember, this is debug-printing only. This change is the reason that so many .stderr files change. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 14:45:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 14:45:57 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.7b05d60f89a26ad472498168265641b1@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15828 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK it now prints it the way you had it. Hooray. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 14:54:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 14:54:58 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell In-Reply-To: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> References: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> Message-ID: <064.fa9a6d10e140410635ef7ed0e660f06f@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5360 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): So can this patch be merged into 8.8? Otherwise plugins are much less usable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 14:59:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 14:59:00 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.553996bb05cd96c0bd19d3a8b207e7da@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f334d20e00e3f4bd217e49216b7e9d9c8779db10/ghc" f334d20e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f334d20e00e3f4bd217e49216b7e9d9c8779db10" Careful tweaking to exprOkForSpeculation This patch does several things: * Make exprOkForSpeculation ignore evaluatedness of variables See the Note [exprOkForSpeculation and evaluated variables] This means that the binder-swap transformation no longer invaliates the let/app invariant. * Make exprOkForSpeculation return False for DataToTagOp and SeqOp. See Note [exprOkForSpeculation and SeqOp/DataToTagOp] * Remove the 'can_fail' property from dataToTag#; it was always a hack (described in the old Note [dataToTag#] in primops.txt.pp), and now its not necessary because of the fixes above. * Make SetLevels use exprIsHNF, /not/ exprOkForSpeculation, when floating single-alternative cases. See SetLevels Note [Floating single-alternative cases] * Fix a buglet in FloatIn; probably never bites in practice See Note [Dead bindings] Collectively, these changes finally fix Trac #15696. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 15:13:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 15:13:12 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.7e2bbbf1dcb43890989b38c48e34ae0c@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13780, #15872 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"73cce63f33ee80f5095085141df9313ac70d1cfa/ghc" 73cce63f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73cce63f33ee80f5095085141df9313ac70d1cfa" Fix #12102/#15872 by removing outdated users' guide prose Summary: In the beginning, #12102 (and #15872, which is of a similar ilk) were caused by a poor, confused user trying to use code that looks like this (with a constraint in the kind of a data type): ```lang=haskell type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" ``` Many bizarre GHC quirks (documented in those tickets) arose from this sort of construction. Ultimately, the use of constraints in data type kinds like this has made a lot of people very confused and been widely regarded as a bad move. Commit 2257a86daa72db382eb927df12a718669d5491f8 finally put this feature out of its misery, so now the code above simply errors with `Illegal constraint in a kind`. As a result, the aforementioned tickets are moot, so this patch wraps a bow on the whole thing by: 1. Removing the (now outdated) section on constraints in data type kinds from the users' guide, and 2. Adding a test case to test this code path. Test Plan: make test TEST=T12102 Reviewers: goldfire, simonpj, bgamari, tdammers Reviewed By: tdammers Subscribers: tdammers, rwbarton, carter GHC Trac Issues: #12102, #15872 Differential Revision: https://phabricator.haskell.org/D5397 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 15:13:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 15:13:11 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.c50ed8bec74d0daf3008f156b9eef55c@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12102, #13933 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"73cce63f33ee80f5095085141df9313ac70d1cfa/ghc" 73cce63f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73cce63f33ee80f5095085141df9313ac70d1cfa" Fix #12102/#15872 by removing outdated users' guide prose Summary: In the beginning, #12102 (and #15872, which is of a similar ilk) were caused by a poor, confused user trying to use code that looks like this (with a constraint in the kind of a data type): ```lang=haskell type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" ``` Many bizarre GHC quirks (documented in those tickets) arose from this sort of construction. Ultimately, the use of constraints in data type kinds like this has made a lot of people very confused and been widely regarded as a bad move. Commit 2257a86daa72db382eb927df12a718669d5491f8 finally put this feature out of its misery, so now the code above simply errors with `Illegal constraint in a kind`. As a result, the aforementioned tickets are moot, so this patch wraps a bow on the whole thing by: 1. Removing the (now outdated) section on constraints in data type kinds from the users' guide, and 2. Adding a test case to test this code path. Test Plan: make test TEST=T12102 Reviewers: goldfire, simonpj, bgamari, tdammers Reviewed By: tdammers Subscribers: tdammers, rwbarton, carter GHC Trac Issues: #12102, #15872 Differential Revision: https://phabricator.haskell.org/D5397 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 15:13:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 15:13:36 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.339da193cdfebaa5d27f11316ab6f43a@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * testcase: => codeGen/should_run/T15696_1, T15696_2, T15696_3 * resolution: => fixed Comment: Ben, Omer: I believe I have finally finished this ticket, as promised. Do check my work! But, optimistically, I'm going to close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 15:15:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 15:15:22 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.3f21724a95cf019990a749a04ede655f@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T12102 Blocked By: | Blocking: Related Tickets: #12102, #13933 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T12102 * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 15:16:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 15:16:18 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.741b9ceb6769eee637eaf443a099202d@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12102 Blocked By: | Blocking: Related Tickets: #13780, #15872 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T12102 * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 15:39:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 15:39:10 -0000 Subject: [GHC] #13786: GHCi linker is dependent upon object file order In-Reply-To: <047.0a99d83942bb8bb77d0420502e27819e@haskell.org> References: <047.0a99d83942bb8bb77d0420502e27819e@haskell.org> Message-ID: <062.7b297395c8340f9f38952d4015f992ab@haskell.org> #13786: GHCi linker is dependent upon object file order -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.2 (Linker) | 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 recursion-ninja): Wondering if there's been any progress on this issue. The ability to use GHCi again would be much appreciated! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 17:09:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 17:09:11 -0000 Subject: [GHC] #15896: GHC API: add function to allow looking up Name for Located RdrName In-Reply-To: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> References: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> Message-ID: <059.fa73e0f7312ef1509e687d8fcf604070@haskell.org> #15896: GHC API: add function to allow looking up Name for Located RdrName -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHC API | Version: 8.6.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:D5330 Wiki Page: ApiNameMap | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 18:00:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 18:00:45 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.9c19918a9800a2a1e4d004ea7e4fd300@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > Annotations should also use the standard binary package for serialisation if it becomes a boot library. binary has been a boot library for a while now. Might be worth revisiting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 18:25:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 18:25:57 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.f3eeb8b6da33cee571a5642455a053fc@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): Another one: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} module Bug where import Data.Kind type Foo = forall (f :: Type -> Type). f f :: Foo Int -> Foo Int f x = x }}} {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the type ‘Foo Int -> Foo Int’ Non-*-like kind when *-like expected: * -> * when checking the body of forall: forall (f :: * -> *). f *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Bug"#) f :: Foo Int -> Foo Int [LclIdX] f = \ (x_aWa :: Foo Int) -> x_aWa end Rec } *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 19:13:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 19:13:01 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments Message-ID: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles on GHC 8.0.2 through 8.6.2: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C k where type S :: k -> Type data D :: Type -> Type data SD :: forall a. D a -> Type instance C (D a) where type S = SD }}} But fails to compile on GHC HEAD (commit 73cce63f33ee80f5095085141df9313ac70d1cfa): {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:3: error: • Type indexes must match class instance head Expected: S @(D a) Actual: S @(D a1) • In the type instance declaration for ‘S’ In the instance declaration for ‘C (D a)’ | 15 | type S = SD | ^^^^^^^^^^^ }}} This regression prevents [https://cs.brynmawr.edu/~rae/papers/2018/stitch/stitch.tar.gz the stitch library] from compiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 19:17:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 19:17:52 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.11a605b341129278bee7e3484181a17d@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A workaround is to manually give `SD` a kind ascription: {{{#!hs instance C (D a) where type S = (SD :: D a -> Type) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 20:55:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 20:55:57 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.c8c3204096707f3c1c5e59ea6e1c0fac@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I haven't confirmed this yet, but I believe the culprit is [http://git.haskell.org/ghc.git/blob/c77fbd94cc60301e5696b75cda44adb07da19a6a:/compiler/typecheck/TcTyClsDecls.hs#l1897 this part] of `tcTyFamInstEqnGuts`: {{{#!hs tc_lhs | null hs_pats -- See Note [Apparently-nullary families] = do { (args, rhs_kind) <- tcInstTyBinders $ splitPiTysInvisibleN (tyConArity fam_tc) (tyConKind fam_tc) ; return (mkTyConApp fam_tc args, rhs_kind) } | otherwise = tcFamTyPats fam_tc mb_clsinfo hs_pats }}} In the `null hs_pats` case, we are calling `tcInstTyBinders`, but that doesn't take the class-bound variables (in `mb_clsinfo`) into account! Some evidence which supports this theory: 1. The `otherwise` case (when the type family takes at least one argument) //does// take `mb_clsinfo` into account. You can see for yourself that this code works correctly by observing that this variant of the original program typechecks: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C k where type S z :: k -> Type data D :: Type -> Type data SD :: forall a. D a -> Type instance C (D a) where type S z = SD }}} 2. Before commit 2257a86daa72db382eb927df12a718669d5491f8 (`Taming the Kind Inference Monster`), which introduced this regression, the code that corresponded to `tc_lhs` was this: {{{#!hs kcTyFamEqnRhs mb_clsinfo rhs_hs_ty lhs_ki = do { -- It's still possible the lhs_ki has some foralls. Instantiate these away. (new_pats, insted_lhs_ki) <- instantiateTyUntilN mb_kind_env 0 lhs_ki }}} This code uses a function which is aware of the class-bound variables (`mb_kind_env`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 22:41:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 22:41:46 -0000 Subject: [GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP Message-ID: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> #16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | Keywords: Applicative, | Operating System: Unknown/Multiple Parsers, ReadP | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems there is some disagreement on what the type of `optional` should be, within `base`. `Control.Applicative` defines it as {{{#!haskell optional :: Alternative f => f a -> f (Maybe a) }}} By contrast, `Text.ParserCombinators.ReadP` defines it as {{{#!haskell optional :: ReadP a -> ReadP () }}} Worse, ReadP implements `Alternative`. So it entirely possible to specialise {{{#!haskell optional :: ReadP a -> ReadP (Maybe a). }}} In the broader Haskell ecosystem (and beyond) there is further confusion. The `Applicative` definition is used by `parsers`, `megaparsec` and purescript's `Data.Maybe`. The `ReadP` definition is used by `Parsec` and purescript's `Text.Parsing.StringParser`. `Cabal`, like `base` defines both. I propose to begin to deprecate `ReadP.optional` ASAP, following suggestions in https://www.reddit.com/r/haskell/comments/8cqgds/inconsistent_optional_definitions/. Code which used the old form may still compile; otherwise `void` should be applied. There have been some suggestions for new names for the `ReadP` definition, such as `optionally` or `optional_`. It may be worth exporting this function directly from `Control.Applicative`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 23:20:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 23:20:13 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.fc33d8d470d5abb2845f835794a1ad9c@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 Phab:D5423 -------------------------------------+------------------------------------- Changes (by davide): * differential: Phab:D5385 Phab:D5327 => Phab:D5385 Phab:D5327 Phab:D5423 Comment: I've created a patch Phab:D5423, with a note about future improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 7 23:51:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Dec 2018 23:51:14 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.487a2ff3bbb7554d94435bd193f32ef0@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5383 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged with ed86e3b531322f74d2c2d00d7ff8662b08fabde6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 00:16:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 00:16:31 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found In-Reply-To: <042.925a06cf3801c7d8163448594b84be93@haskell.org> References: <042.925a06cf3801c7d8163448594b84be93@haskell.org> Message-ID: <057.fa3f7a6f41c964de4230490e4e60408d@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5424 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 00:18:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 00:18:24 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.158bafee527d7619f186d0809fb7e58e@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.3 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:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 00:18:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 00:18:54 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.3a5fca0a6536a8dcb54cf88f5b883c32@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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): Phab:D5394 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.3 => 8.8.1 Old description: > Repro as follows. > > A.hs: > {{{ > {-# OPTIONS_GHC -fno-full-laziness #-} > module A (toTypedData, toTypedDataNoDef) where > > toTypedData :: String -> IO Int > toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s > > wrapPrint :: String -> IO Int -> IO Int > wrapPrint s act = do > putStrLn s > act > > toTypedDataNoDef :: String -> IO Int > toTypedDataNoDef s = return $ length s > }}} > > B.hs: > {{{ > module B ( TypeClass(..) ) where > > import A > > class Show a => TypeClass a where > getSize :: a -> IO Int > getSize a = toTypedData (show a) > > printA :: a -> IO () > }}} > > C.hs: > {{{ > module Main where > > import B > > data MyDataType = MyDataType String Int deriving Show > > instance TypeClass MyDataType where > printA = putStrLn . show > > main :: IO () > main = do > let myValue = MyDataType "haha" 99 > sz <- getSize myValue > putStrLn $ show sz > printA myValue > }}} > > 1. Comment out the `-fno-full-laziness` option in A.hs > 2. `rm *.o *.hi; ghc -O2 C.hs` > 3. Re-enable the `-fno-full-laziness` option in A.hs > 4. `ghc -O2 C.hs` > > Produces a linker error: > > {{{ > C.o:Main_main1_info: error: undefined reference to > 'A_toTypedData2_closure' > C.o(.data.rel.ro+0x48): error: undefined reference to > 'A_toTypedData2_closure' > collect2: error: ld returned 1 exit status > }}} > > Reproduced in 8.0, 8.4 and master. Probably happens in all released > versions of GHC. New description: Repro as follows. A.hs: {{{#!hs {-# OPTIONS_GHC -fno-full-laziness #-} module A (toTypedData, toTypedDataNoDef) where toTypedData :: String -> IO Int toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s wrapPrint :: String -> IO Int -> IO Int wrapPrint s act = do putStrLn s act toTypedDataNoDef :: String -> IO Int toTypedDataNoDef s = return $ length s }}} B.hs: {{{#!hs module B ( TypeClass(..) ) where import A class Show a => TypeClass a where getSize :: a -> IO Int getSize a = toTypedData (show a) printA :: a -> IO () }}} C.hs: {{{ module Main where import B data MyDataType = MyDataType String Int deriving Show instance TypeClass MyDataType where printA = putStrLn . show main :: IO () main = do let myValue = MyDataType "haha" 99 sz <- getSize myValue putStrLn $ show sz printA myValue }}} 1. Comment out the `-fno-full-laziness` option in A.hs 2. `rm *.o *.hi; ghc -O2 C.hs` 3. Re-enable the `-fno-full-laziness` option in A.hs 4. `ghc -O2 C.hs` Produces a linker error: {{{ C.o:Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data.rel.ro+0x48): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status }}} Reproduced in 8.0, 8.4 and master. Probably happens in all released versions of GHC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 00:19:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 00:19:08 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.192268b30242254ee6d5c6fc2c32812b@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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): Phab:D5394 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Repro as follows. > > A.hs: > {{{#!hs > {-# OPTIONS_GHC -fno-full-laziness #-} > module A (toTypedData, toTypedDataNoDef) where > > toTypedData :: String -> IO Int > toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s > > wrapPrint :: String -> IO Int -> IO Int > wrapPrint s act = do > putStrLn s > act > > toTypedDataNoDef :: String -> IO Int > toTypedDataNoDef s = return $ length s > }}} > > B.hs: > {{{#!hs > module B ( TypeClass(..) ) where > > import A > > class Show a => TypeClass a where > getSize :: a -> IO Int > getSize a = toTypedData (show a) > > printA :: a -> IO () > }}} > > C.hs: > {{{ > module Main where > > import B > > data MyDataType = MyDataType String Int deriving Show > > instance TypeClass MyDataType where > printA = putStrLn . show > > main :: IO () > main = do > let myValue = MyDataType "haha" 99 > sz <- getSize myValue > putStrLn $ show sz > printA myValue > }}} > > 1. Comment out the `-fno-full-laziness` option in A.hs > 2. `rm *.o *.hi; ghc -O2 C.hs` > 3. Re-enable the `-fno-full-laziness` option in A.hs > 4. `ghc -O2 C.hs` > > Produces a linker error: > > {{{ > C.o:Main_main1_info: error: undefined reference to > 'A_toTypedData2_closure' > C.o(.data.rel.ro+0x48): error: undefined reference to > 'A_toTypedData2_closure' > collect2: error: ld returned 1 exit status > }}} > > Reproduced in 8.0, 8.4 and master. Probably happens in all released > versions of GHC. New description: Repro as follows. A.hs: {{{#!hs {-# OPTIONS_GHC -fno-full-laziness #-} module A (toTypedData, toTypedDataNoDef) where toTypedData :: String -> IO Int toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s wrapPrint :: String -> IO Int -> IO Int wrapPrint s act = do putStrLn s act toTypedDataNoDef :: String -> IO Int toTypedDataNoDef s = return $ length s }}} B.hs: {{{#!hs module B ( TypeClass(..) ) where import A class Show a => TypeClass a where getSize :: a -> IO Int getSize a = toTypedData (show a) printA :: a -> IO () }}} C.hs: {{{#!hs module Main where import B data MyDataType = MyDataType String Int deriving Show instance TypeClass MyDataType where printA = putStrLn . show main :: IO () main = do let myValue = MyDataType "haha" 99 sz <- getSize myValue putStrLn $ show sz printA myValue }}} 1. Comment out the `-fno-full-laziness` option in A.hs 2. `rm *.o *.hi; ghc -O2 C.hs` 3. Re-enable the `-fno-full-laziness` option in A.hs 4. `ghc -O2 C.hs` Produces a linker error: {{{ C.o:Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data.rel.ro+0x48): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status }}} Reproduced in 8.0, 8.4 and master. Probably happens in all released versions of GHC. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 02:32:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 02:32:49 -0000 Subject: [GHC] #16006: Framework failures when validating In-Reply-To: <043.59ba316e797f664777821326c3e2f316@haskell.org> References: <043.59ba316e797f664777821326c3e2f316@haskell.org> Message-ID: <058.13c2dd55cc70f807850f9da16aa6ff84@haskell.org> #16006: Framework failures when validating -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.10.1 Comment: Fixed with a6b4da8cd2e60618ae1819fbfc992b4958e40006. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 03:34:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 03:34:03 -0000 Subject: [GHC] #15902: dead symbol warning error in rts base In-Reply-To: <045.3733b3a97e244142f0d34dba5301153a@haskell.org> References: <045.3733b3a97e244142f0d34dba5301153a@haskell.org> Message-ID: <060.dfbcdc6dfe56969ff988a781b815ade5@haskell.org> #15902: dead symbol warning error in rts base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.6.3 => 8.8.1 Comment: This is fixed in `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 03:46:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 03:46:13 -0000 Subject: [GHC] #15946: configure script makes use of ln -v flag which is not supported in OpenBSD In-Reply-To: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> References: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> Message-ID: <061.d8f8fd6b0de1042f5e949a8dff144d39@haskell.org> #15946: configure script makes use of ln -v flag which is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: configure Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5425 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5425 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 04:28:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 04:28:36 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.df78468bd849952705a32893389e9991@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | Version: 8.2.2 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 Ben Gamari ): In [changeset:"07e02d578538248aa12bd3f5a77c76ccfdc9e0db/ghc" 07e02d57/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07e02d578538248aa12bd3f5a77c76ccfdc9e0db" Add some complexities to Data.List documentation (#15003) Namely for: - head - uncons - tail - last - init - null }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 04:43:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 04:43:04 -0000 Subject: [GHC] #15130: Hadrian doesn't rebuild changed `CoreUtils.hs` In-Reply-To: <047.f868c2b92f1e49a78a6523a178230534@haskell.org> References: <047.f868c2b92f1e49a78a6523a178230534@haskell.org> Message-ID: <062.6eac2d5b4dbf9b01c61dff0dc087b12e@haskell.org> #15130: Hadrian doesn't rebuild changed `CoreUtils.hs` -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.4.2 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) * component: Build System (make) => Build System (Hadrian) Comment: This is definitely about Hadrian... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:04:45 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found In-Reply-To: <042.925a06cf3801c7d8163448594b84be93@haskell.org> References: <042.925a06cf3801c7d8163448594b84be93@haskell.org> Message-ID: <057.4996a44ea6a41de00ccdb2e5537eaad8@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cb882fc993b4972f7f212b291229ef9e9ade0af9/ghc" cb882fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb882fc993b4972f7f212b291229ef9e9ade0af9" Require 'libdw' for '--enable-dwarf-unwind' This causes './configure --enable-dwarf-unwind' to exit with a helpful error message when 'libdw' cannot be found (compared to the previous behaviour of silently pretending the user hadn't requested DWARF support at all). Test Plan: ./configure --enable-dwarf-unwind # on systems with/without libdw Reviewers: bgamari, nh2 Reviewed By: nh2 Subscribers: nh2, rwbarton, erikd, carter GHC Trac Issues: #15968 Differential Revision: https://phabricator.haskell.org/D5424 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:04:45 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.27a980bf86d35ce3536004174cd18edc@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412, Wiki Page: | Phab:D5422 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"665f8b0c778b3a5dac4696f81da0cea88b101ea9/ghc" 665f8b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="665f8b0c778b3a5dac4696f81da0cea88b101ea9" hadrian: eliminate most of the remaining big rule enumerations Following what was done to Rules.Library some time ago and to Rules.Compile recently (D5412), this patch moves more rules away from the "enumerate a lot of contexts and generate one rule for each" style and instead uses the "parse data from file path to recover context" approach. In fact, the only rules left to convert seem to be the ones from Rules.Generate. This effectively decreases the pauses described in #15938 further as well as the amount of allocations and GC that we do, unsurprisingly. Nowhere as drastically as D5412, though. Test Plan: perform full build and generate docs Reviewers: snowleopard, bgamari Reviewed By: snowleopard Subscribers: rwbarton, carter GHC Trac Issues: #15938 Differential Revision: https://phabricator.haskell.org/D5422 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:04:45 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell In-Reply-To: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> References: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> Message-ID: <064.b0c60e6d3b42401f1331fb7f1f5770cd@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5360 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"45e98f64e82f6ff16dc3e437c3031b9d315f1313/ghc" 45e98f64/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45e98f64e82f6ff16dc3e437c3031b9d315f1313" Add -fno-safe-haskell flag This flag can be set to turn off the Safe Haskell checks. Whether a module is marked Safe/Unsafe/Trustworthy is ignored when this flag to set. Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter GHC Trac Issues: #15920 Differential Revision: https://phabricator.haskell.org/D5360 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:04:45 -0000 Subject: [GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o In-Reply-To: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> References: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> Message-ID: <065.4717e3e1e6744cb8b0fd4ba096df0180@haskell.org> #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T15369 Blocked By: | Blocking: Related Tickets: #15085 | Differential Rev(s): Phab:D5376 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"57c9b1ae4cafd0ee763451f2d4bc10220eef9689/ghc" 57c9b1ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="57c9b1ae4cafd0ee763451f2d4bc10220eef9689" Fix #15369: GHCi doesn't honor :set +c when loading for a second time The decision to (re)collect the type info for a (re)loaded module is now taken only by comparing the file timestamps of the .hs file of the module. (Or form the .o file if the .hs file is missing). If the file timestamp changes, we (re)collect the type info. The timestamp of the processing time of the last collect is no longer used. Test Plan: make test TEST=T15369 Reviewers: alanz, hvr, monoidal, osa1, thomie, bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter GHC Trac Issues: #15369 Differential Revision: https://phabricator.haskell.org/D5376 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:12:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:12:49 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found In-Reply-To: <042.925a06cf3801c7d8163448594b84be93@haskell.org> References: <042.925a06cf3801c7d8163448594b84be93@haskell.org> Message-ID: <057.3ecaf6e6dce1a8953bbc9e94ad351f96@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | 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:D5424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:14:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:14:02 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell In-Reply-To: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> References: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> Message-ID: <064.82a9fa3186e37eb3162743fb336603e6@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5360 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 05:14:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 05:14:09 -0000 Subject: [GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o In-Reply-To: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> References: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> Message-ID: <065.b2b12880b000d3fc78fed1d67cac84cd@haskell.org> #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T15369 Blocked By: | Blocking: Related Tickets: #15085 | Differential Rev(s): Phab:D5376 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 10:19:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 10:19:35 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList Message-ID: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: ⊥ Component: | Version: 8.7 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `Data.OldList`: {{{ #!haskell infix 5 \\ -- comment to fool cpp: https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#cpp-string-gaps }}} Looks like the URL changed to: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html #cpp-and-string-gaps -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 10:22:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 10:22:50 -0000 Subject: [GHC] #16011: GHCi leaks memory even with -fno-it. Message-ID: <047.87b5a3aa449632bbf05a6f556592069a@haskell.org> #16011: GHCi leaks memory even with -fno-it. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: GHCi | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi leaks are not exactly new, but this one is especially easy to trigger/reproduce. The memory allocated by f never gets freed. {{{ PS E:\binary-perf> ..\ghc-8.6.1\bin\ghci.exe -fno-it GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Prelude> f = [1 .. 20000000] :: [Int] Prelude> length f 20000000 Prelude> f = [1 .. 20000001] :: [Int] Prelude> length f 20000001 Prelude> f = [1 .. 20000002] :: [Int] Prelude> length f 20000002 Prelude> f = [1 .. 20000000] :: [Int] Prelude> length f 20000000 Prelude> }}} Or using head and even simpler: {{{ PS E:\binary-perf> ..\ghc_commonAsm\inplace\bin\ghci.exe -fno-it GHCi, version 8.7.20181207: http://www.haskell.org/ghc/ :? for help Loaded package environment from E:\binary- perf\.ghc.environment.x86_64-mingw32-8.7.20181207 Prelude> f = replicate 2000000 False Prelude> length f 2000000 Prelude> f = replicate 2000000 False Prelude> length f 2000000 Prelude> f = replicate 2000000 False Prelude> length f 2000000 Prelude> f = replicate 2000000 False Prelude> length f }}} GHC just keeps using more and more memory when I repeat this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 10:30:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 10:30:42 -0000 Subject: [GHC] #16012: set/getAllocationCounter is broken in GHCi Message-ID: <047.47e6ba0d4a10a32bc08881d654fc48c5@haskell.org> #16012: set/getAllocationCounter is broken in GHCi -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It doesn't seem obvious why it shouldn't work in GHCi, hence the report. {{{ Prelude System.Mem> getAllocationCounter 9223372036854757447 Prelude System.Mem> setAllocationCounter 0 () Prelude System.Mem> getAllocationCounter 9223372036854758855 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 10:31:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 10:31:11 -0000 Subject: [GHC] #16012: set/getAllocationCounter is broken in GHCi In-Reply-To: <047.47e6ba0d4a10a32bc08881d654fc48c5@haskell.org> References: <047.47e6ba0d4a10a32bc08881d654fc48c5@haskell.org> Message-ID: <062.021b2f3df72002d692b447eb4a7e5cde@haskell.org> #16012: set/getAllocationCounter is broken in GHCi -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: GHCi | Version: 8.7 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 AndreasK): * failure: None/Unknown => Incorrect result at runtime * version: 8.6.2 => 8.7 * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 12:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 12:26:59 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.e487a3dbac51e2b804ef2b957a145356@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: michalt Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754, | Differential Rev(s): Phab:D3973, #14989 | Phab:D3999 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #9157, #14754 => #9157, #14754, #14989 Comment: For anyone wondering this has been reverted because of issues with ProcPoint invariants. See #14989 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 12:30:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 12:30:36 -0000 Subject: [GHC] #16007: Implement `-Os` In-Reply-To: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> References: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> Message-ID: <059.ceaf9c649b611f7f23a943c8b0fbc1a1@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16005, #12915, | Differential Rev(s): #14226 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #16005 => #16005, #12915, #14226 Comment: There were also attempts to run a second common block elimination pass a while ago. That ran into some bugs and in the end went nowhere but would be another good idea for -Os. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 13:30:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 13:30:41 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases Message-ID: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a ghci session: {{{ > :set -XTypeFamilies -XPolyKinds > type family Id (a :: k) > type instance Id a = a > type Foo x = Maybe > :kind! Id Foo Id Foo :: * = Id Foo }}} I think the final `:kind!` query should throw an error instead, complaining that `Foo` hasn't been given enough arguments. (But even if you disagree, and think it should be allowed, `*` is clearly not the right kind!) Using a normal type alias in place of the type family for `Id` also allows the query incorrectly, though it does at least report a sensible kind. Although I think it shouldn't matter, I have checked with `-ignore-dot- ghci` to make sure I haven't accidentally turned LiberalTypeSynonyms on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 13:43:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 13:43:23 -0000 Subject: [GHC] #16014: Avoid unnecessary code duplication from String Literals. Message-ID: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> #16014: Avoid unnecessary code duplication from String Literals. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When we compile a function like this: {{{ foo :: Int -> String foo 1 = "1_String" foo 2 = "2_String" foo 3 = "3_String" foo 4 = "4_String" foo 5 = "5_String" foo _ = "unknown_string" }}} We get a few things. Obviously there are the actual strings: {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} Foo.foo10 :: GHC.Prim.Addr# Foo.foo10 = "1_String"# }}} There is no way around these so that's fine. Then we end up with a function to unpack the actual string. {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} Foo.foo9 :: [Char] [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Foo.foo9 = GHC.CString.unpackCString# Foo.foo10 }}} We want to have a closure for each of these. Otherwise we end up constructing a new string each time, which would be a waste. So on the surface this is fine. However we end up with one of these for each string. Looking at the Cmm/Asm the functions are not THAT small. {{{ [Foo.foo9_entry() // [R1] { info_tbls: [(c2hj, label: Foo.foo9_info rep: HeapRep static { Thunk } srt: Nothing)] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2hj: // global if ((Sp + -16) < SpLim) (likely: False) goto c2hk; else goto c2hl; c2hk: // global R1 = R1; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; c2hl: // global (_c2hg::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1); if (_c2hg::I64 == 0) goto c2hi; else goto c2hh; c2hi: // global call (I64[R1])() args: 8, res: 0, upd: 8; c2hh: // global I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c2hg::I64; R2 = Foo.foo10_bytes; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; } } }}} In actual code size (HEAD/-O2) the code + info table is about 100Byte. To give an idea in my current ghc-stage2 I have 12,409 calls to unpackCString, and I assume 99% of them are from actual strings. So that comes out to about one megabyte. Out of a binary size of 84MB, so surprisingly significant actually! == Now what can we do about this! I think the right way to go here is to define a `unpackString` function which does the actual work. Then we jump into that from a small per-string wrapper. So we would end up with code like: {{{ [Foo.foo9_entry() // [R1] c2hj: // R1 = Closure pointer R2 = Foo.foo10_bytes; call (unpackString)(R1,R2) args: 8, res: 0, upd: 8; } }}} Which should be well under 50 bytes. It does cause an extra indirection when unpacking the String, but if the performance of that matters using String is likely the wrong choice to begin with. How to actually get GHC to generate code like that I'm not sure yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 13:46:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 13:46:31 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.9217e94d003e3ed82cb4387d0bf78f34@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.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 dmwit): Okay, so further thinking, I'd like to retract part of the complaint. I believe I understand why it decides on kind `*`, and agree that's a sensible answer. (Namely: I thought in my head `Id :: k -> k`, but the compiler chose `Id :: k -> *`, following exactly the rules set out in the documentation, so the compiler was right and I was wrong. And I thought in my head `Id a = a` matches all types so `Id Foo` should reduce to `Foo` if it works at all, but the compiler thought `Id a = a` only matches when `a :: *`, so `Id Foo` is a stuck term not one that can reduce, and again the compiler was right and I was wrong.) But I still think it should probably complain about applying a type family or type alias to an unsaturated type alias. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 13:57:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 13:57:34 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.c9acae0afe505bca28dedc64ef0c5c7e@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The following patch makes the original program compile again: {{{#!diff diff --git a/compiler/typecheck/Inst.hs b/compiler/typecheck/Inst.hs index 284d6a95d3..991f7eb859 100644 --- a/compiler/typecheck/Inst.hs +++ b/compiler/typecheck/Inst.hs @@ -487,18 +487,19 @@ no longer cut it, but it seems fine for now. -- | Instantantiate the TyConBinders of a forall type, -- given its decomposed form (tvs, ty) tcInstTyBinders :: HasDebugCallStack - => ([TyCoBinder], TcKind) -- ^ The type (forall bs. ty) + => Maybe (VarEnv Kind) + -> ([TyCoBinder], TcKind) -- ^ The type (forall bs. ty) -> TcM ([TcType], TcKind) -- ^ Instantiated bs, substituted ty -- Takes a pair because that is what splitPiTysInvisible returns -- See also Note [Bidirectional type checking] -tcInstTyBinders (bndrs, ty) +tcInstTyBinders mb_kind_info (bndrs, ty) | null bndrs -- It's fine for bndrs to be empty e.g. = return ([], ty) -- Check that (Maybe :: forall {k}. k->*), -- and see the call to instTyBinders in checkExpectedKind -- A user bug to be reported as such; it is not a compiler crash! | otherwise - = do { (subst, args) <- mapAccumLM (tcInstTyBinder Nothing) empty_subst bndrs + = do { (subst, args) <- mapAccumLM (tcInstTyBinder mb_kind_info) empty_subst bndrs ; ty' <- zonkTcType (substTy subst ty) -- Why zonk the result? So that tcTyVar can -- obey (IT6) of Note [The tcType invariant] in TcHsType diff --git a/compiler/typecheck/TcHsType.hs b/compiler/typecheck/TcHsType.hs index 3b36281d4a..39f26949ae 100644 --- a/compiler/typecheck/TcHsType.hs +++ b/compiler/typecheck/TcHsType.hs @@ -1021,7 +1021,7 @@ checkExpectedKindX pp_hs_ty ty act_kind exp_kind let n_exp_invis_bndrs = invisibleTyBndrCount exp_kind n_act_invis_bndrs = invisibleTyBndrCount act_kind n_to_inst = n_act_invis_bndrs - n_exp_invis_bndrs - ; (new_args, act_kind') <- tcInstTyBinders (splitPiTysInvisibleN n_to_inst act_kind) + ; (new_args, act_kind') <- tcInstTyBinders Nothing (splitPiTysInvisibleN n_to_inst act_kind) ; let origin = TypeEqOrigin { uo_actual = act_kind' , uo_expected = exp_kind @@ -1133,7 +1133,7 @@ tcTyVar mode name -- Could be a tyvar, a tycon, or a datacon | otherwise = do { let tc_arity = tyConArity tc ; tc_kind <- zonkTcType (tyConKind tc) - ; (tc_args, kind) <- tcInstTyBinders (splitPiTysInvisibleN tc_arity tc_kind) + ; (tc_args, kind) <- tcInstTyBinders Nothing (splitPiTysInvisibleN tc_arity tc_kind) -- Instantiate enough invisible arguments -- to saturate the family TyCon diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index 877166dfd5..0700f94202 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -1895,13 +1895,17 @@ tcTyFamInstEqnGuts fam_tc mb_clsinfo imp_vars exp_bndrs hs_pats hs_rhs_ty ; return (qtvs, pats, rhs_ty) } where tc_lhs | null hs_pats -- See Note [Apparently-nullary families] - = do { (args, rhs_kind) <- tcInstTyBinders $ + = do { (args, rhs_kind) <- tcInstTyBinders mb_kind_env $ splitPiTysInvisibleN (tyConArity fam_tc) (tyConKind fam_tc) ; return (mkTyConApp fam_tc args, rhs_kind) } | otherwise = tcFamTyPats fam_tc mb_clsinfo hs_pats + mb_kind_env = case mb_clsinfo of + NotAssociated -> Nothing + InClsInst{ai_inst_env = kind_env} -> Just kind_env + {- Note [Apparently-nullary families] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider diff --git a/testsuite/tests/indexed-types/should_fail/T9160.stderr b/testsuite/tests/indexed-types/should_fail/T9160.stderr index e918013f67..14f204191e 100644 --- a/testsuite/tests/indexed-types/should_fail/T9160.stderr +++ b/testsuite/tests/indexed-types/should_fail/T9160.stderr @@ -1,7 +1,7 @@ -T9160.hs:19:3: error: - • Type indexes must match class instance head - Expected: F @* - Actual: F @(* -> *) - • In the type instance declaration for ‘F’ +T9160.hs:19:12: error: + • Expecting one more argument to ‘Maybe’ + Expected a type, but ‘Maybe’ has kind ‘* -> *’ + • In the type ‘Maybe’ + In the type instance declaration for ‘F’ In the instance declaration for ‘C (a :: *)’ }}} As you can see, there is one existing test (`T9160`) whose expected stderr changed, but the new error message arguably makes as much sense as the previous one. (For what it's worth, that new error message used to be the expected stderr before commit https://ghc.haskell.org/trac/ghc/changeset/2257a86daa72db382eb927df12a718669d5491f8/ghc landed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 13:58:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 13:58:20 -0000 Subject: [GHC] #16014: Avoid unnecessary code duplication from String Literals. In-Reply-To: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> References: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> Message-ID: <062.1ab4a5d3740111baef82241a3e32cd37@haskell.org> #16014: Avoid unnecessary code duplication from String Literals. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): #15133 is another take on this topic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 14:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 14:09:25 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.65ef83bb60a5b3696b2935c570201ef0@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16014 | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #16014 Comment: The string caf code also contributes significantly to code size. See #16014 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 14:56:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 14:56:49 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.82311abedb53f4bb8244c511919d21c0@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13962 Comment: `:kind` deliberately allows unsaturated uses of type synonyms and type families—see [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/ghci.html #ghci-cmd-:kind this section] of the users' guide. Many folks find it quite handy to be able to query the kinds of type synonyms with `:kind` (e.g., `:kind Id`), but disallowing unsaturated type synonyms/families //carte blanche// would prevent `:kind Id` from working, so a special case was added to allow it in that particular scenario. (Also note that this has been previously discussed in #13962.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 15:55:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 15:55:11 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.6113c2008fae962bd1bbf8d696bb9d27@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): This //passes// `-dcore-lint`, however: {{{#!hs {-# LANGUAGE RankNTypes #-} module Works where f :: (forall. Maybe) a f = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 15:56:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 15:56:26 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.2ecdef0f86e4cb0f1941370524465e0a@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): Sure, I understand the motivation. It seems like a sensible middle ground would be to special-case only top- level unsaturated type aliases/families, and not wholesale allow unsaturation. And indeed the way the documentation was written makes it sound like that's the case: it uses the precise language ":kind even allows you to write a partial application of a type synonym", whereas `Id Foo` is not a partial application of a type synonym but rather the application of a type (family) to a partial application of a type synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 16:00:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 16:00:58 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.aa611cd3879c285bd56a7ee03d51eea1@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 dmwit]: > whereas `Id Foo` is not a partial application of a type synonym but rather the application of a type (family) to a partial application of a type synonym. Indeed. Still, removing this feature would be a breaking change (albeit a slight one), so that's something to consider. It might be worth opening a [https://github.com/ghc-proposals/ghc-proposals GHC proposal] about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 16:35:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 16:35:18 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header (was: GHC warnings do not respect the default module header) In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.1be75111580fcd18802d180e11772f6f@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn 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 RolandSenn): Testing my patch, I found some behaviour, that may be unexpected / annoying for ghci users, specially beginners: Consider a module Foo.hs without a `main` function and without a module header: {{{ nomain :: IO () nomain = putStrLn usedVar usedVar :: String usedVar = "T13839" }}} Compiling with GHC 8.6 (`ghc -Wall Foo.hs`) gives: {{{ [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Foo.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ }}} Loading into GHCi ''just works'': {{{ ghci -Wall Foo.hs GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Foo.hs, interpreted ) Ok, one module loaded. *Main> }}} Now with the new warnings I get: {{{ GHCi, version 8.7.20181207: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:2:1: warning: [-Wunused-top-binds] Defined but not used: ‘nomain’ Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: ‘usedVar’ Ok, one module loaded. *Main> }}} We get the same warnings with GHC-8.6, after adding a `main` function. **In a module without a module header and without a `main` function GHCi will report ALL top level names as unused! ** Therefore I propose to issue the requested warnings in GHCi only, if there is a `main` function available! @Feuerbach: Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 16:44:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 16:44:31 -0000 Subject: [GHC] #16015: git notes logic breaks CircleCI validation of pull requests Message-ID: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> #16015: git notes logic breaks CircleCI validation of pull requests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Due to missing credentials. David, can you have a look? https://circleci.com/gh/ghc/ghc/12493 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 16:50:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 16:50:31 -0000 Subject: [GHC] #16014: Avoid unnecessary code duplication from String Literals. In-Reply-To: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> References: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> Message-ID: <062.8e73fc315218d6d809c230af68102c68@haskell.org> #16014: Avoid unnecessary code duplication from String Literals. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15113 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #15113 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 17:38:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 17:38:02 -0000 Subject: [GHC] #15444: 8.4.3 has an undocumented dependency on libnuma. In-Reply-To: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> References: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> Message-ID: <062.09dded44f4812f9791eec32c4496440b@haskell.org> #15444: 8.4.3 has an undocumented dependency on libnuma. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.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 AndreasK): * status: closed => new * priority: high => normal * resolution: fixed => * milestone: 8.6.1 => 8.6.3 Comment: Seems this made it's way back into the new 8.6 release. {{{ 4:33 PM with ghc 8.6.3 on debian I need to install libnuma-dev, else linking fails. Not the case with 8.6.2. I did install the deb9 version, where before it was deb8 4:33 PM is this expected? See https://gist.github.com/alanz/243da5983d46862dd2a72a0b2ecc5369 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 17:38:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 17:38:48 -0000 Subject: [GHC] #15444: 8.4.3 has an undocumented dependency on libnuma. In-Reply-To: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> References: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> Message-ID: <062.a24963a401a01bda0d9cb6c4e1916aa1@haskell.org> #15444: 8.4.3 has an undocumented dependency on libnuma. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.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 AndreasK): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 18:53:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 18:53:57 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.7348852a8594ba61cb49aa4c92987913@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | Phab:D5398 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 19:11:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 19:11:56 -0000 Subject: [GHC] #15794: shell.nix depends on build artifacts In-Reply-To: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> References: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> Message-ID: <063.24f1cc1b8ee1a194a8cd8e82aba73d15@haskell.org> #15794: shell.nix depends on build artifacts -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c00d2f59df1f3707d529531fd0c6b55903516ec4/ghc" c00d2f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c00d2f59df1f3707d529531fd0c6b55903516ec4" hadrian: Drop nix build script It's currently too out-of-date to build current hadrian and is arguably completely broken anyways (see #15794). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 19:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 19:12:35 -0000 Subject: [GHC] #15794: shell.nix depends on build artifacts In-Reply-To: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> References: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> Message-ID: <063.87172c292860790fc4a02be4185e5de0@haskell.org> #15794: shell.nix depends on build artifacts -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It has been removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 20:19:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 20:19:18 -0000 Subject: [GHC] #16016: Hadrian build fails on FreeBSD Message-ID: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> #16016: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A plain hadrian build using `hadrian/build.cabal.sh` fails with {{{ /---------------------------------------------------------------------------------\ | Successfully built program 'ghc-pkg' (Stage0). | | Executable: _build/stage0/bin/ghc-pkg | | Program synopsis: A utility for querying and managing the GHC package database. | \---------------------------------------------------------------------------------/ hadrian: '/usr/home/ben/ghc/_build/stage0/bin/ghc' exited with an error: ghc: missing -B option shakeArgsWith 0.000s 0% Function shake 0.392s 0% Database read 0.000s 0% With database 0.000s 0% Running rules 1725.240s 99% ========================= Total 1725.633s 100% Error when running Shake build system: at src/Rules.hs:(32,19)-(45,17): at src/Rules.hs:45:5-17: * Depends on: _build/stage1/lib/bin/unlit at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (PackageDataFile (Context {stage = Stage1, package = Package {pkgLanguage = Haskell, pkgType = Program, pkgName = "unlit", pkgPath = "utils/unlit"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:200:5-36: * Depends on: _build/stage1/utils/unlit/setup-config * Raised the exception: ExitFailure 1 }}} on FreeBSD 11 on amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 8 20:23:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Dec 2018 20:23:14 -0000 Subject: [GHC] #16016: Hadrian build fails on FreeBSD In-Reply-To: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> References: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> Message-ID: <061.74270b9c3c14a4669716e12fdea0ddce@haskell.org> #16016: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: 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: > A plain hadrian build using `hadrian/build.cabal.sh` fails with > {{{ > /---------------------------------------------------------------------------------\ > | Successfully built program 'ghc-pkg' (Stage0). > | > | Executable: _build/stage0/bin/ghc-pkg > | > | Program synopsis: A utility for querying and managing the GHC package > database. | > \---------------------------------------------------------------------------------/ > hadrian: '/usr/home/ben/ghc/_build/stage0/bin/ghc' exited with an error: > ghc: missing -B option > > shakeArgsWith 0.000s 0% > Function shake 0.392s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 1725.240s 99% ========================= > Total 1725.633s 100% > Error when running Shake build system: > at src/Rules.hs:(32,19)-(45,17): > at src/Rules.hs:45:5-17: > * Depends on: _build/stage1/lib/bin/unlit > at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: > * Depends on: OracleQ (PackageDataFile (Context {stage = Stage1, package > = Package {pkgLanguage = Haskell, pkgType = Program, pkgName = "unlit", > pkgPath = "utils/unlit"}, way = v})) > at src/Hadrian/Haskell/Cabal/Parse.hs:200:5-36: > * Depends on: _build/stage1/utils/unlit/setup-config > * Raised the exception: > ExitFailure 1 > }}} > > on FreeBSD 11 on amd64. New description: A plain hadrian build using `hadrian/build.cabal.sh` bootstrapped with GHC 8.4.3 from `ports` fails with {{{ /---------------------------------------------------------------------------------\ | Successfully built program 'ghc-pkg' (Stage0). | | Executable: _build/stage0/bin/ghc-pkg | | Program synopsis: A utility for querying and managing the GHC package database. | \---------------------------------------------------------------------------------/ hadrian: '/usr/home/ben/ghc/_build/stage0/bin/ghc' exited with an error: ghc: missing -B option shakeArgsWith 0.000s 0% Function shake 0.392s 0% Database read 0.000s 0% With database 0.000s 0% Running rules 1725.240s 99% ========================= Total 1725.633s 100% Error when running Shake build system: at src/Rules.hs:(32,19)-(45,17): at src/Rules.hs:45:5-17: * Depends on: _build/stage1/lib/bin/unlit at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (PackageDataFile (Context {stage = Stage1, package = Package {pkgLanguage = Haskell, pkgType = Program, pkgName = "unlit", pkgPath = "utils/unlit"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:200:5-36: * Depends on: _build/stage1/utils/unlit/setup-config * Raised the exception: ExitFailure 1 }}} on FreeBSD 11 on amd64. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 00:43:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 00:43:02 -0000 Subject: [GHC] #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory Message-ID: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Currently GHC uses a lot of memory to build a relatively small module and causes my CI to fail due to there being a 4G memory limit. The source code can be found here: https://github.com/haskell-works/hw- json/tree/73368cee21dc72eedd5291ba689f9abf10e7fcd2 The problem module is here: https://github.com/haskell-works/hw- json/blob/73368cee21dc72eedd5291ba689f9abf10e7fcd2/test/HaskellWorks/Data/Json/Backend/Standard/Succinct/CursorSpec.hs The build output follows: {{{ cabal new-build --enable-tests --enable-benchmarks --project- file="cabal.project" -j${CABAL_THREADS:-4} all Build profile: -w ghc-8.6.2 -O2 In order, the following will be built (use -v for more details): - hw-json-0.9.0.1 (lib) (first run) - hw-json-0.9.0.1 (test:hw-json-test) (first run) - hw-json-0.9.0.1 (exe:hw-json) (first run) - hw-json-0.9.0.1 (bench:bench) (first run) Configuring library for hw-json-0.9.0.1.. Preprocessing library for hw-json-0.9.0.1.. Building library for hw-json-0.9.0.1.. [ 1 of 32] Compiling HaskellWorks.Data.Json.DecodeError ( src/HaskellWorks/Data/Json/DecodeError.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/DecodeError.o ) [ 2 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.MakeIndex ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/MakeIndex.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/MakeIndex.o ) [ 3 of 32] Compiling HaskellWorks.Data.Json.Internal.Index ( src/HaskellWorks/Data/Json/Internal/Index.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Index.o ) [ 4 of 32] Compiling HaskellWorks.Data.Json.Internal.PartialIndex ( src/HaskellWorks/Data/Json/Internal/PartialIndex.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/PartialIndex.o ) [ 5 of 32] Compiling HaskellWorks.Data.Json.Internal.Token.Types ( src/HaskellWorks/Data/Json/Internal/Token/Types.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Token/Types.o ) [ 6 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.Token.Tokenize ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/Token/Tokenize.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/Token/Tokenize.o ) [ 7 of 32] Compiling HaskellWorks.Data.Json.Internal.Token ( src/HaskellWorks/Data/Json/Internal/Token.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Token.o ) [ 8 of 32] Compiling HaskellWorks.Data.Json.Internal.Value ( src/HaskellWorks/Data/Json/Internal/Value.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Value.o ) [ 9 of 32] Compiling HaskellWorks.Data.Json.Internal.Word8 ( src/HaskellWorks/Data/Json/Internal/Word8.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Word8.o ) [10 of 32] Compiling HaskellWorks.Data.Json.Internal.Word64 ( src/HaskellWorks/Data/Json/Internal/Word64.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Word64.o ) [11 of 32] Compiling HaskellWorks.Data.Json.Internal.CharLike ( src/HaskellWorks/Data/Json/Internal/CharLike.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/CharLike.o ) [12 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.Blank ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/Blank.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/Blank.o ) [13 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.BlankedJson ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/BlankedJson.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/BlankedJson.o ) [14 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.ToInterestBits64 ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/ToInterestBits64.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/ToInterestBits64.o ) [15 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.ToBalancedParens64 ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/ToBalancedParens64.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/ToBalancedParens64.o ) [16 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.IbBp ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/IbBp.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/IbBp.o ) [17 of 32] Compiling HaskellWorks.Data.Json.Backend.Standard.SemiIndex ( src/HaskellWorks/Data/Json/Backend/Standard/SemiIndex.hs, /root/project /dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Backend/Standard/SemiIndex.o ) [18 of 32] Compiling HaskellWorks.Data.Json.Backend.Simple.SemiIndex ( src/HaskellWorks/Data/Json/Backend/Simple/SemiIndex.hs, /root/project /dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Backend/Simple/SemiIndex.o ) [19 of 32] Compiling HaskellWorks.Data.Json.LightJson ( src/HaskellWorks/Data/Json/LightJson.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/LightJson.o ) [20 of 32] Compiling HaskellWorks.Data.Json.PartialValue ( src/HaskellWorks/Data/Json/PartialValue.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/PartialValue.o ) [21 of 32] Compiling HaskellWorks.Data.Json.Type ( src/HaskellWorks/Data/Json/Type.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Type.o ) [22 of 32] Compiling HaskellWorks.Data.Json.Backend.Standard.Cursor ( src/HaskellWorks/Data/Json/Backend/Standard/Cursor.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Backend/Standard/Cursor.o ) [23 of 32] Compiling HaskellWorks.Data.Json.Cursor ( src/HaskellWorks/Data/Json/Cursor.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Cursor.o ) [24 of 32] Compiling HaskellWorks.Data.Json.Internal.Backend.Standard.Cursor.Token ( src/HaskellWorks/Data/Json/Internal/Backend/Standard/Cursor/Token.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Internal/Backend/Standard/Cursor/Token.o ) [25 of 32] Compiling HaskellWorks.Data.Json.Value ( src/HaskellWorks/Data/Json/Value.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Value.o ) [26 of 32] Compiling HaskellWorks.Data.Json.FromValue ( src/HaskellWorks/Data/Json/FromValue.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/FromValue.o ) [27 of 32] Compiling HaskellWorks.Data.Json.Backend.Standard.LoadCursor ( src/HaskellWorks/Data/Json/Backend/Standard/LoadCursor.hs, /root/project /dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Backend/Standard/LoadCursor.o ) [28 of 32] Compiling HaskellWorks.Data.Json.LoadCursor ( src/HaskellWorks/Data/Json/LoadCursor.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/LoadCursor.o ) [29 of 32] Compiling HaskellWorks.Data.Json.Backend.Standard.Load ( src/HaskellWorks/Data/Json/Backend/Standard/Load.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Backend/Standard/Load.o ) [30 of 32] Compiling HaskellWorks.Data.Json.Load ( src/HaskellWorks/Data/Json/Load.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json/Load.o ) [31 of 32] Compiling HaskellWorks.Data.Json ( src/HaskellWorks/Data/Json.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/HaskellWorks/Data/Json.o ) [32 of 32] Compiling Paths_hw_json ( /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/autogen/Paths_hw_json.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/opt/build/Paths_hw_json.o ) Configuring test suite 'hw-json-test' for hw-json-0.9.0.1.. Configuring benchmark 'bench' for hw-json-0.9.0.1.. Configuring executable 'hw-json' for hw-json-0.9.0.1.. Preprocessing test suite 'hw-json-test' for hw-json-0.9.0.1.. Building test suite 'hw-json-test' for hw-json-0.9.0.1.. Preprocessing executable 'hw-json' for hw-json-0.9.0.1.. Preprocessing benchmark 'bench' for hw-json-0.9.0.1.. Building benchmark 'bench' for hw-json-0.9.0.1.. Building executable 'hw-json' for hw-json-0.9.0.1.. [ 1 of 11] Compiling HaskellWorks.Data.Json.Backend.Standard.Succinct.Cursor.InterestBitsSpec ( test/HaskellWorks/Data/Json/Backend/Standard/Succinct/Cursor/InterestBitsSpec.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/t /hw-json-test/opt/build/hw-json-test/hw-json-test- tmp/HaskellWorks/Data/Json/Backend/Standard/Succinct/Cursor/InterestBitsSpec.o ) [1 of 2] Compiling Main ( bench/Main.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/b/bench/opt/build/bench/bench-tmp/Main.o ) [1 of 7] Compiling App.Commands.Types ( app/App/Commands/Types.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x /hw-json/opt/build/hw-json/hw-json-tmp/App/Commands/Types.o ) [2 of 7] Compiling App.Lens ( app/App/Lens.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x/hw-json/opt/build /hw-json/hw-json-tmp/App/Lens.o ) [3 of 7] Compiling App.Commands.Demo ( app/App/Commands/Demo.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x /hw-json/opt/build/hw-json/hw-json-tmp/App/Commands/Demo.o ) [2 of 2] Compiling Paths_hw_json ( /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/b/bench/opt/build/bench/autogen/Paths_hw_json.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/b/bench/opt/build/bench/bench-tmp/Paths_hw_json.o ) Linking /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/b/bench/opt/build/bench/bench ... [4 of 7] Compiling App.Commands.CreateIndex ( app/App/Commands/CreateIndex.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x/hw-json/opt/build /hw-json/hw-json-tmp/App/Commands/CreateIndex.o ) [5 of 7] Compiling App.Commands ( app/App/Commands.hs, /root/project /dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x/hw- json/opt/build/hw-json/hw-json-tmp/App/Commands.o ) [ 2 of 11] Compiling HaskellWorks.Data.Json.Backend.Standard.Succinct.CursorSpec ( test/HaskellWorks/Data/Json/Backend/Standard/Succinct/CursorSpec.hs, /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/t /hw-json-test/opt/build/hw-json-test/hw-json-test- tmp/HaskellWorks/Data/Json/Backend/Standard/Succinct/CursorSpec.o ) [6 of 7] Compiling Main ( app/Main.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x/hw-json/opt/build /hw-json/hw-json-tmp/Main.o ) [7 of 7] Compiling Paths_hw_json ( /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x/hw-json/opt/build /hw-json/autogen/Paths_hw_json.hs, /root/project/dist- newstyle/build/x86_64-linux/ghc-8.6.2/hw-json-0.9.0.1/x/hw-json/opt/build /hw-json/hw-json-tmp/Paths_hw_json.o ) Linking /root/project/dist-newstyle/build/x86_64-linux/ghc-8.6.2/hw- json-0.9.0.1/x/hw-json/opt/build/hw-json/hw-json ... cabal: Failed to build test:hw-json-test from hw-json-0.9.0.1. The build process was killed (i.e. SIGKILL). The typical reason for this is that there is not enough memory available (e.g. the OS killed a process using lots of memory). Exited with code 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 00:44:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 00:44:23 -0000 Subject: [GHC] #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory In-Reply-To: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> References: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> Message-ID: <062.0a84d5e3dd32e1755620d7798b6fd1c2@haskell.org> #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 newhoggy): For my own purposes, breaking up the module into two smaller modules was sufficient to avoid triggering the problem, but it would be good if the memory usage could be reduced for this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 01:39:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 01:39:00 -0000 Subject: [GHC] #16018: Disabling core optimizations ignores code that would otherwise warn. Message-ID: <044.38c3f570727f8f6ad76c92a141976181@haskell.org> #16018: Disabling core optimizations ignores code that would otherwise warn. -------------------------------------+------------------------------------- Reporter: dmjio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Keywords: core, | Operating System: Unknown/Multiple optimizations, Wall | Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the below code snippet, {{{#!hs module Main where main :: IO () main = putStrLn "hey" data StopLight = Red | Green | Yellow deriving (Show, Eq) data Intersection = Intersection { light :: {-# UNPACK #-} !StopLight } deriving (Show, Eq) }}} The above code will warn with optimizations enabled (`ghc -Wall -O2 Main.hs`), message below: ''' Main.hs:13:5: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘Intersection’ • In the definition of data constructor ‘Intersection’ In the data type declaration for ‘Intersection’ | 13 | = Intersection ''' Without optimizations, no warnings are emitted `ghc -Wall -O0 Main.hs`. The desired behavior should be a warning emitted in both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 01:41:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 01:41:10 -0000 Subject: [GHC] #16018: Disabling core optimizations ignores code that would otherwise warn. In-Reply-To: <044.38c3f570727f8f6ad76c92a141976181@haskell.org> References: <044.38c3f570727f8f6ad76c92a141976181@haskell.org> Message-ID: <059.51f09da233f77631f3367a6485c7db87@haskell.org> #16018: Disabling core optimizations ignores code that would otherwise warn. -------------------------------------+------------------------------------- Reporter: dmjio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: core, | optimizations, Wall Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dmjio): * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 05:45:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 05:45:41 -0000 Subject: [GHC] #16016: Hadrian build fails on FreeBSD In-Reply-To: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> References: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> Message-ID: <061.38e9f56e9386013ef1511ae677f2f6cf@haskell.org> #16016: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Do you remember what GHC commit where you running? I'm debugging some build problems on FreeBSD, but I get much further than this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 09:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 09:37:32 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails Message-ID: <047.60bba0568024ee8f0292c613569e5373@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime | Version: 8.7 System | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Build 64479 https://phabricator.haskell.org/harbormaster/build/64479/ {{{ rts/sm/CNF.c:1002:13: error: 486 error: declaration does not declare anything [-Werror ,-Wmissing-declarations] 487 FALLTHROUGH; 488 ^ 489 | 490 1002 | FALLTHROUGH; 491 | ^ 492 493 includes/Stg.h:201:21: error: 494 note: expanded from macro 'FALLTHROUGH' 495 | 496 201 | #define FALLTHROUGH GNU_ATTRIBUTE(fallthrough) 497 | ^ 498 #define FALLTHROUGH GNU_ATTRIBUTE(fallthrough) 499 ^ 500 501 includes/Stg.h:188:27: error: 502 note: expanded from macro 'GNU_ATTRIBUTE' 503 | 504 188 | #define GNU_ATTRIBUTE(at) __attribute__((at)) 505 | ^ 506 #define GNU_ATTRIBUTE(at) __attribute__((at)) 507 ^ }}} Marking this as highest priority because it is a regression and it breaks CI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 09:53:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 09:53:47 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.be56e7271fae04157bea12a6c650608f@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ThrashAbaddon): * cc: ThrashAbaddon (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 09:56:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 09:56:20 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.ceb7f932197628ebff4e34980f1d252a@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: carlhowells | Owner: qnikst Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ThrashAbaddon): * cc: ThrashAbaddon (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 09:58:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 09:58:54 -0000 Subject: [GHC] #12126: Bad error messages for SPECIALIZE pragmas In-Reply-To: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> References: <046.46f61e5c8784dffd3faa2d7de26366e6@haskell.org> Message-ID: <061.cdb5f4294da5c52ed200cdc5dee4a4cb@haskell.org> #12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: tmcgilchrist Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Specialize, | ErrorMessages, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ThrashAbaddon): * cc: ThrashAbaddon (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 10:25:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 10:25:11 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.972ded92acffb0f70b6b061f0c9fb0ca@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * related: => #14613 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 10:32:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 10:32:55 -0000 Subject: [GHC] #8109: Type family patterns should support as-patterns. In-Reply-To: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> References: <050.c933323dc7b27f878df54b935f73c14c@haskell.org> Message-ID: <065.7df4f11f5a3434267f2cc9884e884c3d@haskell.org> #8109: Type family patterns should support as-patterns. -------------------------------------+------------------------------------- Reporter: carlhowells | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * owner: qnikst => (none) Comment: Seems, I have neither a good understanding on how to implement this ticket, nor enough time to pass through all changes in the parser and further, so if anyone would like to solve this one - feel free to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 13:25:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 13:25:26 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.9a768e1e757eee7d9f79e07ec4214215@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 13:28:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 13:28:47 -0000 Subject: [GHC] #16020: Hadrian: correctly Install libffi shared object files Message-ID: <045.7cb46e35f781e91fb607edbacacf8fcc@haskell.org> #16020: Hadrian: correctly Install libffi shared object files -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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 Phab:D5423 a hack to correctly install the libffi .so files is implemented. This is a quick and dirty solution to fix the hadrian build. Note [Hadrian: install libffi hack] from that patch and also issue #15837 have more details, but ultimately hadrian should not have a special case for libffi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 13:30:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 13:30:53 -0000 Subject: [GHC] #16007: Implement `-Os` In-Reply-To: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> References: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> Message-ID: <059.925e6877cc45144fc1b497fd09a97af5@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16005, #12915, | Differential Rev(s): #14226 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Popular C compilers like GCC or clang allow to optimise for binary size. > > Since there are multiple ways in which GHC trades code size for faster > programs, it might make sense to follow suit. This ticket is for tracking > which optimisations/hacks in the compiler might be affected, as well as > > Feel free to add items to the following list: > > - potentially huge impact due to specialisation, liberate case and > inlining > - +0.1% increase in code size due to known calls instead of re-using > generic apply thunks in #16005 > - -0.1% due to `-fstg-lift-lams` #9476 New description: Popular C compilers like GCC or clang allow to optimise for binary size. Since there are multiple ways in which GHC trades code size for faster programs, it might make sense to follow suit. This ticket is for tracking which optimisations/hacks in the compiler might be affected, as well as Feel free to add items to the following list: - potentially huge impact due to specialisation, liberate case and inlining - potential of -0.9% due to a second run of common block elimination (#14226) - +0.1% increase in code size due to known calls instead of re-using generic apply thunks in #16005 - -0.1% due to `-fstg-lift-lams` #9476 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 13:37:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 13:37:54 -0000 Subject: [GHC] #16021: Hadrian: remove/refactor package specific hacks Message-ID: <045.d647b8c4fa454d862f197abc397a154d@haskell.org> #16021: Hadrian: remove/refactor package specific hacks -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Hadrian implements a number of package specific hacks (e.g. see #16020). Such hacks should be discussed in this ticket and ideally removed or refactored. Hacks: * libffi (#16020) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 13:47:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 13:47:15 -0000 Subject: [GHC] #16020: Hadrian: correctly Install libffi shared object files In-Reply-To: <045.7cb46e35f781e91fb607edbacacf8fcc@haskell.org> References: <045.7cb46e35f781e91fb607edbacacf8fcc@haskell.org> Message-ID: <060.40f9e1f4291c896b1a7f0c612f612010@haskell.org> #16020: Hadrian: correctly Install libffi shared object files -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: high | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 14:34:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 14:34:31 -0000 Subject: [GHC] #2550: Add an option to read file names from a file instead of the command line In-Reply-To: <047.3665f1a48a327f8421f4cc9de980373f@haskell.org> References: <047.3665f1a48a327f8421f4cc9de980373f@haskell.org> Message-ID: <062.4dc8f8202319821ff1ec4c376c498861@haskell.org> #2550: Add an option to read file names from a file instead of the command line -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Package system | Version: 6.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2551 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by f-a): This would of course greatly mitigate the pain of Template Hakell stage restrictions, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 14:46:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 14:46:49 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.a41c7e9f2aba96261efa5185b9a907d2@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: 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): FYI: ckoparkar is also working on this in Phab:D5415. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 15:01:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 15:01:49 -0000 Subject: [GHC] #16022: Hadrian appears to link against libffi unconditionally Message-ID: <046.31572989e9f3296a793745b1dafe131d@haskell.org> #16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Hadrian appears to be linking against `libffi`, even on platforms where it should not be used. I suspect the cause is that Hadrian makes no attempt to set the `ffi` flag when configuring `rts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 15:02:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 15:02:08 -0000 Subject: [GHC] #16022: Hadrian appears to link against libffi unconditionally In-Reply-To: <046.31572989e9f3296a793745b1dafe131d@haskell.org> References: <046.31572989e9f3296a793745b1dafe131d@haskell.org> Message-ID: <061.cf0cdf36b89e3041ea8d9bcddf1b8f05@haskell.org> #16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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: davide, snowleopard (added) * priority: normal => highest * component: Compiler => Build System (Hadrian) * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 15:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 15:07:08 -0000 Subject: [GHC] #16022: Hadrian appears to link against libffi unconditionally In-Reply-To: <046.31572989e9f3296a793745b1dafe131d@haskell.org> References: <046.31572989e9f3296a793745b1dafe131d@haskell.org> Message-ID: <061.47d8aadb15c106bb1bb2aaa75226aed4@haskell.org> #16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5427 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5427 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 15:07:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 15:07:18 -0000 Subject: [GHC] #16022: Hadrian appears to link against libffi unconditionally In-Reply-To: <046.31572989e9f3296a793745b1dafe131d@haskell.org> References: <046.31572989e9f3296a793745b1dafe131d@haskell.org> Message-ID: <061.38e31d108e532e9534f4f1102fefc6e1@haskell.org> #16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5427 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a quick attempt at a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 15:25:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 15:25:34 -0000 Subject: [GHC] #16009: Deprecate `optional` from Text.ParserCombinators.ReadP In-Reply-To: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> References: <047.b8517c9cd85a8ee3e79d051e4b8360a2@haskell.org> Message-ID: <062.5840234dc97c348bf6f68f7fe28ac179@haskell.org> #16009: Deprecate `optional` from Text.ParserCombinators.ReadP -------------------------------------+------------------------------------- Reporter: dbaynard | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.6.2 Resolution: | Keywords: Applicative, | Parsers, ReadP 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 dbaynard): * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 16:00:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 16:00:23 -0000 Subject: [GHC] #16018: Disabling core optimizations ignores code that would otherwise warn. In-Reply-To: <044.38c3f570727f8f6ad76c92a141976181@haskell.org> References: <044.38c3f570727f8f6ad76c92a141976181@haskell.org> Message-ID: <059.13d07273185bb6907a8ecf8610837962@haskell.org> #16018: Disabling core optimizations ignores code that would otherwise warn. -------------------------------------+------------------------------------- Reporter: dmjio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: core, | optimizations, Wall Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Given the below code snippet, > > {{{#!hs > module Main where > > main :: IO () > main = putStrLn "hey" > > data StopLight > = Red > | Green > | Yellow > deriving (Show, Eq) > > data Intersection > = Intersection > { light :: {-# UNPACK #-} !StopLight > } deriving (Show, Eq) > }}} > > The above code will warn with optimizations enabled (`ghc -Wall -O2 > Main.hs`), message below: > ''' > Main.hs:13:5: warning: > • Ignoring unusable UNPACK pragma > on the first argument of ‘Intersection’ > • In the definition of data constructor ‘Intersection’ > In the data type declaration for ‘Intersection’ > | > 13 | = Intersection > ''' > > Without optimizations, no warnings are emitted `ghc -Wall -O0 Main.hs`. > > The desired behavior should be a warning emitted in both cases. New description: Given the below code snippet, {{{#!hs module Main where main :: IO () main = putStrLn "hey" data StopLight = Red | Green | Yellow deriving (Show, Eq) data Intersection = Intersection { light :: {-# UNPACK #-} !StopLight } deriving (Show, Eq) }}} The above code will warn with optimizations enabled (`ghc -Wall -O2 Main.hs`), message below: {{{ Main.hs:13:5: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘Intersection’ • In the definition of data constructor ‘Intersection’ In the data type declaration for ‘Intersection’ | 13 | = Intersection }}} Without optimizations, no warnings are emitted `ghc -Wall -O0 Main.hs`. The desired behavior should be a warning emitted in both cases. -- Comment (by bgamari): I believe this may be similar to #9370. In short, whether we represent field unpackedness (and strictness) in the AST is determined by whether we have compiled with `-O`. More concretely, we drop the unpack pragma in `MkId.dataConSrcToImplBang` in the case of `-O0`. This is really an awful design and should be changed. As described in #9370, we should rather always include these sorts of pragmas in the AST and ignore them in the simplifier if optimisation is disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 16:25:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 16:25:00 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.e211e150ce7f8560a9e30a20c7b97642@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * Attachment "incomplete-record-updates.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 16:25:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 16:25:25 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.a5591b81039247777dcdc86222ac5ebd@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * Attachment "incomplete-uni-patterns.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 16:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 16:26:09 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.2ee6b9c259fb71940ed96d3b9ef9e566@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): RolandSenn, feel free to commandeer that patch. Adding the flags to {{{-Wall}}} was the easy part, and that's done. However, we still need to do something about the code in GHC which is unsafe per these two flags. (Attached the build/error log). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 17:13:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 17:13:23 -0000 Subject: [GHC] #16015: git notes logic breaks CircleCI validation of pull requests In-Reply-To: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> References: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> Message-ID: <061.a289505a54a4f7b135d6e0b4253f70cf@haskell.org> #16015: git notes logic breaks CircleCI validation of pull requests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 davide): @bgamari, when we originally set up CircleCI to push git notes, you had to configure CircleCI with the correct ssh key. It looks to me like this ssh key is not used when CI runs for PRs (hence missing credentials). I don't have access to ghc's CircleCI configuration, so I can only speculate. Perhaps you set up the key to be used only on a specific host and CI for PRs are run on a different host? This also begs the question: do we want to push performance notes for PRs, or only for merged commits (I would guess only merged commits)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 17:21:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 17:21:25 -0000 Subject: [GHC] #16015: git notes logic breaks CircleCI validation of pull requests In-Reply-To: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> References: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> Message-ID: <061.9e706987d6ed002d08343aa8f42fa13f@haskell.org> #16015: git notes logic breaks CircleCI validation of pull requests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 davide): P.S. I've looked at CI runs since ​https://circleci.com/gh/ghc/ghc/12493 and confirmed that PRs all fail to push git notes due to missing credentials. Non-PR triggered CI runs either push the notes successfully, or skip pushing due to [https://github.com/ghc/ghc/commit/0f2ac24c26fb951cc81100085c7773906a241523 #diff-91a1cfa1c62d468507f51bd4ea7e7fcd this change]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 17:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 17:30:56 -0000 Subject: [GHC] #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows Message-ID: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Attempting to bootstrap GHC HEAD with GHC 8.6 on Windows fails shortly after starting the build with {{{ ... Configuring hsc2hs-0.68.4.1... "inplace/bin/ghc-cabal.exe" configure utils/gen-dll dist --with- ghc="/home/ben/ghc-8.6.3-amd64/bin/ghc.exe" --with-ghc- pkg="/home/ben/ghc-8.6.3-amd64/bin/ghc-pkg" --packag e-db=C:/msys64/home/ben/ghc/libraries/bootstrapping.conf --disable- library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-optio n=CFLAGS="-Wall -fno-stack-protector -Wno-error=inline" --configure- option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -W no-error=inline " --constraint "binary == 0.8.6.0" --constraint "text == 1.2.3.1" --constraint "transformers == 0.5.5.0" --constraint "mtl == 2.2.2" --constrain t "parsec == 3.1.13.0" --constraint "Cabal == 2.5.0.0" --constraint "hpc == 0.6.0.3" --constraint "ghc-boot-th == 8.7" --constraint "ghc- boot == 8.7" --constraint "template-haskell == 2.15.0.0" --constraint "ghc-heap == 8.7" --constraint "ghci == 8.7" --with- gcc="C:\\msys64\\home\\ben\\ghc-8.6.3-amd64\\lib\\../mingw/bin/gcc.exe" --with- ld="C:\\msys64\\home\\ben\\ghc-8.6.3-amd64\\lib\\../mingw/bin/ld.exe" --with- ar="C:\\msys64\\home\\ben\\ghc-8.6.3-amd64\\lib\\../mingw/bin/ar.exe" --with-alex="\Use rs\ben\AppData\Roaming/cabal/bin/alex" --with- happy="\Users\ben\AppData\Roaming/cabal/bin/happy" Configuring gen-dll-0.1... ghc-cabal.exe: Encountered missing dependencies: containers ==0.5.* make[1]: *** [utils/gen-dll/ghc.mk:19: utils/gen-dll/dist/package-data.mk] Error 1 make: *** [Makefile:124: all] Error 2 }}} Given that the build succeeds when bootstrapping with GHC 8.4, I suspect that this is a regression in the Cabal released with 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 17:44:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 17:44:54 -0000 Subject: [GHC] #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows In-Reply-To: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> References: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> Message-ID: <061.74df9160cf8eab3f06c42fb32cbd75ae@haskell.org> #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh, never mind. We simply need to bump the bound on `gen-dll`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 18:12:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 18:12:04 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.7d0325968116777dc5e9915f9513b287@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): My own vote is that we drop the saturation requirement only at top-level, calling the current implementation a bug. To my horror, GHC allows this interaction: {{{#!hs type family Map f x where Map _ '[] = '[] Map f (x : xs) = f x : Map f xs data Nat = Zero | Succ Nat type family Pred n where Pred Zero = Zero Pred (Succ n) = n }}} {{{ λ> :kind! Map Pred [Succ (Succ Zero), Succ (Succ (Succ Zero)), Zero] Map Pred [Succ (Succ Zero), Succ (Succ (Succ Zero)), Zero] :: [Nat] = '[ 'Succ 'Zero, 'Succ ('Succ 'Zero), 'Zero] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 18:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 18:20:16 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.79657c391ede69973613514dea3318e9@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 goldfire): `forall (f :: Type -> Type). f` is bogus. It should be rejected both by the type checker and Core Lint. This is rather awkward w.r.t. type inference (as Simon points out) because of `Constraint`. I don't like the validity-checking solution, because then we reject something like `:k forall a. a` in GHCi. `a`'s kind will be unconstrained, so it will get kind `k`. But then the `forall` is bogus. We could imagine a magic class `TypeLike` with `instance TypeLike (TYPE r)` and `instance TypeLike Constraint`. We can further imagine defaulting this class (not unlike how we default `Num`). But this is a sledgehammer of a solution, to be sure. I don't think there is anything unsound about removing the restriction... but no published type theory (to my knowledge) does so. Back in the day, the restriction wasn't there because we needed, e.g., `forall a. Array# a` -- that is, we needed unlifted types (which didn't really have kinds) in `forall`s. Now with levity polymorphism, we have a more principled way of dealing with this all, and so we do. Perhaps the new principles weren't carried all the way to their logical conclusion, though, as this ticket shows. Note: if we really can't come up with a good way to impose this restriction in the type-checker, I wouldn't be strongly opposed to just dropping it. It's just a little smelly, but no worse than that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 19:49:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 19:49:45 -0000 Subject: [GHC] #13637: Printing type operators adds extraneous parenthesis In-Reply-To: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> References: <046.6ebd1e08796fca2595c91164229af3b2@haskell.org> Message-ID: <061.003bdee23293d0457d7de354aeb2812b@haskell.org> #13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I agree that this ticket's bug should be fixed. The {{{We don't keep the fixity of type operators in the operator}}} quoted in comment:3 above is the root problem, if I understand correctly. I'm writing a plugin for type-level sets, and the extra parentheses makes the syntax much more difficult to read than it should be. {{{((('Empty :* a) :* b) :* c)}}} is worse than {{{'Empty :* a :* b :* c}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 20:41:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 20:41:41 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.d1139459448e5a0031154db59010ab62@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: RolandSenn => (none) Comment: @ckoparkar, @RyanGlScott: Ops, this ticket contains more fun than I expected! Most of these ''incomplete patterns'' are already a very long time in the GHC and libraray code, so we can assume, they are nearly never a problem. The new warnings do not make the code safer or more unsafe. GHC now just reminds us, that there is unsafe code. To fix, we have 3 possibilities: 1. Add a pragma to skip the warning to every affected module. This has the advantage, that we don't change the semantics of any GHC or library module. 2. Add the missing patterns, and call panic! This has the advantage, that if we really ever hit such a case, the user gets a nicer error message, and is invited to report the problem. 3. Add the missing patterns and add (maybe) intelligent code to the RHS of the pattern. This has the **disadvantage**, that we add a lot of code. Unfortunately will be unable to test this new code. This is very bad! I think, we should concentrate on option 1 or 2. The difference in the amount of work is marginal, however, I don't really know, which one is ''the GHC way'' to solve this issue. Ryan (and others!) please advice! Both solutions (1 and 2) are not difficult but a fair amount of work. We should only do it, if we know, that the solution will be accepted by code review. In addition we have to decide, who does the work: I don't mind to do everything, or just a part (libraries or GHC) or nothing. **The decisions are up to you! ** PS: Till now I never did something in the libraries, so I'll probably need some guidance, eg how and where to specify the bumped version numbers of the modified libraries. PSS: Thanks to ckoparkar for the two attachments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 21:38:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 21:38:23 -0000 Subject: [GHC] #12893: Profiling defeats stream fusion when using vector library In-Reply-To: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> References: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> Message-ID: <062.393e4bc1ba11ec32df9276f577f17949@haskell.org> #12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: stream-fusion | profiling Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf, simonpj (added) Comment: Replying to [comment:4 guaraqe]: > I think the problem that the OP is reporting is that there are no cost centers in the program, yet no optimization is done. There are no manual `SCC`s and compilation is done with `-fno-prof-count-entries -fno-prof- cafs -fno-prof-auto -O2`, so we would expect that there would be no barriers for optimization. > > This can be wrong if for some reason the GHC flags are not passed to the `vector` library, and it is still being compiled with automatic cost centers, which would indeed block fusion. If that is the case, it would be nice to have a way to pass these flags all the way down. Indeed passing `-prof` will use profiling versions of libraries. So functions in `vector` will still contribute their cost-centres. I did some digging. It seems that with profiled `vector` libraries, small functions like [https://github.com/haskell/vector/blob/cc06420eaa597b85ffd8ded9f82aac1a3fc02c18/Data/Vector/Internal/Check.hs#L53 doBoundsCheck] or the specialised call to `pure @Id` (from `Data.Vector.Fusion.Util`) are no longer inlined. Especially the fact that `pure @Id` is no longer inlined means that SpecConstr is having a hard time extending the call pattern for the crucial `Step` parameter through the `Id` constructor in calls like this: {{{ jump $j_s8PT ((Data.Vector.Fusion.Util.$fMonadId1 @ (Data.Vector.Fusion.Stream.Monadic.Step Double Double) (Data.Vector.Fusion.Stream.Monadic.Yield @ Double @ Double (GHC.Types.D# sc_s8Ur) (GHC.Types.D# (GHC.Prim.+## sc_s8Ur 1.0##)))) }}} Note that `$fMonadId = pure @Id`. If `$fMonadId` was inlined, SpecConstr could probably see through the SCC and extend the call pattern to `Yield`. I'm not sure which part of the simplifier or whatever is responsible for refusing to inline `$fMonadId`, it's unfolding in the interface file is basically {{{ \ @ a -> {__scc {Data.Vector.Fusion.Util.pure} True False} \ (v :: a) -> v }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 9 21:47:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Dec 2018 21:47:37 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.10c7d817d67d636259c731b0e2a4cd58@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: michalt Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754, | Differential Rev(s): Phab:D3973, #14989 | Phab:D3999 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Note that I posted a solution in https://ghc.haskell.org/trac/ghc/ticket/14989#comment:2: Just recompute proc points after the transformation. There's no reason we couldn't have this now other than that it will probably eat more CPU time than the quick (but broken) fixup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 01:09:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 01:09:47 -0000 Subject: [GHC] #16024: Kind Signatures on data instances Message-ID: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> #16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- There's a comment in `compiler/typecheck/TcInstDcls.hs` that reads: > The "header" is the part other than the data constructors themselves > e.g. `data instance D [a] :: * -> * = ...` > Here the "header" is the bit before the "=" sign What's weird is that you cannot actually compile code that this example suggests is valid. Consider this: {{{ {-# language TypeFamilies #-} module BadSig where data family Bar a :: * data instance Bar Int :: * = Bool }}} It fails on GHC 8.6.2 with: {{{ bad_sig.hs:6:28: error: parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' | 6 | data instance Bar Int :: * = Bool | ^ }}} Oddly, GHC will accept the instance if the body is missing: {{{ {-# language TypeFamilies #-} module BadSig where data family Bar a :: * data instance Bar Int :: * }}} It is not clear to me whether or not this one should be accepted, but that is beside the point. The first example should certainly be accepted. It should also be accepted with `TYPE 'LiftedRep` instead of `*`, but it fails with the same parser error when given that kind signature as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 01:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 01:16:11 -0000 Subject: [GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler. Message-ID: <052.9187b36966727d1f3848569f633777f2@haskell.org> #16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (make) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to build a cross-compiler with GHC 8.6.3, I ran into the following: {{{ ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) libraries/ghc-prim/dist-install/build/GHC/CString.o: error adding symbols: File in wrong format echo libraries/ghc-prim/dist-install/build/GHC/CString.o libraries/ghc- prim/dist-install/build/GHC/Classes.o libraries/ghc-prim/dist- install/build/GHC/Debug.o libraries/ghc-prim/dist- install/build/GHC/IntWord64.o libraries/ghc-prim/dist- install/build/GHC/Magic.o libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o libraries/ghc-prim/dist- install/build/GHC/Tuple.o libraries/ghc-prim/dist- install/build/GHC/Types.o libraries/ghc-prim/dist- install/build/cbits/atomic.o libraries/ghc-prim/dist- install/build/cbits/bswap.o libraries/ghc-prim/dist- install/build/cbits/clz.o libraries/ghc-prim/dist- install/build/cbits/ctz.o libraries/ghc-prim/dist- install/build/cbits/debug.o libraries/ghc-prim/dist- install/build/cbits/longlong.o libraries/ghc-prim/dist- install/build/cbits/pdep.o libraries/ghc-prim/dist- install/build/cbits/pext.o libraries/ghc-prim/dist- install/build/cbits/popcnt.o libraries/ghc-prim/dist- install/build/cbits/word2float.o >> libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.3.a.contents libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/HSghc-prim-0.5.3.o' failed make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o] Error 1 make[1]: *** Waiting for unfinished jobs.... "arm-linux-gnueabihf-ar" q libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.3.a @libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3.a.contents arm-linux-gnueabihf-ar: creating libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.3.a "rm" -f libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3.a.contents Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 It seems that this was due to an error in mk/config.mk, viz. LD_NO_GOLD = ld LD = arm-linux-gnueabihf-ld.gold NM = arm-linux-gnueabihf-nm AR = arm-linux-gnueabihf-ar OBJDUMP = arm-linux-gnueabihf-objdump }}} The variable {{{LD_NO_GOLD}}} should have the prefix {{{arm-linux- gnueabihf}}}. When I set {{{LD_NO_GOLD}}} to {{{arm-linux-gnueabihf-ld}}} manually, the build proceeds and works correctly. Let me know if you need any additional information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 01:35:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 01:35:29 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite Message-ID: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 01:35:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 01:35:40 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.29528f3aaed3200a27a5c7e4f3896276@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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: alpmestan, snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 03:25:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 03:25:41 -0000 Subject: [GHC] #16024: Kind Signatures on data instances In-Reply-To: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> References: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> Message-ID: <064.cd3fefb6a890b031be0eadb04a011217@haskell.org> #16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 goldfire): This has nothing to do with data instances. Datatype declarations that use `=` cannot also have a kind signature; only GADT-syntax declarations can have a kind signature. An empty datatype is considered to be in GADT syntax. So the bug here essentially just a thinko in that comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 03:27:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 03:27:16 -0000 Subject: [GHC] #16024: Kind Signatures on data instances In-Reply-To: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> References: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> Message-ID: <064.61f0d958e54ced51c077e0f632a46994@haskell.org> #16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Richard Eisenberg ): In [changeset:"4773b4308203a7f9d50a26831ccf56d8afe3c5e5/ghc" 4773b43/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4773b4308203a7f9d50a26831ccf56d8afe3c5e5" Fix minor mistake in comment about data decls. Fixes #16024. [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 03:28:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 03:28:10 -0000 Subject: [GHC] #16024: Kind Signatures on data instances In-Reply-To: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> References: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> Message-ID: <064.6b9cfd8210c569a0d60266cd377067ff@haskell.org> #16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 goldfire): * status: new => closed * resolution: => fixed Comment: Another one bites the dust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 04:16:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 04:16:14 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.d5ec8194674b84fb74642db3c42e894d@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: 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): Option (2) seems like the obvious choice (at first) -- but then we realize that doing it means that we have to really change a lot of syntax! In particular, incomplete record updates cannot be cleanly refactored. We also have another option: 4. Refine GHC's types so that these warnings go away. For example, if we have {{{#!hs data T = MkT1 { foo :: Int } | MkT2 { bar :: Bool } }}} and have `t { foo = 5 }` somewhere, we'll get an error. But perhaps there is enough logic to suggest that `t` will always be a `MkT1`. We could refactor to {{{#!hs data T = MkT1 T1 | MkT2 T2 data T1 = Mk1 { foo :: Int } data T2 = Mk2 { bar :: Bool } }}} and then our variable `t` would have type `T1` instead of `T` and all would be well. Of course, this refactoring introduces new memory allocations at runtime, and it may be hard to make all the types work out. It's thus impractical. However, it suggests a way forward here: Do (1), but make (4) the end goal. That is, just squash the warnings for now, but have it be an explicit goal (with a ticket to track the goal) to remove the squashings. This would mean, e.g., that we would need a way for the refactoring above ''not'' to take extra allocations at runtime. (This would be a huge improvement for Haskell overall!) And we'd likely need dependent types :). But all this would be very nice concrete fodder for why such improvements are called for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 04:29:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 04:29:06 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell In-Reply-To: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> References: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> Message-ID: <064.b9c2cded0ddd625a4fbef6c5646d89ce@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5360 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I know it's "too late", but this strikes me as something that should get more visibility. With the feature requested here, it is now possible to compile a module with `{-# LANGUAGE Safe #-}` in it but that uses `unsafeCoerce`. The fact that this happens might be buried in a `.cabal` file or even more obfuscated. While I certainly recognize why Matt wanted this, and I see no reasonable alternative, I do think that this begs the larger question of what guarantees we can expect from a module with `{-# LANGUAGE Safe #-}` in it. I think the best course would be to make a post-hoc ghc-proposal to seek community input on the design here. I don't advocate reverting the patch -- I see how you can be quite blocked without this -- but I still want to have a larger conversation about the design goals here. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 05:34:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 05:34:47 -0000 Subject: [GHC] #16027: Cannot use DefaultSignatures for TypeFamiles Message-ID: <050.c69f3341bbdc58bd8bae1da234037179@haskell.org> #16027: Cannot use DefaultSignatures for TypeFamiles -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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'm surprised there wasn't a ticket for this. Maybe I just couldn't find it. In short, I want to do something like: {{{ class Monad m => MyMonad m where type AssociatedMonad m :: Type -> Type default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type type AssociatedMonad (t m') = t (AssociatedMonad m') fun :: Foo -> m () default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m () fun = lift . fun }}} The syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out. The use-case, like the normal method original, is to assist with monad transformer boilerplate. {{{MonadTrans}}} wouldn't be enough, but {{{MFunctor}}} from mmorph might be depending on the method using the associated type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 06:33:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 06:33:30 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.7bd0c9e3221a753fa7380307ff9044b4@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > Possible this can be refined to "-fno-code is relevant only when -fno- omit-iface-pragmas". I'm confused about this line. We currently don't have `-fno-omit-iface- pragmas`. Are you suggesting implementing a new flag for something and only adding that to the fingerprint? (instead of `-fno-code`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 07:32:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 07:32:08 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.88b9284737e8bd99ebdd246103defd3d@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Indeed, at the moment we support specifying a test with `--only`, and this feature is probably getting closer and closer to the top of our priority queue, with the work we've all been doing lately. I may take a stab at implementing this. Do we want to keep specifying all the tests through an env var? A CLI argument? Both? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 07:32:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 07:32:43 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.9c521eb61ceb97440f265be9b47e0641@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #15404 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): GHC 8.6.3 fixes this issue. Thank you, Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 07:55:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 07:55:39 -0000 Subject: [GHC] #16016: Hadrian build fails on FreeBSD In-Reply-To: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> References: <046.c890c9664b891859303a0904aa6fbdf2@haskell.org> Message-ID: <061.c85c40c17a7ba2a8bdc606e5ccbd209a@haskell.org> #16016: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15860 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * related: => #15860 Comment: raichoo has mentionned (and fixed) some issue he encountered while building GHC with Hadrian on FreeBSD, see [https://ghc.haskell.org/trac/ghc/ticket/15860 #15860]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 08:03:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 08:03:08 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.6554a7e81b1b551099f3c69ac906a1d0@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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): Sorry, the flag is `-fno-omit-interface-pragmas`. Does it make sense now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 08:04:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 08:04:55 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.87dca2b99899002b0ba47f88dff0831a@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412, Wiki Page: | Phab:D5422 -------------------------------------+------------------------------------- Comment (by alpmestan): Both D5412 and D5422 have landed on master. When I now resume builds that I stopped while building base (`_build/stage1/libraries/base/*`), hadrian gets back to work pretty quickly on my machine, never above 5 seconds for sure, and it seems to me it's back on track within 2-3 seconds in general now. Is this acceptable? Can we consider this problem solved and close the ticket? (We might want to get rid of the only big rule enumeration we have left -- the ones for generated files, `Rules.Generate` -- but I'd say it's not worth the trouble right now. The impact would quite likely be minor, while requiring some non trivial effort.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 08:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 08:07:21 -0000 Subject: [GHC] #16022: Hadrian appears to link against libffi unconditionally In-Reply-To: <046.31572989e9f3296a793745b1dafe131d@haskell.org> References: <046.31572989e9f3296a793745b1dafe131d@haskell.org> Message-ID: <061.b71a0fdb248dc046e57ca7a1e4ed2978@haskell.org> #16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5427 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 08:18:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 08:18:43 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.512a6c4c2f9cfbfc9be75f5bfd2321cd@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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): Phab:D5394 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Oh, did this miss the 8.6.3 cutoff? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 08:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 08:41:56 -0000 Subject: [GHC] #16007: Implement `-Os` In-Reply-To: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> References: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> Message-ID: <059.025127f922f332b98d12beeeb6ce6b3a@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16005, #12915, | Differential Rev(s): #14226 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 09:00:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 09:00:29 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.1d14a53626c07899bcf897abb8596006@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 09:03:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 09:03:53 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.aebf0de7a15bc8003e4e5a8e829169f9@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * cc: RolandSenn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 09:20:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 09:20:07 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.033c337344b36b38b0b6ecd63aac880b@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): What does that flag do? I think it's not documented (I checked the man page and user manual). Looking at the code, it seems like it doesn't write pragmas to the interface file (and ignores any pragmas that may make a different in the interface file, e.g. RULEs and UNPACK pragmas). I don't see how it's relevant to `-fno-code` though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 09:30:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 09:30:45 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.3047479f37cc237884a1ec7e201da503@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I found the problem with dynamic interface files that I mention in comment:31. Normally when I run these: {{{ $ ghc-stage1 --show-iface libraries/ghc-prim/dist- install/build/GHC/Types.hi $ ghc-stage1 --show-iface libraries/ghc-prim/dist- install/build/GHC/Types.dyn_hi }}} The first command should show `Wanted: [] Got: []` in `Ways` section, the second should show `Wanted: [] Got: [dyn]`, but with my code both show `Got [dyn]`. So it seems like I'm generating a dyn iface file instead of a normal iface file. This seems to be related with how the `-dynamic-too` flag is implemented (it runs the pipeline multiple times, but I think the repeated parts of the pipeline does not include the code generator). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 09:50:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 09:50:34 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.3392a90936b8dad429182f19a5bccdb9@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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): @osa1 sorry I assumed too much background knowledge here. Let me fill in the blanks: `-fomit-interface-pragmas` is on by default with `-O0`, but off with `-O` and above. It is the flag that controls whether we emit optimisation info, including things like unfoldings, strictness signatures, arity, and CAF info into the interface file. When the flag is on, we only emit types and nothing else. It normally isn't used explicitly on the command line. Perhaps it should be documented, I'm not sure what our policy on documenting "internal" flags like this is currently. The relevance to `-fno-code` is this: * we were considering whether `-fno-code` affects the ABI or not, because if it affects the ABI, then it needs to be included in the flags we fingerprint in `FlagChecher` * Prior to your changes here, `-fno-code` does not affect the ABI, but now it does, because the CAF info may change if we use `-fno-code`. * But, this only applies if `-fomit-interface-pragmas` is off (which is also included in `FlagChecker` right now). * So, we must now include `-fno-code` in `FlagChecker` Make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 10:30:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 10:30:25 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.cb56794db25a70e0142d2dda49652e30@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5412, Wiki Page: | Phab:D5422 -------------------------------------+------------------------------------- Comment (by snowleopard): Many thanks, Alp! I agree that rewriting `Rules.Generate` is most likely unnecessary. I think the worst-case startup time of 5 seconds is acceptable, although we might come back to optimising Hadrian further at some point. This probably deserves a separate, lower priority ticket. @bgamari: Could you check Alp's results on your setup? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 10:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 10:39:48 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.e05e784ebfe7c4ba5ea808bf818c0c00@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Another option would be to provide a setting in `UserSettings` as part of the user build flavour, which would be a bit more uniform (all settings in one place), but perhaps less convenient for users (since this requires recompilation of Hadrian). To me, having many different ways of providing settings to Hadrian (CLI, `UserSettings`, environment variables, something else?) is confusing, but perhaps this is perfectly normal/expected for GHC developers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 11:22:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 11:22:20 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.50a0cc27ae4550d37efcb94641a8b865@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Aha, found the problem. We run the code generator twice with `-dynamic- too`, but normally we write the interface files only once (`hscWriteIface` generates two interfaces, a `.hi` and a `.dyn-hi`). Now if I call `hscWriteIface` again after STG generation I end up calling `hscWriteIface` two more times, one for the normal compilation and one for `-dynamic-too`. The first call correctly updates both interface files, then before the second call we update the `DynFlags` to add `WayDyn` way and remove `Opt_BuildDynamicToo` (in `dynamicTooMkDynamicDynFlags`), so the second call to `hscWriteIface` updates the normal iface file (not the dyn iface), but updates it with `WayDyn`. Correct behavior: in the first codegen we should only update the normal iface file, in the second only the dyn iface file. Not sure how to implement this yet. (I'll look at comment:39 later) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 11:33:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 11:33:24 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.65af78fbc6be65b3484988fe3d686619@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I'm afraid we want the "list of tests to run" to be supplied at runtime, as rebuilding hadrian whenever I want to look at, say, only a subset of those 10 tests that I was running before, would be a bit annoying. The way I see it, `UserSettings` are useful when you want to do things that you'd usually do in `build.mk`, i.e add some extra options for GHC or the C compiler here and there, things like that. It's not something you'll be editing a lot while working on a particular patch, probably more of a "edit once at the beginning and not much afterwards" kind of workflow. While names of tests to run can definitely change from a minute to the next, when you're looking into group of failing tests "per theme" for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 11:46:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 11:46:57 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.0e9550dfa7e623ee8ca4b50bbac44d4a@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I see. I guess keeping all test numbers in the command line `--only="t123 t456 t789"` will also get tedious? If yes, then going via environment variables seems to be the only remaining alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 11:47:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 11:47:33 -0000 Subject: [GHC] #16027: Cannot use DefaultSignatures for TypeFamiles In-Reply-To: <050.c69f3341bbdc58bd8bae1da234037179@haskell.org> References: <050.c69f3341bbdc58bd8bae1da234037179@haskell.org> Message-ID: <065.6641544d661a8c21b8893a9db1f3077f@haskell.org> #16027: Cannot use DefaultSignatures for TypeFamiles -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): Until constrained type families are implemented (which likely won't be for a good while), you can do this: {{{#!hs class Monad m => MyMonad m where type AssociatedMonad m :: Type -> Type type AssociatedMonad m = DefaultAssociatedMonad m fun :: Foo -> m () default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m () fun = lift . fun type family DefaultAssociatedMonad (m :: Type -> Type) :: Type -> Type where DefaultAssociatedMonad (t m') = t (AssociatedMonad m') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 12:22:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 12:22:25 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.d528150dd07f5fca50d7e1238dfb727f@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Yay, it validates! Will do some more refactoring and submit a diff soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 12:24:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 12:24:35 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.b11ad65e25bec5d225acd0fa8a85aa2c@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Well, it's not much different from `make TEST="t123 t456 t789"`, is it? We can support both quite easily, really. The important thing is that you have a quick way to take the testsuite output that lists the failing tests and ask hadrian to run just those, or a only subset. We might have to do something about the `TEST` environment variable to make sure that it makes it through the `build.*` scripts, to the hadrian executable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 14:14:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 14:14:49 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.d9c3964311fa81d3737e4661410bea13@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Linking) | 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 AndreasK): The code causing the failure is at rts/linker/PEi386.c:1960 where the overflow check is not correctly implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 14:19:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 14:19:37 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.37438619e247d2b7bcd844b67e925f29@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Linking) | 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 AndreasK): There is some overflow checking code at https://github.com/eth- sri/ELINA/blob/61c24b4b6309745c222699b6998ad943d8de5624/elina_poly/opt_pk_vector.c#L504 which we could steal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 14:21:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 14:21:25 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.c5f54074af52b5e43d469ff8563b6836@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 14:37:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 14:37:41 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.11a341fb90dad00ec461921b4c14d50a@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Just happened to come across this. As an avid user of the feature you're describing, I would want a way to do this on the command line. Other options are good, too (e.g. setting an env var so that way I can run the same tests over and over), but inessential (for me). Separate from the `make TEST=...` functionality, I also make regular use of the fact that running `make` in different subdirectories of `tests` runs only subsets. For example, I'll go into `testsuite/tests/typecheck` and run `make` just to run type-checking tests. Sometimes I even just want the `should_fail` directory of that. I would certainly miss the ability to run subsets like this if it were gone. It's so easy (just change dirs) and so useful. Thanks for all the work you're putting into this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 15:49:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 15:49:37 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.4edae665b397eed0a9659e646293580b@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I started working on a patch to support running a given bunch of tests as described above. The cwd-sensitivity has been requested by simonmar too, so I'll look into how to best make that happen soon as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 15:52:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 15:52:06 -0000 Subject: [GHC] #16024: Kind Signatures on data instances In-Reply-To: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> References: <049.97b9b1919a9a22938c483a92b4224782@haskell.org> Message-ID: <064.957f8ef7d37817428dcb9c93aa033fe8@haskell.org> #16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Comment (by andrewthad): Thanks! This makes sense now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 16:25:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 16:25:53 -0000 Subject: [GHC] #16028: tyThingCoAxiom panics while building Agda Message-ID: <047.23f2ee5afbe868e490db42ef500482ef@haskell.org> #16028: tyThingCoAxiom panics while building Agda -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0): {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for arm-unknown-linux): tyThingCoAxiom Identifier ‘fromDescListWithKey’ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/main/HscTypes.hs:2153:32 in ghc:HscTypes Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The same version of Agda builds fine with ghc-8.4.3 on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3&stamp=1540145469&raw=0). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 16:52:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 16:52:07 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.1f48b1a03965cd5ab1bb527ea6f12fd0@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 goldfire): I agree we may not need `substTy` to be monadic. But if we don't make it monadic, it should panic if it ever spots a `TcTyVar`. The problem with making `typeKind` respect the `Type`/`Constraint` distinction is that it means everyone pays the price. Specifically, `typeKind (FunTy {}) = liftedTypeKind` is just fine right now, but if we want to get `typeKind` correct w.r.t. `Constraint`, then this case will have to recur (because of quantified constraints). I agree that doing this wouldn't cause misbehavior, but it would potentially slow, e.g., core passes down. > We probably want to keep the pure version for occasions where we know the types are zonked. True, but only for syntactic convenience, right? The monadic version should be no less efficient than the pure one, if there are no metavars, I would think. I agree about the idea about the visibility stuff. It might be worthwhile, for performance reasons, to make the decision about visibility once, at the top of `tcEqType`, and then have two mostly-identical recursive functions, one which accounts for visibility and one that doesn't. The alternative is to consult the flag many times during the recursive processing, which seems wasteful. If `tc_eq_type` really is only ever called with `tcView`, then yes, specialize. Does that get you unblocked? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 17:08:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 17:08:30 -0000 Subject: [GHC] #15795: Core lint error with visible kind patterns In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.3d1d6f4a43ebdaae8f8518d389787b83@haskell.org> #15795: Core lint error with visible kind patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeApplications => TypeInType * cc: mnguyen (removed) Comment: This has nothing to do with visible kind application. This fails the same way: {{{#!hs data (×) :: forall (cat1 :: Cat ob1) (cat2 :: Cat ob2). Cat (ob1, ob2) where Prod :: forall ob1 ob2 cat1 cat2 a1 b1 a2 b2 u. cat1 a1 b1 -> cat2 a2 b2 -> (×) '((a1 :: u), a2) '(b1, b2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 17:45:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 17:45:49 -0000 Subject: [GHC] #16029: Inadequate absence analysis Message-ID: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> #16029: Inadequate absence analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider {{{ data S = MkS Int Int g1 :: S -> Int -> Int g1 (MkS x y) 0 = 0 g1 (MkS x y) n = g1 (MkS y x) (n-1) }}} With GHC 8.6 we get {{{ $wg1 :: S -> GHC.Prim.Int# -> GHC.Prim.Int# [Str=] $wg1 = \ (w_s2oH :: S) (ww_s2oL :: GHC.Prim.Int#) -> case w_s2oH of { MkS x_s2pz y_s2pA -> case ww_s2oL of ds_X2nb { __DEFAULT -> Foo.$wg1 (Foo.MkS y_s2pA x_s2pz) (GHC.Prim.-# ds_X2nb 1#); 0# -> 0# }} g1 :: S -> Int -> Int [Str=m] g1 = \ (w_s2oH :: S) (w1_s2oI :: Int) -> case w_s2oH of w2_X2pG { MkS ipv_s2p2 ipv1_s2p3 -> case w1_s2oI of { GHC.Types.I# ww1_s2oL -> case Foo.$wg1 w2_X2pG ww1_s2oL of ww2_s2oP { __DEFAULT -> GHC.Types.I# ww2_s2oP }}} }}} What terrible code! We evaluate the S argument in the wrapper, and box and unbox it every time around the loop, even though it is never ultimately used. Here's what happens if the arguments are banged: {{{ data T = MkT !Int !Int g2 :: T -> Int -> Int g2 (MkT x y) 0 = 0 g2 (MkT x y) n = g2 (MkT y x) (n-1) }}} We get {{{ $wg2 GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [Str=] Foo.$wg2 = \ (ww_s2ow :: GHC.Prim.Int#) (ww1_s2ox :: GHC.Prim.Int#) (ww2_s2oB :: GHC.Prim.Int#) -> case ww2_s2oB of ds_X2n0 { __DEFAULT -> Foo.$wg2 ww1_s2ox ww_s2ow (GHC.Prim.-# ds_X2n0 1#); 0# -> 0# } g2 :: T -> Int -> Int [Str=m ] g2 = \ (w_s2os :: T) (w1_s2ot :: Int) -> case w_s2os of { MkT ww1_s2ow ww2_s2ox -> case w1_s2ot of { GHC.Types.I# ww4_s2oB -> case Foo.$wg2 ww1_s2ow ww2_s2ox ww4_s2oB of ww5_s2oF { __DEFAULT -> GHC.Types.I# ww5_s2oF }}} }}} Still terrible. We pass the two components around the loop before discarding them at the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 18:27:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 18:27:25 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.5552c70d8260e5d7b75e2e2a45d86b2d@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): This is due to 6bb8aaa3b4fcebf8f0de2f81f00dcc20b857c4f5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 18:30:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 18:30:53 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.b58ecc3d724573fb398460e3f6bdea51@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => Phab:D5431 Comment: Got a patch ([https://phabricator.haskell.org/D5431 D5431]) that makes hadrian support `TEST="..." hadrian/build.sh test` and/or `hadrian/build.sh test --only="..."`. Both can be used at the same time and hadrian will happily concatenate both lists of tests and run them all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 18:34:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 18:34:45 -0000 Subject: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust In-Reply-To: <045.e33af6968458760182e141457b350018@haskell.org> References: <045.e33af6968458760182e141457b350018@haskell.org> Message-ID: <060.54958ff49cccd1a6e34a17e76ed27f46@haskell.org> #4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.12.2 Resolution: duplicate | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate * related: => #9718 Comment: Duplicate of #9718. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 18:35:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 18:35:55 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.1e1ff63b914acdd4e0f5274e6c7dc0d6@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5432 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D5432 Comment: Not quite ready but submitted the patch to get comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 19:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 19:17:03 -0000 Subject: [GHC] #15795: Core lint error with visible kind patterns In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.098b6f8b3662c43e5c27f54a0bc125d1@haskell.org> #15795: Core lint error with visible kind patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Smaller version: {{{ #!haskell {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} module DF where import Data.Kind data F :: forall (cat1 :: ob1). ob1 -> Type where Prod :: F (a :: u) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 19:27:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 19:27:16 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names In-Reply-To: <046.a0cda9df357797abce34c12980353145@haskell.org> References: <046.a0cda9df357797abce34c12980353145@haskell.org> Message-ID: <061.47fb2d80befbfaadd0e99e9d04a1ddeb@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 19:39:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 19:39:34 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.a8f586c10e3599e7a185ca921d2f8734@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I know Simon strongly disliked that `Maybe (VarEnv Kind)` getting too far from TcTyClsDecls. Could you just add a call to `addConsistencyConstraints` to `tc_lhs`? I also think that the new `checkExpectedKind` from Phab:D5229 will fix this handily. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 19:52:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 19:52:31 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind (was: Core lint error with visible kind patterns) In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.56cbb99026f7d056a6400444d160e77a@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, monoidal! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 21:05:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 21:05:20 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.5099a4f728662eda9f0894006f48a986@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5435 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5435 Comment: Oh wow, I was not aware of `checkConsistencyConstraints`! That's a much cleaner solution, and better yet, it doesn't cause any existing tests to change their expected output. I've submitted a patch as Phab:D5435. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 21:07:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 21:07:34 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names In-Reply-To: <046.a0cda9df357797abce34c12980353145@haskell.org> References: <046.a0cda9df357797abce34c12980353145@haskell.org> Message-ID: <061.f3b852a3483d98641d7aec6f9c03ad58@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => Phab:D5434 Comment: I have a patch at [https://phabricator.haskell.org/D5434 D5434], adding those `stage::` targets. It seems to be working as expected and advertised in the patch description. Feedback/review/refinements welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 10 22:14:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Dec 2018 22:14:10 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.2cf664bf2db151fe3ca638e0bde77f36@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): yup, i thought i had tested this properly on my side, but i guess not :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 02:50:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 02:50:39 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.77bd4a8adfdb1387a34f279c73a3e5d7@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Phab:D5436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5436 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 03:12:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 03:12:13 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.c2b4b52a69754aafe68cfe0ed2ddef72@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * cc: ulysses4ever (added) Comment: I've been thinking about this one lately. For the sake of experiment, I tried to replace the implementation of a hand-crafted Binary instance (namely, the one for `ArgType`) with the implementation derived by Data.Binary via GHC.Generics. This alone immediately led GHC into panic (see below). [https://gitlab.staging.haskell.org/ulysses4ever/ghc/commit/6156a260cd775a1d780d3c9f3c4cef8fb39d0f19 The patch is here]. Maybe my new instance has some flaw? Can anyone comment on any of these? {{{ $ 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 ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -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 Cabal-2.5.0.0 -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id ghc-8.7 -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 ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181207 for x86_64-unknown-linux): Binary(IfaceConDecls).get: Invalid IfaceConDecls CallStack (from HasCallStack): error, called at compiler/iface/IfaceSyn.hs:1896:18 in ghc:IfaceSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug utils/ghctags/ghc.mk:18: recipe for target 'utils/ghctags/dist- install/build/Main.dyn_o' failed make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 06:54:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 06:54:41 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.0f05ca913e119e4bd33313c5f65ad42d@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I now believe my work-in-progress plugin could be simpler, if a few parts of the plugin API changed. One of those is if the fsks and fmvs were both left in place in both Givens and in Wanteds; no extra unflattening before invoking plugins. I have a related request: directly provide the list of all in-scope variables bound by the enclosing and current implications. This would include the flattening variables with their definitions (preferably in a topological order), instead of having to partition their defining constraints from the passed in {{{Ct}}}s. In particular, it's awkward that some fsks are defined as an alias of another by a {{{CTyEqCan}}}, not by a {{{CFunEq}}} -- there is no {{{CFunEq}}} for such fsks, just the {{{CTyEqCan}}}. I'm not sure when this happens, but I'm definitely seeing it in GHC 8.6.2. That list would also include skolem binders pretty easily -- the fsk, fmv, and skolem lists are already in data structures (implication, inert cans). Ideally the list would also include unification variables, but I don't think their list is maintained anywhere currently, so I imagine their might be a good reason for that. But. If I had the unflattened constraints as-is from GHC, and a list of all in-scope type variables (incl covars?), my life as plugin author would be much easier. That would let me replace my type and coercion traversing code with just calls to the {{{subst}}} functions. My final ingredient for this wishlist would be for the {{{subst*}}} functions to indicate if they ever applied the passed-in substitution: I need to know if a substitution actually applied to a constraint. I could ask for free vars before substing, but that incurs a redundant traversal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 10:11:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 10:11:27 -0000 Subject: [GHC] #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory In-Reply-To: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> References: <047.4ee6e3cb6277c23f86d13aa1f86642ee@haskell.org> Message-ID: <062.d64fbc453442ae1fd19aeb810fe14a2a@haskell.org> #16017: ghc-8.6.1 and ghc-8.6.2 use a log of memory -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 11:26:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 11:26:10 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.cd402b6fef3d367030a8581c6cde911c@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5435 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"3899966e4613ec18f365c28d64e9acc163cc1165/ghc" 3899966e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3899966e4613ec18f365c28d64e9acc163cc1165" Fix #16008 with a pinch of addConsistencyConstraints Summary: #16008 happened because we forgot to typecheck nullary associated type family instances in a way that's consistent with the type variables bound by the parent class. Oops. Easily fixed with a use of `checkConsistencyConstraints`. Test Plan: make test TEST=T16008 Reviewers: simonpj, goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #16008 Differential Revision: https://phabricator.haskell.org/D5435 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 11:29:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 11:29:51 -0000 Subject: [GHC] #16008: GHC HEAD type family regression involving invisible arguments In-Reply-To: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> References: <050.0cadeec8ddcf97973e1a554daa3a34d5@haskell.org> Message-ID: <065.9e3f5615d34cc51cc02d85b4dcd45429@haskell.org> #16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: TypeFamilies, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16008 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5435 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => typecheck/should_compile/T16008 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:06:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:06:25 -0000 Subject: [GHC] #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows In-Reply-To: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> References: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> Message-ID: <061.0b5e7698bebffb65e83a37f1276979a0@haskell.org> #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Ben Gamari ): In [changeset:"e709c8f8d45c699840f5bab7c9ff71373a53b8b0/ghc" e709c8f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e709c8f8d45c699840f5bab7c9ff71373a53b8b0" utils/gen-dll: Bump containers upper bound Fixes #16023. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:06:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:06:40 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.f61037092a85199b8bf050afb65eeed9@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Phab:D5436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6a71add81d8f30b0caca0e869fb8e35787881c87/ghc" 6a71add8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6a71add81d8f30b0caca0e869fb8e35787881c87" rts: Disable fallthrough attribute when compiling with Clang Apparently clang doesn't enable implicitly fallthrough warnings by default http://llvm.org/viewvc/llvm-project?revision=167655&view=revision when compiling C and the attribute cause warnings of their own (#16019). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:06:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:06:55 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.d3347f05427c0b3412e7c43e5a335c8a@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"4b3022021d49778bcd29a57308dbe0a076549f1b/ghc" 4b302202/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b3022021d49778bcd29a57308dbe0a076549f1b" testsuite: Mark tickets identified in #15467 as broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:10:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:10:53 -0000 Subject: [GHC] Batch modify: #15876, #15878, #15608, #15992, #15995, #15997, ... In-Reply-To: <480.2e63c5ba2929d6c08b92e3e4f2f1a1b0@haskell.org> References: <480.2e63c5ba2929d6c08b92e3e4f2f1a1b0@haskell.org> Message-ID: <480.2e63c5ba2929d6c08b92e3e4f2f1a1b0@haskell.org> Batch modification to #15876, #15878, #15608, #15992, #15995, #15997, #16027, #15998, #16000, #15978, #15977, #15967, #15996, #15897, #15914, #15915, #15917, #16004, #15882, #15940, #15907, #15932, #15905, #15921, #15944, #15883, #15885, #15888, #15880, #15889, #15923, #15924, #15933, #15936, #15895, #16029, #15891, #15444, #14613, #15928, #15946, #15909, #15929, #15958, #15957, #15982, #15973, #15983, #15984, #15913, #15912, #15918, #15927, #15960, #15947, #15942, #15945, #15989, #15966, #15956, #15988, #15991, #15959, #16011, #16012, #16013, #15993, #16015, #16017, #16021, #16020, #16014, #15952, #16023 by bgamari: milestone to None Comment: Ticket retargeted after milestone closed -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:13:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:13:03 -0000 Subject: [GHC] #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows In-Reply-To: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> References: <046.9f05d0a394050f0ed18d59bb1474aefb@haskell.org> Message-ID: <061.7f3a55e20f6ec40089f9bc07009da083@haskell.org> #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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 * version: 8.6.2 => 8.7 * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:13:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:13:54 -0000 Subject: [GHC] #15444: 8.4.3 has an undocumented dependency on libnuma. In-Reply-To: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> References: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> Message-ID: <062.f0f59d6a9da76c231c081d98b818ed0c@haskell.org> #15444: 8.4.3 has an undocumented dependency on libnuma. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.4.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.6.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:14:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:14:40 -0000 Subject: [GHC] #15608: Segfault in retainer profiling In-Reply-To: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> References: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> Message-ID: <058.82e258b47c6f063864c786d2e21be60c@haskell.org> #15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.5 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:D5134 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:15:50 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.6c4327418d973c3a11280aef9da76499@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13897 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: This is certainly #13897. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:16:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:16:03 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.cafb1082782f7d2ad1e7ba4f7897d43e@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.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): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): Sorry to be an annoyance and ask about this again, but is it looking like this will land for 8.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:16:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:16:10 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.9492a331b71b9841cf022a628cc1516a@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: upstream Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: continuous | integration, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Let's try to fix this in Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:17:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:17:34 -0000 Subject: [GHC] #15982: Hadrian's `--configure` flag is broken on Windows In-Reply-To: <050.1db3a576777b406081d2912367d7ba45@haskell.org> References: <050.1db3a576777b406081d2912367d7ba45@haskell.org> Message-ID: <065.5024ab9de83c3fd4922d0b99ba4a19a0@haskell.org> #15982: Hadrian's `--configure` flag is broken on Windows -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * os: Unknown/Multiple => Windows * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 15:18:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 15:18:01 -0000 Subject: [GHC] #15915: Add CI for integer-simple In-Reply-To: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> References: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> Message-ID: <061.3dacb37b7a736476e797e7f8c942fa0d@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.6.2 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.8.1 Comment: I would like to make this happen soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 16:32:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 16:32:50 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.cc87047cf39f569587cb4657969a22d1@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): I realized that it is more reasonable to try a clean build after this kind of change. The error I get after `make clean` is similar but happens in different place: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.3 -hide-all-packages -i -ilibraries /ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim /dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O -dcore-lint -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 -dynamic-too -c libraries/ghc-prim/./GHC/CString.hs -o libraries/ghc-prim /dist-install/build/GHC/CString.o -dyno libraries/ghc-prim/dist- install/build/GHC/CString.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181207 for x86_64-unknown-linux): Ix{Int}.index: Index (33619973) out of range ((0,821)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/CString.o' failed make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 16:56:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 16:56:54 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.34b3eb8c58bc73ca287a117075909f87@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: new Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 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 supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:07:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:07:42 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.8ef0efd673ab480dd02c27128c08f9ef@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me like the issue is that your `get` implementation doesn't actually consume the output that it parses, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:18:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:18:59 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.727306984b770919267b8aff89499660@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: closed Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by supersven): * status: new => closed * resolution: => fixed Comment: Please see: https://github.com/ghc/ghc/pull/236 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:20:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:20:37 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.1c72ad411c8fe45d067d5bb0acca358a@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 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 supersven): * status: closed => new * owner: supersven => (none) * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:20:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:20:58 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.64edc4c038ccd325d1fe5a7241b0cf2b@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: new Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 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 supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:21:14 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.a2a7dca7e987fd1e3497e78840d2e58a@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: patch Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 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 supersven): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:33:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:33:31 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi Message-ID: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently loaded this file into GHCi: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy data Foo1 (a :: k) where MkFoo1a :: Proxy a -> Int -> Foo1 a MkFoo1b :: { a :: Proxy a, b :: Int } -> Foo1 a data family Foo2 (a :: k) data instance Foo2 (a :: k) where MkFoo2a :: Proxy a -> Int -> Foo2 a MkFoo2b :: { c :: Proxy a, d :: Int} -> Foo2 a }}} And when I queried these datatypes with `:info`, I saw this: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint- explicit-kinds GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :i Foo1 Foo2 type role Foo1 nominal phantom data Foo1 @k (a :: k) where MkFoo1a :: forall k (a :: k). (Proxy @{k} a) -> Int -> Foo1 k a MkFoo1b :: forall k (a :: k). {a :: Proxy @{k} a, b :: Int} -> Foo1 k a -- Defined at Bug.hs:8:1 data family Foo2 @k (a :: k) -- Defined at Bug.hs:12:1 data instance forall k (a :: k). Foo2 @k a where MkFoo2a :: forall k (a :: k). (Proxy @{k} a) -> Int -> Foo2 @k a MkFoo2b :: forall k (a :: k). {c :: Proxy @{k} a, d :: Int} -> Foo2 @k a -- Defined at Bug.hs:13:15 }}} Yuck. A couple of icky things to note here: * For some reason, the `Proxy @{k} a` field is needlessly parenthesized in `MkFoo1a` and `MkFoo2a`. This does //not// happen when record syntax is used, as demonstrated with `MkFoo1b` and `MkFoo2b`. * Even more strangely, despite the fact that `k` is a specified argument, we're pretty-printing the return type of `MkFoo1{a,b}` as `Foo k a`, not `Foo @k a`. This problem doesn't appear to happen for data family instances, since `MkFoo2{a,b}` don't have this issue. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:42:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:42:12 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi In-Reply-To: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> References: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> Message-ID: <065.7ce1f3d9b6b5f878b6e4cb3763aaa2cb@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5440 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5440 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:46:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:46:07 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives Message-ID: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.7 libraries/base | Keywords: Data.Fixed, | Operating System: Unknown/Multiple Show | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic: {{{#!hs GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help Prelude> show (Just (-1 :: Int)) "Just (-1)" Prelude> show (Just (-1 :: Float)) "Just (-1.0)" }}} However, the Show instance for Fixed does not {{{#!hs Prelude> :m Data.Fixed Prelude Data.Fixed> show (Just (-1 :: Fixed E2)) "Just -1.00" Prelude Data.Fixed> }}} I would expect it to, because of consistency and because the result "Just -1.00" is ill-typed when seen as an expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:48:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:48:18 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.9fc9cdb140ec6f319731f27dd44d44f1@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5381 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 17:55:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 17:55:23 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.b4629fa554debe516918e1035336a4e2@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5335 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: => Phab:D5335 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 18:48:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 18:48:06 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.5662590908992836e384215125a8bf70@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's worth noting that this Core Lint error only appears to occur when GHC constructs a wrapper for `Prod`. In other words, the following errors: {{{#!hs data F :: forall (cat1 :: ob1). ob1 -> Type where Prod :: forall u (a :: u). F a }}} But this does //not// error: {{{#!hs data F :: forall (cat1 :: ob1). ob1 -> Type where Prod :: F a }}} Since in the latter code, `Prod` won't need a wrapper, and its type will simply be `forall {ob1} {cat1 :: ob1} (a :: ob1). F a`. (Currently, there's no way to write that with GHC's explicit `forall` syntax, so pretty much any attempt to write the type of `Prod` using a `forall` will trigger this error.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 19:41:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 19:41:59 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.93e1237ba42ee416fce7aeab447568d6@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.7 Resolution: | Keywords: Data.Fixed, | Show, newcomer 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 RyanGlScott): * keywords: Data.Fixed, Show => Data.Fixed, Show, newcomer Comment: Good catch. I wouldn't expect this to be difficult to fix—we'd just need to change the `Show` instance such that negative `Fixed` values are parenthesized with a sufficiently high precedence value. For inspiration, one can look at the existing [http://git.haskell.org/ghc.git/blob/4b3022021d49778bcd29a57308dbe0a076549f1b:/libraries/base/GHC/Show.hs#l472 Show Integer instance], which parenthesizes negative `Integer`s when the precedence is higher than 6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 20:12:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 20:12:34 -0000 Subject: [GHC] #16032: Compile speed regression Message-ID: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.6.3 seems to be about 10% slower than GHC 8.4.4 compiling a large input. The times goes from 22.25m to 24.5m. Unfortunately, I cannot include the modules to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 20:12:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 20:12:51 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.6bf7d2f5bc0ad615654eed891eaea46d@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by augustss): * Attachment "ghc-compile-time.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 20:27:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 20:27:40 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.b5959c6378dbf22805a0c4ce38cebc91@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Phab:D5436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): @Ben: your logic means that clang will do " #define FALLTHROUGH GNU_ATTRIBUTE(fallthrough)" is that what you want? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 21:12:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 21:12:22 -0000 Subject: [GHC] #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 Message-ID: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: RankNTypes | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program typechecks on GHC 7.0.4 through 8.4.4: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where f :: (forall a. a -> forall b. b -> c) -> () f (_ :: forall a. a -> forall b. b -> z) = () }}} However, it does not typecheck on GHC 8.6.3: {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:4: error: • Couldn't match type ‘b0 -> c’ with ‘forall b. b -> z’ Expected type: a -> forall b. b -> z Actual type: a -> b0 -> c • When checking that the pattern signature: forall a. a -> forall b. b -> z fits the type of its context: forall a. a -> forall b. b -> c In the pattern: _ :: forall a. a -> forall b. b -> z In an equation for ‘f’: f (_ :: forall a. a -> forall b. b -> z) = () • Relevant bindings include f :: (forall a. a -> forall b. b -> c) -> () (bound at Bug.hs:7:1) | 7 | f (_ :: forall a. a -> forall b. b -> z) = () | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 21:13:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 21:13:42 -0000 Subject: [GHC] #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 In-Reply-To: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> References: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> Message-ID: <065.d127c2092cc09032f323f68eb5e79ac4@haskell.org> #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > The following program typechecks on GHC 7.0.4 through 8.4.4: > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE ScopedTypeVariables #-} > module Bug where > > f :: (forall a. a -> forall b. b -> c) -> () > f (_ :: forall a. a -> forall b. b -> z) = () > }}} > > However, it does not typecheck on GHC 8.6.3: > > {{{ > $ /opt/ghc/8.6.3/bin/ghc Bug.hs > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > > Bug.hs:7:4: error: > • Couldn't match type ‘b0 -> c’ with ‘forall b. b -> z’ > Expected type: a -> forall b. b -> z > Actual type: a -> b0 -> c > • When checking that the pattern signature: > forall a. a -> forall b. b -> z > fits the type of its context: forall a. a -> forall b. b -> c > In the pattern: _ :: forall a. a -> forall b. b -> z > In an equation for ‘f’: > f (_ :: forall a. a -> forall b. b -> z) = () > • Relevant bindings include > f :: (forall a. a -> forall b. b -> c) -> () (bound at > Bug.hs:7:1) > | > 7 | f (_ :: forall a. a -> forall b. b -> z) = () > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} New description: The following program typechecks on GHC 7.0.4 through 8.4.4: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where f :: (forall a. a -> forall b. b -> c) -> () f (_ :: forall a. a -> forall b. b -> c) = () }}} However, it does not typecheck on GHC 8.6.3: {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:4: error: • Couldn't match type ‘b0 -> c1’ with ‘forall b. b -> c’ Expected type: a -> forall b. b -> c Actual type: a -> b0 -> c1 • When checking that the pattern signature: forall a. a -> forall b. b -> c fits the type of its context: forall a. a -> forall b. b -> c1 In the pattern: _ :: forall a. a -> forall b. b -> c In an equation for ‘f’: f (_ :: forall a. a -> forall b. b -> c) = () • Relevant bindings include f :: (forall a. a -> forall b. b -> c1) -> () (bound at Bug.hs:7:1) | 7 | f (_ :: forall a. a -> forall b. b -> c) = () | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 21:43:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 21:43:46 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell In-Reply-To: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> References: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> Message-ID: <064.ce6f216a39787c6a8a3015fca6f239af@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5360 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm not that enthusiastic about a proposal as I don't know that anyone should rely on safe haskell as it's quite a neglected feature. I think I would rather write a proposal about removing safe haskell rather than understand how it should interact more precisely with plugins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 22:39:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 22:39:22 -0000 Subject: [GHC] #16034: Quadratic GC slowdown using RTS debug Message-ID: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> #16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 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: -------------------------------------+------------------------------------- Hello, Under some conditions of heavy heap usage, I seem to experience a quadratic slowdown due to GC using the debugging RTS only (for example, in the context of ticky profiling). I have been able to reproduce it using the following program (depending on the aeson library): {{{#!hs import Data.Aeson (eitherDecode, Value) import qualified Data.ByteString.Lazy as BL import Data.Maybe (catMaybes) import System.Directory (listDirectory) import System.FilePath ( () ) main :: IO() main = do let dir = "data" files <- listDirectory dir values <- catMaybes <$> mapM (readF dir) files print $ length values readF :: FilePath -> FilePath -> IO (Maybe Value) readF dir fp = do print (dir fp) blob <- BL.readFile (dir fp) case eitherDecode blob of Left _ -> return Nothing Right v -> return $ Just $! v }}} Here data is a directory filled with (identical) JSON files. See the attached Python script for the proposed dataset. {{{ $ ghc -O -dynamic -o main Main.hs $ ./main +RTS -s ... 18,583,045,600 bytes allocated in the heap 6,334,338,280 bytes copied during GC 975,763,072 bytes maximum residency (14 sample(s)) 6,986,112 bytes maximum slop 930 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 17727 colls, 0 par 2.596s 2.597s 0.0001s 0.0006s Gen 1 14 colls, 0 par 2.422s 2.422s 0.1730s 0.7947s INIT time 0.000s ( 0.000s elapsed) MUT time 3.349s ( 3.351s elapsed) GC time 5.019s ( 5.020s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 8.368s ( 8.371s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 5,548,968,539 bytes per MUT second Productivity 40.0% of total user, 40.0% of total elapsed }}} {{{ $ ghc -O -dynamic -debug -o main.debug Main.hs $ ./main +RTS -s ... 18,583,045,600 bytes allocated in the heap 6,334,332,424 bytes copied during GC 975,763,072 bytes maximum residency (14 sample(s)) 6,986,112 bytes maximum slop 930 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 17727 colls, 0 par 172.941s 172.959s 0.0098s 0.0459s Gen 1 14 colls, 0 par 9.532s 9.532s 0.6808s 3.2061s INIT time 0.000s ( 0.000s elapsed) MUT time 5.020s ( 5.017s elapsed) GC time 182.473s (182.491s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 187.492s (187.508s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 3,701,999,827 bytes per MUT second Productivity 2.7% of total user, 2.7% of total elapsed }}} In debug mode, the runtime is almost quadratic: {{{ Nb of files Duration (non-debug) Duration (debug) 100 0.8s 2.8s 200 1.6s 8.8s 400 3.2s 27.6s 1000 8.2s 168.9s }}} The problem can be seen with either GHC 8.6.3 (here on Archlinux, with aeson 1.4.2.0) but was also observed using GHC 8.4.4, with static binaries, using "stack". I was able to reproduce with both threaded and non-threaded mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 22:39:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 22:39:39 -0000 Subject: [GHC] #16034: Quadratic GC slowdown using RTS debug In-Reply-To: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> References: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> Message-ID: <059.4a7126915e9c34ca3464c6bd35632bf2@haskell.org> #16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by remyo): * Attachment "generate.py" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 22:43:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 22:43:37 -0000 Subject: [GHC] #16034: Quadratic GC slowdown using RTS debug In-Reply-To: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> References: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> Message-ID: <059.99d392300e4dea1b4d8cfef7f4af9e3e@haskell.org> #16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 remyo): Basic debugging seems to indicate the time is mainly spent in {{{scheduleDoGC}}} and especially {{{countBlocks}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 22:50:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 22:50:01 -0000 Subject: [GHC] #16035: keep-cafs fails on FreeBSD 11 Message-ID: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> #16035: keep-cafs fails on FreeBSD 11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.7 System (Linker) | Keywords: | Operating System: FreeBSD Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's a bit unclear why: {{{#!patch =====> keep-cafs(normal) 9 of 10 [0, 4, 2] cd "rts/keep-cafs.run" && $MAKE -s --no-print-directory KeepCafs Actual stdout output differs from expected: diff -uw "rts/keep-cafs.run/keep-cafs.stdout.normalised" "rts/keep- cafs.run/keep-cafs.run.stdout.normalised" --- rts/keep-cafs.run/keep-cafs.stdout.normalised 2018-12-11 22:41:53.650952000 +0000 +++ rts/keep-cafs.run/keep-cafs.run.stdout.normalised 2018-12-11 22:41:53.651227000 +0000 @@ -1,2 +1,4 @@ -1000 -1001 +KeepCafsMain: KeepCafs1.o: unknown symbol `base_GHCziBase_zdfMonadIO_closure' +KeepCafsMain: KeepCafs2.o: unknown symbol `base_GHCziNum_zdfNumInt_closure' +34410180672 +34410180672 }}} Perhaps a GHCi linker issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 22:50:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 22:50:12 -0000 Subject: [GHC] #16035: keep-cafs fails on FreeBSD 11 In-Reply-To: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> References: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> Message-ID: <061.2e1d2ef1ba52892a73f2f15181cc0ae6@haskell.org> #16035: keep-cafs fails on FreeBSD 11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 (Linker) | Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: rts/keep-cafs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => rts/keep-cafs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 22:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 22:56:57 -0000 Subject: [GHC] #16035: keep-cafs fails on FreeBSD 11 In-Reply-To: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> References: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> Message-ID: <061.1fb9de3ae39b7128e490341a412a32d8@haskell.org> #16035: keep-cafs fails on FreeBSD 11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 (Linker) | Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: rts/keep-cafs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `linkwhole` also fails with very similar symptoms: {{{ =====> linkwhole(normal) 4 of 8 [0, 0, 1] cd "driver/linkwhole/linkwhole.run" && $MAKE -s --no-print-directory linkwhole Wrong exit code for linkwhole()(expected 0 , actual 2 ) Stderr ( linkwhole ): host: lib.so: unknown symbol `base_GHCziNum_zdfNumInt_closure' host: Unable to resolve objects for lib.so gmake[2]: *** [Makefile:20: linkwhole] Error 1 *** unexpected failure for linkwhole(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:12:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:12:14 -0000 Subject: [GHC] #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 In-Reply-To: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> References: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> Message-ID: <065.87d335818fe18310982b8d218ee6ad59@haskell.org> #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: Commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`) is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.673d344018c65902c96bc7ac06183ffa@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 Phab:D5423 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4efafe7e5288532b385bbfe3cd684ddcda0f3b0a/ghc" 4efafe7e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4efafe7e5288532b385bbfe3cd684ddcda0f3b0a" Revert dynamically linking ghc. Building a dynamically linked ghc is broken do to incorrectly building and installing libffi. This disables building a dynamically linked ghc and ghc-iserv-dyn while keeping most of the code in the relevant commits: 79d5427e1 and 89fa34ecd Test Plan: Ensure build environment does NOT have a system libffi installed (you may want to use a nix environment). Then `hadrian/build.sh -c --flavour=default`. Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, carter GHC Trac Issues: #15837 Differential Revision: https://phabricator.haskell.org/D5430 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15915: Add CI for integer-simple In-Reply-To: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> References: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> Message-ID: <061.9ed1f94e5a4926aff9607df00a82eac9@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.6.2 Integration | Resolution: | Keywords: Operating System: 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:"50f0cd4647ffc6300c762375419831a11f8648e6/ghc" 50f0cd46/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="50f0cd4647ffc6300c762375419831a11f8648e6" circleci: Add integer-simple build target Fixes #15915. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15946: configure script makes use of ln -v flag which is not supported in OpenBSD In-Reply-To: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> References: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> Message-ID: <061.9647cb77de6799a8aeeb85d30d6eec1e@haskell.org> #15946: configure script makes use of ln -v flag which is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: configure Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5425 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"066d3989a45003d2caaf96fab90ec30b55a647ee/ghc" 066d3989/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="066d3989a45003d2caaf96fab90ec30b55a647ee" configure: Don't use ln -v There's no reason why we need to print the linked files and apparently ln on OpenBSD doesn't support -v. Fixes #15946. Test Plan: Validate Reviewers: monoidal Reviewed By: monoidal Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15946 Differential Revision: https://phabricator.haskell.org/D5425 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names In-Reply-To: <046.a0cda9df357797abce34c12980353145@haskell.org> References: <046.a0cda9df357797abce34c12980353145@haskell.org> Message-ID: <061.10402a092ab97e3a526c858f7b12bb92@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5434 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7491cedb20d15a54e905205c51aea72a13ac73aa/ghc" 7491ced/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7491cedb20d15a54e905205c51aea72a13ac73aa" Hadrian: simple targets for building libraries and executables This patch introduces (phony) build targets of the form (1) stage:: (e.g: stage1:lib:Cabal) (2) stage:: (e.g: stage2:exe:ghc-bin) where (1) builds the given library with the stage N compiler and (2) builds the given executable with the stage N-1 compiler. This patch may be generating too many such targets but it's a first stab that we can refine. This fixes #15949. Test Plan: hadrian/build.sh stage1:exe:ghc-bin Reviewers: bgamari, snowleopard Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15949 Differential Revision: https://phabricator.haskell.org/D5434 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.f8ff3cc78bf0f05da434af41ffce9082@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5431 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a5e76a073afc8ffdde274a4cb3d09847f2d35be9/ghc" a5e76a07/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5e76a073afc8ffdde274a4cb3d09847f2d35be9" Hadrian: ability to run a subset of the testsuite This was supposed to be working already but didn't work when we specified several tests with --only. This patch not only fixes this but also makes it possible to specify a subset of tests to run with the TEST environment variable, like the make build system. Here are some examples: hadrian/build.sh test --only=plugins01 hadrian/build.sh test --only="plugins01 plugins02" TEST="plugins01 plugins02" hadrian/build.sh test TEST=plugins03 hadrian/build.sh test --only="plugins01 plugins02" When both the TEST environment variable and the --only flag are used, we simply concatenate the list of tests from both sources and ask the testsuite driver to run them all. This patch addresses #16026. Test Plan: hadrian/build.sh test --only="plugins01 plugins02" Reviewers: bgamari, snowleopard Reviewed By: bgamari, snowleopard Subscribers: rwbarton, carter GHC Trac Issues: #16026 Differential Revision: https://phabricator.haskell.org/D5431 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.f342b6e05576dd66b10625aaf8511876@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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): Phab:D5394 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"288f681e06accbae690c46eb8a6e997fa9e5f56a/ghc" 288f681/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="288f681e06accbae690c46eb8a6e997fa9e5f56a" Fix recompilation bug with default class methods (#15970) If a module uses a class, then it can instantiate the class and thereby use its default methods, so we must include the default methods when calculating the fingerprint for the class. Test Plan: New unit test: driver/T15970 Before: ``` =====> T15970(normal) 1 of 1 [0, 0, 0] cd "T15970.run" && $MAKE -s --no-print-directory T15970 Wrong exit code for T15970()(expected 0 , actual 2 ) Stdout ( T15970 ): Makefile:13: recipe for target 'T15970' failed Stderr ( T15970 ): C.o:function Main_zdfTypeClassMyDataType1_info: error: undefined reference to 'A_toTypedData2_closure' C.o:function Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data+0x298): error: undefined reference to 'A_toTypedData2_closure' C.o(.data+0x480): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) ``` After: test passes. Reviewers: bgamari, simonpj, erikd, watashi, afarmer Subscribers: rwbarton, carter GHC Trac Issues: #15970 Differential Revision: https://phabricator.haskell.org/D5394 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15904: hp2ps fail with parse error when the command args contains double quotes In-Reply-To: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> References: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> Message-ID: <061.a729801e5e5f9498af9d6c78056d0227@haskell.org> #15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Resolution: fixed | Keywords: hp2ps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5346 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0136906c9e69b02cd1ffe2704fa5d737d8c4cfaf/ghc" 0136906/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0136906c9e69b02cd1ffe2704fa5d737d8c4cfaf" Fix uninformative hp2ps error when the cmdline contains double quotes Reapply D5346 with fix incompatible shell quoting in tests. It seems like `$'string'` is not recognized under all test environments, so let's avoid it in tests. Test Plan: ``` hp2ps: "T15904".hp, line 2: integer must follow identifier ``` use new ghc and hp2ps to profile a simple program. Reviewers: simonmar, bgamari, erikd, tdammers Reviewed By: bgamari Subscribers: tdammers, carter, rwbarton GHC Trac Issues: #15904 Differential Revision: https://phabricator.haskell.org/D5388 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.fccfaa2bca8394d651ab17c3f6a13845@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d549c081f19925dd0e4c70d45bded0497c649d49/ghc" d549c08/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d549c081f19925dd0e4c70d45bded0497c649d49" dmdAnal: Move handling of datacon strictness to mkWWstr_one Previously datacon strictness was accounted for when we demand analysed a case analysis. However, this results in pessimistic demands in some cases. For instance, consider the program (from T10482) data family Bar a data instance Bar (a, b) = BarPair !(Bar a) !(Bar b) newtype instance Bar Int = Bar Int foo :: Bar ((Int, Int), Int) -> Int -> Int foo f k = case f of BarPair x y -> case burble of True -> case x of BarPair p q -> ... False -> ... We really should be able to assume that `p` is already evaluated since it came from a strict field of BarPair. However, as written the demand analyser can not conclude this since we may end up in the False branch of the case on `burble` (which places no demand on `x`). By accounting for the data con strictness later, applied to the demand of the RHS, we get the strict demand signature we want. See Note [Add demands for strict constructors] for a more comprehensive discussion. Test Plan: Validate Reviewers: simonpj, osa1, goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15696 Differential Revision: https://phabricator.haskell.org/D5226 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports In-Reply-To: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> References: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> Message-ID: <061.43d5bfa0b929cd3f7cd0a7644ca65d9a@haskell.org> #14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14225 Blocked By: | Blocking: Related Tickets: #15611 | Differential Rev(s): Phab:D5331 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4c174dddc7b36ebf97ba0e182f843d563e3d598c/ghc" 4c174ddd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c174dddc7b36ebf97ba0e182f843d563e3d598c" Misleading msg with qualified imports "No module named X imported" To check whether a given module has been imported, we do the following: From the list of all qualified names we extract the distinct module names to a list of module names. Then we check whether the given module name is in this list of module names. Test Plan: make test TEST=T14225 Reviewers: mpickering, hvr, monoidal, osa1, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14225 Differential Revision: https://phabricator.haskell.org/D5331 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15924: Do not save performance test results if worktree is dirty In-Reply-To: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> References: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> Message-ID: <060.da7ecfcf221067e38fb503c3955e8dbe@haskell.org> #15924: Do not save performance test results if worktree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5368 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"54ee148c2b28d2326cfd273aed4842c2b53e2625/ghc" 54ee148c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="54ee148c2b28d2326cfd273aed4842c2b53e2625" Do not save performance test results if worktree is dirty. Reviewers: bgamari, tdammers Reviewed By: bgamari, tdammers Subscribers: rwbarton, carter GHC Trac Issues: #15924 Differential Revision: https://phabricator.haskell.org/D5368 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.6a91151ae86c3fa34923bbc0a5af6054@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"21339c9f6bfb952a3a0b8de5ee649d46dfbf0d9b/ghc" 21339c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21339c9f6bfb952a3a0b8de5ee649d46dfbf0d9b" RTS linker: don't crash early when not finding extra-libraries Allow GHCi to not crash when no assumed DLL is found in the standard location. E.g. when loading the package built "dyn" way, we may well have the package's DLL around, and it's the system linker which loads necessary dependencies. Why does this (partially) fix #11042? It's because we often (and when having packages built `dyn` way -- almost always) don't need to load anything recorded in the `extra-libraries` stanza, since if the package DLL exists, GHCi linker simply calls the system linker (via `dlopen`/ `LoadLibrary` APIs) to load it and doesn't bother to load package prelinked object file (if any) or package static library. Thus, all "regular" (with no fancy low-level package content manipulation) packages built "dyn" way should be OK after this fix. Reviewers: hvr, bgamari, int-index Reviewed By: bgamari, int-index Subscribers: Phyx, int-index, rwbarton, carter GHC Trac Issues: #11042 Differential Revision: https://phabricator.haskell.org/D5170 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.7d201cbd8b8e7391e79922c2722b4803@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5300 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"9e763afa9f1f75eacce24291f298f32527591b14/ghc" 9e763af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e763afa9f1f75eacce24291f298f32527591b14" PPC NCG: Implement MachOps for smaller sizes Generate code for MachOps with smaller than wordsize data. Refactor conversion MachOps. Fixes #15854 Test Plan: validate (I validated on powerpc64le and x86_64 Linux) Reviewers: bgamari, hvr, erikd, simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15854 Differential Revision: https://phabricator.haskell.org/D5300 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.ec2d825bff4c50ea94f3fbbd6a99f955@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"da05d79d03e5e03e391b381f23c46fc02957abf7/ghc" da05d79/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da05d79d03e5e03e391b381f23c46fc02957abf7" Support registering Plugins through the GHC API This allows tooling using the GHC API to use plugins internally. Hopefully this will make it possible to decouple the development of useful plugins from (currently) kitchen-sink type tooling projects such as ghc-mod or HIE -- at least to some extent. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, alanz, rwbarton, carter GHC Trac Issues: #15826 Differential Revision: https://phabricator.haskell.org/D5278 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.47bc2a6faccd0eeef63183b4ee2ee10e@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.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:D4859 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"18b74cdbbfa053704caabd104587d8a91a9233a0/ghc" 18b74cdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18b74cdbbfa053704caabd104587d8a91a9233a0" testsuite: Add tests for #15270 Reviewers: alpmestan Reviewed By: alpmestan Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5216 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux In-Reply-To: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> References: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> Message-ID: <061.6fe76035a3af15f817f7dcbd31349a19@haskell.org> #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.7 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15847, #12759 | Differential Rev(s): Phab:D5288 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea/ghc" c98e25a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea" Explicitly pass -fno-PIC to C compiler on linux Recent gcc on some linux ditributions may have -fPIC on by default ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations ``` This results in following error for i686: ``` $ TEST=T13366 make test ... c-iserv.bin: /home/watashi/github/ghc/libraries/ghc-prim/dist-install/build/HSghc-pri m-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' ghc-stage2: unable to load package `ghc-prim-0.5.3' ... ``` As our runtime linker doesn't support R_386_GOTPC relocations at all (#15847). Also while we don't have such problem on x86_64, it's not desired to build PIC objects either. Test Plan: `TEST=T13366 make test` passed on {rGHC82a716431cc680392e332bc2b1a1fd0d7faa4cd8} Reviewers: simonmar, bgamari, austin Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15848 Differential Revision: https://phabricator.haskell.org/D5288 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.7541a446b4b4d71d0a0bff7592f80a94@haskell.org> #1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari ): In [changeset:"c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea/ghc" c98e25a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea" Explicitly pass -fno-PIC to C compiler on linux Recent gcc on some linux ditributions may have -fPIC on by default ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations ``` This results in following error for i686: ``` $ TEST=T13366 make test ... c-iserv.bin: /home/watashi/github/ghc/libraries/ghc-prim/dist-install/build/HSghc-pri m-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' ghc-stage2: unable to load package `ghc-prim-0.5.3' ... ``` As our runtime linker doesn't support R_386_GOTPC relocations at all (#15847). Also while we don't have such problem on x86_64, it's not desired to build PIC objects either. Test Plan: `TEST=T13366 make test` passed on {rGHC82a716431cc680392e332bc2b1a1fd0d7faa4cd8} Reviewers: simonmar, bgamari, austin Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15848 Differential Revision: https://phabricator.haskell.org/D5288 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15847: GHCi cannot load .o built from c with -fPIC on i386 linux In-Reply-To: <046.0d428416ca6e4d905bff26c968f36b08@haskell.org> References: <046.0d428416ca6e4d905bff26c968f36b08@haskell.org> Message-ID: <061.173e6fcdeea79d10ce6d8d55d56c6c4b@haskell.org> #15847: GHCi cannot load .o built from c with -fPIC on i386 linux --------------------------------------------+------------------------------ Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System (Linker) | Version: 8.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by Ben Gamari ): In [changeset:"c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea/ghc" c98e25a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c98e25a4de88f12c6ded0a97fcf3ed8f4996b9ea" Explicitly pass -fno-PIC to C compiler on linux Recent gcc on some linux ditributions may have -fPIC on by default ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations ``` This results in following error for i686: ``` $ TEST=T13366 make test ... c-iserv.bin: /home/watashi/github/ghc/libraries/ghc-prim/dist-install/build/HSghc-pri m-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' ghc-stage2: unable to load package `ghc-prim-0.5.3' ... ``` As our runtime linker doesn't support R_386_GOTPC relocations at all (#15847). Also while we don't have such problem on x86_64, it's not desired to build PIC objects either. Test Plan: `TEST=T13366 make test` passed on {rGHC82a716431cc680392e332bc2b1a1fd0d7faa4cd8} Reviewers: simonmar, bgamari, austin Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15848 Differential Revision: https://phabricator.haskell.org/D5288 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings In-Reply-To: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> References: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> Message-ID: <066.7c57fc7f106eb63c303cd810d174bff9@haskell.org> #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: shayne- | fletcher-da Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal 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:D5251 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8a4edd15d87849d070f7608b0825789a22e52374/ghc" 8a4edd1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a4edd15d87849d070f7608b0825789a22e52374" Enable rebindable fail with overloaded strings Summary: enable rebindable fail with overloaded strings Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, ndmitchell, rwbarton, carter GHC Trac Issues: #15645 Differential Revision: https://phabricator.haskell.org/D5251 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> References: <045.f082fab7438101dc39442d6c1de2a5dd@haskell.org> Message-ID: <060.c105ee6ba3ffe31c8c880dd7fc7056a2@haskell.org> #703: all binaries built by ghc have executable stacks -------------------------------------+------------------------------------- Reporter: duncan | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T703 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4faab14bcf8a892414306a61bcde02d82cf735be/ghc" 4faab14b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4faab14bcf8a892414306a61bcde02d82cf735be" testsuite: Skip T703 on non-Linux platforms While the test is in principle applicable to many platforms, the current implementation requires readelf, which we can only assume is present on ELF-based platforms (e.g. Linux). See Trac #703. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #16035: keep-cafs fails on FreeBSD 11 In-Reply-To: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> References: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> Message-ID: <061.dda7f43054d4d7da99b8406384d64193@haskell.org> #16035: keep-cafs fails on FreeBSD 11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 (Linker) | Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: rts/keep-cafs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"847e8b60ff1f2a1b2dcf281a6e82c340225acf96/ghc" 847e8b60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="847e8b60ff1f2a1b2dcf281a6e82c340225acf96" testsuite: Mark keep-cafs and keep-cafs-fail as broken on FreeBSD See #16035. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:21:06 -0000 Subject: [GHC] #16035: keep-cafs fails on FreeBSD 11 In-Reply-To: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> References: <046.490e482e00e00a603156e7a1cf01ebef@haskell.org> Message-ID: <061.acbee7dc13cbd55241ad0f8b02bee4cf@haskell.org> #16035: keep-cafs fails on FreeBSD 11 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 (Linker) | Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: rts/keep-cafs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"65fb69b78f4850b56ee6a2655bc5dc6c441a984e/ghc" 65fb69b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="65fb69b78f4850b56ee6a2655bc5dc6c441a984e" testsuite: Mark linkwhole as broken on FreeBSD See #16035. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:28:06 -0000 Subject: [GHC] #15915: Add CI for integer-simple In-Reply-To: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> References: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> Message-ID: <061.5b9f95d3264878d51638ca7270ddb4d9@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.6.2 Integration | 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 Dec 11 23:28:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:28:37 -0000 Subject: [GHC] #15946: configure script makes use of ln -v flag which is not supported in OpenBSD In-Reply-To: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> References: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> Message-ID: <061.df6c2a57a63074a9dd48ebca1381148f@haskell.org> #15946: configure script makes use of ln -v flag which is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: configure Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5425 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:29:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:29:02 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names In-Reply-To: <046.a0cda9df357797abce34c12980353145@haskell.org> References: <046.a0cda9df357797abce34c12980353145@haskell.org> Message-ID: <061.a1871b3a1314efa219d2151172e8b932@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:29:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:29:19 -0000 Subject: [GHC] #16026: No way to run a subset of the testsuite In-Reply-To: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> References: <046.6126bb148e02dc351b63b922e6c2be69@haskell.org> Message-ID: <061.749fda7cb1ec5fd6e1fd96fba0db9704@haskell.org> #16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: feature request | Status: closed Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:29:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:29:53 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.e56febcd9831d7744fbd5180d9949482@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: merge Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.6.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): Phab:D5394 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.8.1 => 8.6.4 Comment: It did. I'll retarget for 8.6.4 in case one happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:30:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:30:12 -0000 Subject: [GHC] #15924: Do not save performance test results if worktree is dirty In-Reply-To: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> References: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> Message-ID: <060.dd022111a4449f70492810aa45da758f@haskell.org> #15924: Do not save performance test results if worktree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.6.2 Resolution: fixed | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5368 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:30:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:30:25 -0000 Subject: [GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports In-Reply-To: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> References: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> Message-ID: <061.b63c9b1d2208292c6661d7a4656273f5@haskell.org> #14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14225 Blocked By: | Blocking: Related Tickets: #15611 | Differential Rev(s): Phab:D5331 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:31:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:31:00 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.83a99a0c5f5bd651e30aec6a922465db@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5300 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:31:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:31:14 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.939696ce3d3111b35b26cb47e6019208@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHC API | Version: 8.7 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:D5278 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:33:34 -0000 Subject: [GHC] #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux In-Reply-To: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> References: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> Message-ID: <061.cfa5c64b5b479f93f8e7ed5ee49cd6df@haskell.org> #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Driver | Version: 8.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15847, #12759 | Differential Rev(s): Phab:D5288 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Great catch, watashi! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:33:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:33:50 -0000 Subject: [GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings In-Reply-To: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> References: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> Message-ID: <066.4bd1c9cfd4c89c911072bcdcfec3e564@haskell.org> #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: shayne- | fletcher-da Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: GHCProposal 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:D5251 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 11 23:34:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Dec 2018 23:34:50 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.8afe0086cdb49d3a83f155faf58c89ed@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753, #11238 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * related: #10458 #5289 #12753 => #10458 #5289 #12753, #11238 * blockedby: 11238 => * milestone: => 8.8.1 Comment: As noted in the patch, there isn't quite fixed but it's likely as good as it's going to get. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 00:56:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 00:56:28 -0000 Subject: [GHC] #16027: Cannot use DefaultSignatures for TypeFamiles In-Reply-To: <050.c69f3341bbdc58bd8bae1da234037179@haskell.org> References: <050.c69f3341bbdc58bd8bae1da234037179@haskell.org> Message-ID: <065.f7c0db9aa243aad61928edb231b8de71@haskell.org> #16027: Cannot use DefaultSignatures for TypeFamiles -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 Ericson2314): @RyanGlScott nice trick! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 02:30:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 02:30:06 -0000 Subject: [GHC] #16036: expDouble## 0.0## doesn't get complied into 1.0## Message-ID: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> #16036: expDouble## 0.0## doesn't get complied into 1.0## -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [nix-shell:/tmp]$ cat T.hs {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file #-} module T (f) where import GHC.Float import GHC.Prim f :: Double f = D# (expDouble# 0.0## -## 1.0##) [nix-shell:/tmp]$ ghc -fforce-recomp T.hs [1 of 1] Compiling T ( T.hs, T.o ) [nix-shell:/tmp]$ cat T.dump-simpl ==================== Tidy Core ==================== 2018-12-12 02:23:40.288094743 UTC Result size of Tidy Core = {terms: 20, types: 6, coercions: 0, joins: 0/0} -- RHS size: {terms: 5, types: 0, coercions: 0, joins: 0/0} f :: Double [GblId, Str=m, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 15 20}] f = GHC.Types.D# (-## (expDouble# 0.0##) 1.0##) … }}} This was spotted in real code where we had GHC generate something like {{{#!haskell 1# -> jump $j9_s1IVU (GHC.Prim.+## sc3_s2pVI (GHC.Prim.-## (GHC.Prim.expDouble# 0.0##) 1.0##)) }}} I would expect this (I think reasonably) to be just `{{{jump $j9_s1IVU sc3_s2pVI}}}`. Maybe {{{expDouble## ##}}} should always evaluate at compile time to not block further constant folding? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 03:40:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 03:40:02 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found In-Reply-To: <042.925a06cf3801c7d8163448594b84be93@haskell.org> References: <042.925a06cf3801c7d8163448594b84be93@haskell.org> Message-ID: <057.4c563649872d38d0d5de96ba5b1d24b9@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * status: closed => new * resolution: fixed => Comment: Reopening because the merged patch has a syntax error (missing `,` that none of us spotted, including `autoconf`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 04:13:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 04:13:44 -0000 Subject: [GHC] #16037: memcpy test inexplicably failing Message-ID: <046.e148bae4ac1874a30d669ba5b5d04e9c@haskell.org> #16037: memcpy test inexplicably failing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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 started seeing failures in the `memcpy` test: {{{#!diff diff -uw "codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised" "codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised" --- codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised 2018-12-11 23:13:18.763730758 -0500 +++ codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised 2018-12-11 23:13:18.763730758 -0500 @@ -1,9 +1,9 @@ callMemcpy: +subq movq movq movl -subq -movl +xorl call memcpy addq jmp }}} The failures aren't themselves concerning; the new assembler is perfectly valid: {{{#!asm .section .text .align 8 .globl callMemcpy .type callMemcpy, @function callMemcpy: .Lc6: movl $1024,%eax subq $8,%rsp movq %rax,%rdx movq %rbx,%rdi movq %r14,%rsi xorl %eax,%eax call memcpy addq $8,%rsp jmp *(%rbp) .size callMemcpy, .-callMemcpy .section .note.GNU-stack,"", at progbits .ident "GHC 8.7.20181211" }}} However, I have no explanation for why this suddenly started happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 05:41:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 05:41:30 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups Message-ID: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found this while looking at compile time panic in my code for #9718. The test that triggers the panic is `T4003`, but here's a simpler version of the test: {{{ -- T4003B.hs module T4003B where import {-# SOURCE #-} T4003A (HsExpr) data HsOverLit id = OverLit (HsExpr id) deriving Eq ----------------------------------- -- T4003A.hs-boot module T4003A where data HsExpr i instance Eq i => Eq (HsExpr i) ----------------------------------- -- T4003A.hs module T4003A where import T4003B data HsExpr id = HsOverLit (HsOverLit id) | HsBracketOut (HsExpr id) deriving Eq }}} Compile in this order: T4003A.hs-boot, T4003B.hs, T4003A.hs {{{ $ ghc-stage1 -O -c T4003A.hs-boot $ ghc-stage1 -O -c T4003B.hs $ ghc-stage1 -O -c T4003A.hs }}} The last step fails with a panic because in the new STG pass I implemented for #9718 I assume that all recursive groups are already in a `Rec`, but this program has a set of bindings that are actually recursive but not in a `Rec`. If I dump ds and simpl outputs of the last step I see that this recursive group: (in the ds output) {{{ Rec { -- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0} $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V) -- RHS size: {terms: 9, types: 11, coercions: 0, joins: 0/0} $c/=_a287 $c/=_a287 = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 -> $dm/= ($fEqHsExpr $dEq_a27V) eta_B2 eta_B1 -- RHS size: {terms: 37, types: 37, coercions: 0, joins: 1/3} $c==_a27X $c==_a27X = \ @ id_a27U $dEq_a27V -> let { $dEq_a283 $dEq_a283 = $fEqHsExpr $dEq_a27V } in let { $dEq_a281 $dEq_a281 = $fEqHsOverLit $dEq_a27V } in \ ds_d2jB ds_d2jC -> join { fail_d2jD fail_d2jD _ = False } in case ds_d2jB of { HsOverLit a1_a27Q -> case ds_d2jC of { __DEFAULT -> jump fail_d2jD void#; HsOverLit b1_a27R -> == $dEq_a281 a1_a27Q b1_a27R }; HsBracketOut a1_a27S -> case ds_d2jC of { __DEFAULT -> jump fail_d2jD void#; HsBracketOut b1_a27T -> == $dEq_a283 a1_a27S b1_a27T } } end Rec } -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Becomes non-recursive in simplifier output: {{{ Rec { -- RHS size: {terms: 34, types: 45, coercions: 0, joins: 0/0} $fEqHsExpr_$c== $fEqHsExpr_$c== = \ @ id_a27U $dEq_a27V ds_d2jB ds1_d2jC -> case ds_d2jB of { HsOverLit a1_a27Q -> case ds1_d2jC of { HsOverLit b1_a27R -> case a1_a27Q of { OverLit a2_a2k8 -> case b1_a27R of { OverLit b2_a2kc -> == (noinline $fxEqHsExpr $dEq_a27V) a2_a2k8 b2_a2kc } }; HsBracketOut ipv_s2kg -> False }; HsBracketOut a1_a27S -> case ds1_d2jC of { HsOverLit ipv_s2kj -> False; HsBracketOut b1_a27T -> $fEqHsExpr_$c== $dEq_a27V a1_a27S b1_a27T } } end Rec } -- RHS size: {terms: 13, types: 10, coercions: 0, joins: 0/0} $fEqHsExpr_$c/= $fEqHsExpr_$c/= = \ @ id_a27U $dEq_a27V eta_B2 eta1_B1 -> case $fEqHsExpr_$c== $dEq_a27V eta_B2 eta1_B1 of { False -> True; True -> False } -- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0} $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($fEqHsExpr_$c== $dEq_a27V) ($fEqHsExpr_$c/= $dEq_a27V) -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Notice that `c==` refers to `fxEqHsExpr`, which refers to `fEqHsExpr`, which refers to `c==`, forming a recursive group. (Confirmed with GHC 8.6.3 and GHC HEAD) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 10:00:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 10:00:13 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.29bea5b473bb3826e6b516cf0363404a@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): @ckoparkar: Just go ahead! Grab the ticket and do the changes outlined by goldfire in [https://ghc.haskell.org/trac/ghc/ticket/15656#comment:6 comment:6]. It's not so much work, as you only have to add one line to every module (not line!) listed in your attachments. The really difficult work will be postponed to the new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 10:16:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 10:16:39 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.45373c0275e9a4030a2750cdb7269525@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * Attachment "prod.py" added. Python script for sampling and plotting productivity rates -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 12:22:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 12:22:37 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out Message-ID: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Keywords: FloatOut | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15155 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on #15155, I discovered that the magic function `GHC.Magic.noinline` tricked the float-out transformation into performing undesirable operations: Looking at the Core produced: {{{#!hs { ghc-prim-0.5.3:GHC.Types.I# x_azMX [Dmd=] -> case x_azMX of { __DEFAULT -> jump $j_sMly; 3674937295934324920# -> src check_ty_roles_sLb3 (src env_aqfK) (src role_aqfL) (ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind) } } }}} After simplification we end up with a toplevel variable basically redirecting to an imported variable. {{{#!hs -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} lvl330_r12qn :: Kind [GblId] lvl330_r12qn = ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind }}} This would cause `IND_STATIC`s when eventually emitted as assembly. IIRC `GHC.Magic.noinline` was introduced with GHC v8.2. This probably regressed the float-out optimisation. I have a patch to reclassify `noinline ` as cheap, so that it won't be floated out. N.B.: for more details, see: https://github.com/ghc/ghc/pull/224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 12:23:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 12:23:40 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.13d8cde9da6f2c314453d82ea0072fb9@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * owner: (none) => heisenbug Comment: Working on a fix and adding testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 13:28:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 13:28:30 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.b096fbc62c4b230f29965aded6995be8@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: ckoparkar Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * owner: (none) => ckoparkar Comment: Thanks RolandSenn. Updating that patch now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 13:36:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 13:36:27 -0000 Subject: [GHC] #16036: expDouble## 0.0## doesn't get complied into 1.0## In-Reply-To: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> References: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> Message-ID: <062.37f431e4c24923e6bf01f64cefddbcc1@haskell.org> #16036: expDouble## 0.0## doesn't get complied into 1.0## -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): > Maybe expDouble## ## should always evaluate at compile time to not block further constant folding? Yes that'd be easy to do via a rewrite rule. (See `prelude/PrelRules.hs`.) But whenever floating-point is in the picture I always worry about maintaining floating-point semantics. So someone fp- savvy should execute on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 15:33:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 15:33:30 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions Message-ID: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- My team has observed a 2x performance degradation in code that makes use of `StateT` that appears to be related to strictness and unboxing, even when built with `-O2`. Our code makes heavy use of the state monad, and when GHC fails to optimise this performance We've managed to minimise the behaviour to the following reproducer (that ignores state entirely), consisting of two files. It depends on `criterion` `Lib.hs`: {{{#!hs {-# LANGUAGE BangPatterns #-} module Lib where -- A type to take the place of state data X a = X { runX :: !a } test1 :: Int -> Int test1 = \(!i) -> go i where go = \(!i) -> if i > 0 then go $! i - 1 else i {-# NOINLINE test1 #-} test2 :: Int -> Int test2 = \(!i) -> runX (go i) where go = \(!i) -> if i > 0 then go $! i - 1 else X i {-# NOINLINE test2 #-} }}} `Main.hs`: {{{#!hs {-# LANGUAGE Strict #-} module Main where import Lib import Criterion import Criterion.Main main :: IO () main = defaultMain [ bgroup "main" [ bgroup "small" [ bench "without state" $ whnf test1 100000000 , bench "with state" $ whnf test2 100000000 ] ] ] }}} Run as above, the code takes twice as long to execute `test2` as it does `test1`. However, when the signature for `runX` is changed to `runX :: !Int`, the code in `test2` exhibits identical performance to `test1`. It has been reproduced across multiple linux64 machines, but not tested on any other architecture or operating system. Please find the full (stack - yes, I know) project as an attachment. You can simply `stack run` to observe the issue. If you have any further queries please let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 15:33:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 15:33:46 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.1010aacac1e8970c4f82247250fd6ba7@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 _recursion): * Attachment "bug.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 15:42:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 15:42:36 -0000 Subject: [GHC] #16041: Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete-record-updates Message-ID: <048.2ee2823bb5f04904134edd2bdeda2ca2@haskell.org> #16041: Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete- record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15656 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While implementing the GHC proposal which adds these flags to {{{-Wall}}}, we suppressed a lot of warnings generated due to code that is considered ''unsafe'' per these flags. However, the proper way to fix this is to refine things so that these warnings go away. See https://ghc.haskell.org/trac/ghc/ticket/15656#comment:6 for more details. w -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 15:51:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 15:51:55 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.054b08a51c3b2e65dc4be3e70cceba32@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: ckoparkar Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16041 | Differential Rev(s): Phab:D5415 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * differential: => Phab:D5415 * related: => #16041 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 15:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 15:52:18 -0000 Subject: [GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates In-Reply-To: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> References: <048.18d484ea3a84b8fb98b962ae915a09c0@haskell.org> Message-ID: <063.a6e51a38e3f5359a43a8a62d223ab3f3@haskell.org> #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: ckoparkar Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16041 | Differential Rev(s): Phab:D5415 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 15:54:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 15:54:06 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.3a287d508d5dd57ce6be426f8f41e1c4@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have not yet tried with criterion, but I tried with {{{ main = print (test1 10000000) }}} or `test2`, and ran with `+RTS -s`. I got the same amount of allocation either way. Do you see that too? If so, it's not a heap-allocation issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 16:23:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 16:23:29 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.59c7eaeac00b7710697b921378c9b8b8@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): Good point! I forgot to check that. Allocations are very close to each other but not identical. Both of the outputs are attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 16:23:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 16:23:56 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.388e040d1b24adde3a749518e92cfe00@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 _recursion): * Attachment "test1.log" added. `test1` allocation report -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 16:24:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 16:24:12 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.05fe686887bf8223c0b9adfdd7b9a0a8@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 _recursion): * Attachment "test2.log" added. `test2` allocation report -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 16:28:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 16:28:13 -0000 Subject: [GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler. In-Reply-To: <052.9187b36966727d1f3848569f633777f2@haskell.org> References: <052.9187b36966727d1f3848569f633777f2@haskell.org> Message-ID: <067.0104716dbd770fe636be1dece97ceba8@haskell.org> #16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sigh, quite right. All of this linker wrangling is very fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 17:02:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 17:02:10 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.5a0b34357903df8f0d9da1877388ff4f@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this would be fixed by nested cpr, see #1600. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 17:14:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 17:14:22 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.a4d8341cd5a16703d7c1ec0619a7dde8@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): A cursory read looks like it would, yes! Nevertheless, this is pretty concerning. I now have no idea why most of our codebase isn't getting hit by this issue, and suddenly I've run into a place where it occurs. I'm a little afraid for the performance stability of our code across GHC upgrades now. Is it something that could only be fixed by nested CPR or could a band-aid fix be put in place, do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 17:28:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 17:28:03 -0000 Subject: [GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler. In-Reply-To: <052.9187b36966727d1f3848569f633777f2@haskell.org> References: <052.9187b36966727d1f3848569f633777f2@haskell.org> Message-ID: <067.a0161638769974ce88df39e37ba4aa69@haskell.org> #16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Phab:D5443 fixes this, although in an admittedly rather hacky way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 17:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 17:34:37 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.f3bb4a78d3de90dd8991ca092869b677@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Oh, quite so, thank you Ben! I [https://gitlab.staging.haskell.org/ulysses4ever/ghc/commit/a73488e420de3f6990af500d7380e8d38dca8e9a fixed it] and now GHC compiles. I ran the test suite and had one unexpected failure (which I did not see before the patch): {{{ Unexpected results from: TEST="T14052" SUMMARY for test run started at Wed Dec 12 14:54:05 2018 UTC 0:52:39 spent to go through 6713 total tests, which gave rise to 20813 test cases, of which 13674 were skipped 45 had missing libraries 6936 expected passes 157 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: perf/should_run/T14052.run T14052 [[Errno 2] No such file or directory: 'perf/should_run/T14052.run/T14052.stats'] (ghci) }}} This feels strange. What should be the right way to investigate it? (I'm not super comfortable with the test suite). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 17:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 17:39:48 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.30f949106e23eedc8c4db7f574cd5ed6@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d77501cd5b9060e38acd50e11e0c5aae89d75b65/ghc" d77501cd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d77501cd5b9060e38acd50e11e0c5aae89d75b65" Improvements to demand analysis This patch collects a few improvements triggered by Trac #15696, and fixing Trac #16029 * Stop making toCleanDmd behave specially for unlifted types. This special case was the cause of stupid behaviour in Trac #16029. And to my joy I discovered the let/app invariant rendered it unnecessary. (Maybe the special case pre-dated the let/app invariant.) Result: less special-case handling in the compiler, and better perf for the compiled code. * In WwLib.mkWWstr_one, treat seqDmd like U(AAA). It was not being so treated before, which again led to stupid code. * Update and improve Notes There are .stderr test wibbles because we get slightly different strictness signatures for an argumment of unlifted type: rather than for Int# rather than for Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 17:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 17:39:48 -0000 Subject: [GHC] #16029: Inadequate absence analysis In-Reply-To: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> References: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> Message-ID: <061.e944d59bf02035925bf2039473e0ac95@haskell.org> #16029: Inadequate absence analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d77501cd5b9060e38acd50e11e0c5aae89d75b65/ghc" d77501cd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d77501cd5b9060e38acd50e11e0c5aae89d75b65" Improvements to demand analysis This patch collects a few improvements triggered by Trac #15696, and fixing Trac #16029 * Stop making toCleanDmd behave specially for unlifted types. This special case was the cause of stupid behaviour in Trac #16029. And to my joy I discovered the let/app invariant rendered it unnecessary. (Maybe the special case pre-dated the let/app invariant.) Result: less special-case handling in the compiler, and better perf for the compiled code. * In WwLib.mkWWstr_one, treat seqDmd like U(AAA). It was not being so treated before, which again led to stupid code. * Update and improve Notes There are .stderr test wibbles because we get slightly different strictness signatures for an argumment of unlifted type: rather than for Int# rather than for Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 18:49:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 18:49:47 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.d20b0b9711eb7a5eb5126cd70239a058@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3202, #3217 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 18:56:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 18:56:25 -0000 Subject: [GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules In-Reply-To: <045.cb7cce9290a571655339780c5a935547@haskell.org> References: <045.cb7cce9290a571655339780c5a935547@haskell.org> Message-ID: <060.a5a43ac5dcac47c1c33b327e473d9107@haskell.org> #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10857 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => closed * resolution: => duplicate * related: => #10857 Comment: This is exactly the same as #10857 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 19:33:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 19:33:32 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.cc8645aa8c4f625199196974ed3708ec@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Now we get, with `validate --slow` {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.7 -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/hieFile -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 -Icompiler/stage2/build/. -Icompiler/stage2/build/parser -Icompiler/stage2/build/utils -Icompiler/stage2/build/../rts/dist/build -Icompiler/stage2/build/stage2 -optP-DGHCI -optP-DINTEGER_GMP -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.9.0 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.1 -package-id filepath-1.4.2.1 -package-id ghc-boot-8.7 -package-id ghc-boot-th-8.7 -package-id ghc- heap-8.7 -package-id ghci-8.7 -package-id hpc-0.6.0.3 -package-id integer- gmp-1.0.2.0 -package-id process-1.6.3.0 -package-id template- haskell-2.15.0.0 -package-id terminfo-0.4.1.2 -package-id time-1.9.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wno-name- shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail- instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O -dcore-lint -dno-debug-output -DDEBUG -Wcpp- undef -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir compiler/stage2/build -c compiler/simplCore/Simplify.hs -o compiler/stage2/build/Simplify.p_o -dyno compiler/stage2/build/Simplify.dyn_o compiler/stranal/WwLib.hs:1187:1: error: [-Wunused-top-binds, -Werror =unused-top-binds] Defined but not used: ‘mk_seq_case’ | 1187 | mk_seq_case arg body = Case (Var arg) (sanitiseCaseBndr arg) (exprType body) [(DEFAULT, [], body)] | ^^^^^^^^^^^ compiler/stranal/WwLib.hs:1198:1: error: [-Wunused-top-binds, -Werror =unused-top-binds] Defined but not used: ‘sanitiseCaseBndr’ | 1198 | sanitiseCaseBndr id = id `setIdInfo` vanillaIdInfo | ^^^^^^^^^^^^^^^^ <> make[1]: *** [compiler/ghc.mk:445: compiler/stage2/build/WwLib.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... <> <> <> <> <> <> make: *** [Makefile:128: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 19:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 19:37:22 -0000 Subject: [GHC] #16042: T13031 doesn't get run Message-ID: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> #16042: T13031 doesn't get run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon wrote noting that two tests in `stranal/should_compile` didn't appear to be run in his testing. I have been able to reproduce this. A few observations: * There is a `setTestOpts( only_ways(['optasm']) )` at the top of `stranal/should_compile/test.T` * in a `validate` build `T13031` is skipped when run with: * `make test TEST=T13031 WAY=normal` * `make test TEST=T13031 WAY=optasm` * `make slowtest TEST=T13031 WAY=normal` * `make slowtest TEST=T13031 WAY=optasm` * When the `setTestOpts` call is commented out `T13031` is * skipped with `make test TEST=T13031 WAY=optasm` * run with `make test TEST=T13031 WAY=normal` * `optasm` is in the `config.run_ways` list I suspect what is happening here is that the `optasm` way is not being run To be continued... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 20:25:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 20:25:43 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.7ef076ce66e617a2a22c6d4963a5a8be@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Drat, my fault. I forgot to remove dead code. Patch coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 20:28:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 20:28:53 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.8fd3fdc76763688beaf4e8594d857bcb@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Phab:D5444 #14551 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => make test TESTS="T10857a T10857b" * status: new => patch * differential: => Phab:D5444 * related: #3202, #3217 => #3202, #3217, #14551 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 20:29:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 20:29:59 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.cb7a2d9b63f6877e6bde6df287f5c5ee@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 nh2): * milestone: => 8.8.1 Comment: Is this something that could be tackled for 8.8? Some of the real-world applications we'd really like to upgrade past 8.2 appear to get slower from this. (Tentatively seting milestone) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 20:52:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 20:52:48 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.2de0a79e1563a5ded0a81b8440d646e6@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Doubling sounds bad. There are 9 tests in the repro case. 've lost track of what is what. If someone was able to distil out a simple before-and-after on one test, that would be helpful. Better still, get some insight into what is happening. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 20:58:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 20:58:36 -0000 Subject: [GHC] #16029: Inadequate absence analysis In-Reply-To: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> References: <046.b6f13d2e79eba96c9e708dbe0e044dea@haskell.org> Message-ID: <061.52814534abaa6d0423ed4a19055c97c3@haskell.org> #16029: Inadequate absence analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_compile/T16029 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => stranal/should_compile/T16029 * resolution: => fixed Comment: Fixed, but the test isn't being run -- see Trac #16042 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 21:19:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 21:19:42 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple Message-ID: <046.cea639b79d893836083fb857e93f8b61@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Numerous testsuite tests assume that we are using `integer-gmp`. This assumption mostly arises due to the lack of support for `integer-simple` `Integer`s in `RtClosureInspect.cPprTermBase`, causing many GHCi tests to break. I have marked these as broken to make progress on #15915. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 21:19:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 21:19:53 -0000 Subject: [GHC] #16044: Transition to C11 memory model Message-ID: <043.054a438919fd40e60f8103a09032ee12@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 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: -------------------------------------+------------------------------------- Following offline discussion with Ben Gamari and [https://mail.haskell.org/pipermail/ghc-devs/2018-November/016581.html Cmm Memory Model thread on ghc-devs@], I would like to propose to gradually transition RTS and Cmm to C11 memory model. There are multiple benefits: 1) Correctness: C11 atomics are properly specified and are easier to reason about than the existing SMP.h barriers. 2) Performance: compilers can optimize and generate better code for C11 atomics. For example, on ARMv8 acquire/release operations use specialized LDA/STL instructions. 3) Tooling support: once all code transitions to C11 atomics, tools like ThreadSanitizer can be used to find subtle data races. To make sure that code continues to compile with old compilers (pre C11), I plan to introduce wrapper functions (acquire_load, release_store, etc.) that are implemented either using C11 atomics or SMP.h barriers depending on the STDC_VERSION. Here is a [https://github.com/ulan/ghc/commit/0e8822a8038c3d0c770f4582c8f65b20d7823769 prototype implementation]. The idea is that newly written code should use the wrappers and we can gradually update the existing code. I think updating C code in RTS would work with this approach, but I am not sure about Cmm. Please let me know if you see potential issues, a better way to implement it, or oppose moving to C11 memory model. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 21:42:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 21:42:29 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.3a673ea813f6e6645e4426c253cb04da@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:3 simonpj]: > There are 9 tests in the repro case. I've lost track of what is what. If someone was able to distil out a simple before-and-after on one test This part I can answer immediately: I use only `./TraverseMaybePerformance 8` in the issue description, so that's `test8` form the repro. But yes, a smaller test case will make things easier. Here it is: {{{ #!/usr/bin/env stack -- stack --resolver lts-11.22 script --optimize -- The above one is fast. Slow is: -- stack --resolver lts-12.11 script --optimize {-# OPTIONS_GHC -Wall #-} import Control.Concurrent (yield) import Control.Monad (when) import qualified Data.Text.Lazy as T import qualified Data.Foldable as F myfor_ :: (Foldable f, Applicative app) => f a -> (a -> app ()) -> app () myfor_ t f = case F.toList t of [] -> pure () x -> go x where go [x] = f x go (x:xs) = f x *> go xs printChars_myfor_ :: Int -> T.Text -> IO () printChars_myfor_ idx t = myfor_ (T.uncons t) $ \(c, t') -> do when (idx `mod` 100000 == 0) $ do -- Using putStrLn, I observe 2x more allocations with GHC 8.4.3 vs 8.2.2 (860 vs 460 M) --putStrLn $ "Character #" ++ show idx ++ ": " ++ show c -- Using yield, I observe 4x more allocations with GHC 8.4.3 vs 8.2.2 (860 vs 220 M) yield -- the putStrLn isn't necessary, this is enough to trigger the regression printChars_myfor_ (idx + 1) t' main :: IO () main = printChars_myfor_ 1 $ T.replicate 5000000 $ T.singleton 'x' }}} I even managed to make the regression 4x worse using `yield`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 12 23:24:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Dec 2018 23:24:06 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.820cf95e59c44bbc634a07158f583b78@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: Thank you for doing this, Ulan! CCing Simon Marlow, who I have also discussed this briefly with at a ICFP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 02:40:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 02:40:23 -0000 Subject: [GHC] #16036: expDouble## 0.0## doesn't get complied into 1.0## In-Reply-To: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> References: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> Message-ID: <062.b00f448ea568dc5454536e6319abb3cc@haskell.org> #16036: expDouble## 0.0## doesn't get complied into 1.0## -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Fuuzetsu): In LLVM source I see {{{ case 'e': if ((Name == "exp" && TLI->has(LibFunc_exp)) || (Name == "expf" && TLI->has(LibFunc_expf)) || (Name == "__exp_finite" && TLI->has(LibFunc_exp_finite)) || (Name == "__expf_finite" && TLI->has(LibFunc_expf_finite))) return ConstantFoldFP(exp, V, Ty); }}} So maybe it's fine? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 03:00:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 03:00:46 -0000 Subject: [GHC] #16045: improve dwarf support on OSX Message-ID: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> #16045: improve dwarf support on OSX --------------------------------------+--------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: --------------------------------------+--------------------------------- currently 1) we dont have stack unwinding support on OSX (libDwarf is ELF format only) 2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is set , but not when g0 is set. that is, even if we had a macho unwinding library for use with GHC, currently we can't even unwind base if we wanted to 3) currently the stgcrun.c code for darwin/unix envs when build on OSX, can't be built with GCC, because of some mismatch in how llvm vs gcc flavored tools on osx handle dwarf. This means this file, IF we had unwinding support, would need to be built with clang (apple or llvm flavored). 3 a)HOWEVER: on OSX the threaded RTS (when built with clang) is ~15% slower than the same built with GCC. 3 b) so ideally, in a future world with unwinding on OSX, tweaking the build system to make sure that the STGCRUN.c code it always built with clang, or some other fix, that still permits a GCC built RTS OR otherwise does a fix to that GC rts perf issue, would be ideal Theres a few different action items here, and some of them are quite messy, but they all need to be done for decent perf and debugging experiences on OSX to be in the GHC future! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 03:03:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 03:03:28 -0000 Subject: [GHC] #16045: improve dwarf support on OSX In-Reply-To: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> References: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> Message-ID: <060.bd542c58cddd9554687c53230af0ccf5@haskell.org> #16045: improve dwarf support on OSX ---------------------------------+-------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 carter): the near term fix is to disable the dwarf annnotations in stgcrun.c so that the CI distro builds can have the nice RTS, when built on OSX with GCC (we should still test the clang + info path). longer term: we need to understand if theres a way to work around the section limits when base is built with -g1 / g2/ g3 with the machO object format. one option might be use dsym files instead of putting the data in the object files? lots to poke at to understand whats going on and if its an llvm/apple bug, a fundamental macho dwarf issue given the current macho object format, or if we just need to be more clever on OSX / macho targets longer long term: find a macho dwarf unwindingin stack walker code base we like! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:27:06 -0000 Subject: [GHC] #16037: memcpy test inexplicably failing In-Reply-To: <046.e148bae4ac1874a30d669ba5b5d04e9c@haskell.org> References: <046.e148bae4ac1874a30d669ba5b5d04e9c@haskell.org> Message-ID: <061.dc1e3c2eeb42afee1b4d99a32039bbe7@haskell.org> #16037: memcpy test inexplicably failing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"251db9799ad64d36640d388617da8cf793c98240/ghc" 251db979/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="251db9799ad64d36640d388617da8cf793c98240" testsuite: Try accepting new output for memcpy test See #16037. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:27:06 -0000 Subject: [GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation In-Reply-To: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> References: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> Message-ID: <061.5bc9ba3bb748f3adc9fb29603a61489d@haskell.org> #15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5299 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"efb6a30f0b70948ba51497bf2831e009ec6e1378/ghc" efb6a30f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efb6a30f0b70948ba51497bf2831e009ec6e1378" Fix recompilation checking of pure plugins Previously when switching from using a Plugin with `RecompMaybe`/`ForceRecompile` in `pluginRecompile` to a Plugin with `NoForceRecompile` GHC would never even consider recompiling. However the previously active plugin could have modified the compilation output so we should recompile. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15858 Differential Revision: https://phabricator.haskell.org/D5299 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:27:06 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.1866cf3507b0190a6c0c66b3df488c57@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"14500dab3e9c24d2701c8be6f5a0fca30531ab80/ghc" 14500da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14500dab3e9c24d2701c8be6f5a0fca30531ab80" testsuite: Fix a number of GHCi-related failures due to integer-simple Towards fixing #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:27:06 -0000 Subject: [GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler. In-Reply-To: <052.9187b36966727d1f3848569f633777f2@haskell.org> References: <052.9187b36966727d1f3848569f633777f2@haskell.org> Message-ID: <067.87e52a1c831c84a18891210436883c79@haskell.org> #16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0d7fb471f368237462c700bac5500a90d29a1114/ghc" 0d7fb47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d7fb471f368237462c700bac5500a90d29a1114" configure: Disable LD_NO_GOLD logic when cross-compiling This is generally terrible: see #16025. In short, we previously just blindly used an un-prefixed ld for LD_NO_GOLD. This is blatantly wrong. Ideally we would actually verify that ld.gold is indeed broken (by binutils #22266) before insisting on using another linker but sadly we cannot do so when cross- compiling since this would require running host code. For now we simply disable the LD_NO_GOLD logic when cross-compiling and hope that the user has verified that their ld.gold isn't affected by #22266. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:27:06 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.1dbccec476c615a20c541c70acff81f7@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"cd4477c9137d6df8dfc00d66d54900d45f047af9/ghc" cd4477c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd4477c9137d6df8dfc00d66d54900d45f047af9" testsuite: Normalise away package name differences from safePkg01 Spurious changes observed in a integer-simple build. In service of #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:27:06 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.7440dafaf68c3908b330f1e86a5e9944@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"9d9f4c9a7c04e152b40ae2db7c051cd9e0f5df61/ghc" 9d9f4c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d9f4c9a7c04e152b40ae2db7c051cd9e0f5df61" testsuite: Normalise away spurious differences in out-of-scope instances This fixes a variety of testsuite failures with integer-simple of the form ``` --- typecheck/should_fail/tcfail072.run/tcfail072.stderr.normalised +++ typecheck/should_fail/tcfail072.run/tcfail072.comp.stderr.normalised @@ -12,7 +12,7 @@ -- Defined in ‘integer--:GHC.Integer.Type’ instance Ord () -- Defined in ‘GHC.Classes’ ...plus 21 others - ...plus three instances involving out-of-scope types + ...plus two instances involving out-of-scope types (use -fprint-potential-instances to see them all) In the expression: g A In an equation for ‘g’: g (B _ _) = g A ``` In service of fixing #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:56:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:56:36 -0000 Subject: [GHC] #16042: T13031 doesn't get run In-Reply-To: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> References: <046.e1b71aade95a570ef33733cdb590f152@haskell.org> Message-ID: <061.4c362fc22e95e7f25435878e605f298d@haskell.org> #16042: T13031 doesn't get run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): I see the problem. In `test_common_work` we have, {{{ def test_common_work(watcher, name, opts, func, args): try: t.total_tests += 1 setLocalTestOpts(opts) package_conf_cache_file_start_timestamp = get_package_cache_timestamp() # All the ways we might run this test if func == compile or func == multimod_compile: all_ways = config.compile_ways elif func == compile_and_run or func == multimod_compile_and_run: all_ways = config.run_ways elif func == ghci_script: if 'ghci' in config.run_ways: all_ways = ['ghci'] else: all_ways = [] else: all_ways = ['normal'] ... }}} and we then look at `all_ways` to determine whether the test is supposed to run. When I call `make slowtest TEST=T13031 WAY=optasm` I find that `all_ways` is `['normal']` yet `getTestOpts().only_ways` is `['optasm']`. Consequently I suspect the problem here is that `T13031` is hits the `else` case of the `if`, being a `run_command` test. The simplest fix for this would be to simply drop the `only_way` modifier on the test. However, I worry that issue this will inevitably recur elsewhere. I'm going to sleep on it to see what we can do to improve this situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:57:21 -0000 Subject: [GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler. In-Reply-To: <052.9187b36966727d1f3848569f633777f2@haskell.org> References: <052.9187b36966727d1f3848569f633777f2@haskell.org> Message-ID: <067.8310848649baa841a97543681844c2cf@haskell.org> #16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (make) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:58:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:58:58 -0000 Subject: [GHC] #16037: memcpy test inexplicably failing In-Reply-To: <046.e148bae4ac1874a30d669ba5b5d04e9c@haskell.org> References: <046.e148bae4ac1874a30d669ba5b5d04e9c@haskell.org> Message-ID: <061.c83c8d845bfa0b01f63deaad1c4f830b@haskell.org> #16037: memcpy test inexplicably failing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have accepted the new output but would really like to understand why this changed. I believe the change arose somewhere between 856dd66fc9c6416b2f62c8f2ac8bb61f4a48b859 and 65fb69b78f4850b56ee6a2655bc5dc6c441a984e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 04:59:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 04:59:43 -0000 Subject: [GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation In-Reply-To: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> References: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> Message-ID: <061.d31d5f840c1e809f4cd7212486d2f78e@haskell.org> #15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5299 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 05:26:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 05:26:46 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.92150c7f9ba750ce6ab1a7bb8e9bd0c5@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) * differential: => Phab:D5438 Comment: Thanks for doing this! I think running the benchmarks multiple times is a good idea. That's what `criterion` does, and it provides quite reliable results, even for very fast programs. That said, looking at the patch and your `paraffins` example, I have some questions: - I wonder if it'd be better to run the process multiple times, instead of running the `main` function multiple times in the program. Why? That way we know GHC won't fuse or somehow optimize the `replicateM_ 100` call in the program, and we properly reset all the resources/global state (both the program's and the runtime system's, e.g. weaks pointers, threads, stable names). It just seems more reliable. - Of course this would make the analysis harder as each run will print GC stats which we need to parse and somehow combine ... - That said, I wonder if GC numbers are important for the purposes of nofib. In nofib we care about allocations and runtimes, as long as these numbers are stable it should be fine. So perhaps it's not too hard to repeat the process run instead of `main` function. - You say "GC wibbles", but I'm not sure if these are actually GC wibbles. I just checked paraffins: it doesn't do any IO (other than printing the results), and it's not even threaded (does not use threaded runtime, does not do `forkIO`). So I think it should be quite deterministic, and I think any wibbles are due to OS side of things. In other words, if we could have an OS that only runs `paraffins` and nothing else I think the results would be quite deterministic. Of course this doesn't change the fact that we're getting non- deterministic results and we should do something about it, I'm just trying to understand the root cause here. On my first point: if a solution for benchmarking "processes" (instead of "functions") using criterion-style iteration (by which I mean "provides stable results") I think it may worth trying. Few years back we used `hsbencher` for this purpose at IU, but IIRC it's a bit too heavy (lots of dependencies), and it seems unmaintained now. I vaguely recall another program for this purpose but I can't remember the name... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 05:44:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 05:44:19 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.f6905ee2d9f1c37a502b18ba34ec145b@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm also wondering if having a fixed iteration number is a good idea. What if, in 5 years, 100 iterations for paraffins is not enough to get reliable numbers? I think `criterion` also has a solution for this (it does different number of repetitions depending on results). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 08:40:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 08:40:11 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.5602f2407e40e987016eaebd27b0204a@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 08:42:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 08:42:49 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.c3199b9cb986b6ab5a3eb4e7c2541f98@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 08:44:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 08:44:13 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.c930ad5df4658614320d757d4a83d8d3@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 09:02:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 09:02:15 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.67d5eca4b6e67e989e68ae3421c0c81f@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. For `test1` (the fast one) we get {{{ Rec { $wgo_r2xK :: GHC.Prim.Int# -> GHC.Prim.Int# $wgo_r2xK = \ (ww_s2w4 :: GHC.Prim.Int#) -> case GHC.Prim.># ww_s2w4 0# of { __DEFAULT -> ww_s2w4; 1# -> $wgo_r2xK (GHC.Prim.-# ww_s2w4 1#) } end Rec } T16040.$wtest1 :: GHC.Prim.Int# -> GHC.Prim.Int# T16040.$wtest1 = \ (ww_s2wd :: GHC.Prim.Int#) -> $wgo_r2xK ww_s2wd test1 :: Int -> Int test1 = \ (w_s2wa :: Int) -> case w_s2wa of { GHC.Types.I# ww1_s2wd -> case T16040.$wtest1 ww1_s2wd of ww2_s2wh { __DEFAULT -> GHC.Types.I# ww2_s2wh } } }}} Notice that loop `$wgo` does not allocation at all. For `test2` we get {{{ Rec { $wgo1_r2xL :: GHC.Prim.Int# -> (# Int #) $wgo1_r2xL = \ (ww_s2wm :: GHC.Prim.Int#) -> case GHC.Prim.># ww_s2wm 0# of { __DEFAULT -> (# GHC.Types.I# ww_s2wm #); 1# -> $wgo1_r2xL (GHC.Prim.-# ww_s2wm 1#) } end Rec } T16040.$wtest2 :: GHC.Prim.Int# -> Int T16040.$wtest2 = \ (ww_s2wv :: GHC.Prim.Int#) -> case $wgo1_r2xL ww_s2wv of { (# ww2_s2wy #) -> ww2_s2wy } test2 :: Int -> Int test2 = \ (w_s2ws :: Int) -> case w_s2ws of { GHC.Types.I# ww1_s2wv -> T16040.$wtest2 ww1_s2wv } }}} Here the `$wgo1` loop does no allocation on its hot path, but does allocate an `I# ww` box as it returns. I think that `$wgo1` is doing a heap-check on ''every'' iteration, at the start of the function. It would be better to do the check only on the ''last'' iteration, in the `DEFAULT` branch. I bet these redundant heap checks are what is taking the time. We have long-standing tickets about this; see the summary in comment:2 of Trac #14791. I would love someone to work on this. To catch cases like this should not be very hard. By "like this" I mean * A primitive case * Which has no allocation "upstream" (i.e. before it) * And at least one alternative does no allocation. ---------- Matthew is right that Nested CPR would also fix this. The trouble is that the recursive `go` from `test2` returns an `X Int`, whose representation has two levels of box; eg `X (I# 3#)`. The current CPR transform can't optimise that. Nested-CPR can, and would make ''neither'' branch of `$wgo2` allocate Tantalizingly, we have a nested-cpr patch nearly ready to go. (See Trac #1600.) But it needs someone to pay it some sustained attention. ---------- I don't see an obvious band-aid. This is a long-standing issue, not a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 09:12:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 09:12:13 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.dfbc9a15bf965f50d900220b72a7648b@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Here's a library that can be useful for this purpose: http://hackage.haskell.org/package/bench -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 09:35:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 09:35:41 -0000 Subject: [GHC] #15843: Tuple sections can't be quoted In-Reply-To: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> References: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> Message-ID: <064.c82cbcdfdc66602830a5038a48f024c9@haskell.org> #15843: Tuple sections can't be quoted -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer, | TemplateHaskell 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: > There are quite a few forms that are not supported in template haskell > quotes. It seems that it would be at least a good warm up patch to add > support for tuple sections which you can do simply by desugaring to a > lambda and the normal tuple constructor. > > {{{ > {-# LANGUAGE TemplateHaskell #-} > {-# LANGUAGE TupleSections #-} > module Foo where > > foo = [|| (,5) ||] > }}} > > 1. Modify `DsMeta.repE` to handle tuple sections. You can desugar `(,5) > => `\x -> (x, 5)`. > 2. Add the above test to the test suite. New description: There are quite a few forms that are not supported in template haskell quotes. It seems that it would be at least a good warm up patch to add support for tuple sections which you can do simply by desugaring to a lambda and the normal tuple constructor. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TupleSections #-} module Foo where foo = [|| (,5) ||] }}} 1. Modify `DsMeta.repE` to handle tuple sections. You can desugar `(,5) => \x -> (x, 5)`. 2. Add the above test to the test suite. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 09:47:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 09:47:05 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.e738c2eb15056ad3172732553868b90d@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:2 osa1]: > - I wonder if it'd be better to run the process multiple times, instead of > running the `main` function multiple times in the program. Why? That way we > know GHC won't fuse or somehow optimize the `replicateM_ 100` call in the > program, and we properly reset all the resources/global state (both the > program's and the runtime system's, e.g. weaks pointers, threads, stable > names). It just seems more reliable. The whole point of this patch is that we iterate ''within'' the process, so that GC paramerisation doesn't affect performance (counted instructions, even) on the same program in 'unforeseen' ways, like the discontinuous, non-monotonic paraffins example. There we would expect that increasing nursery always leads to higher productivity, because the GC has to run less often. That clearly isn't the case, due to effects outlined in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38. My hypothesis here is that fixing the productivity curve above has the following effect on benchmarking a patch that changes allocations: Basically, we fix the GC paramerisation and vary allocations instead of fixing allocations and varying GC parameters. For a fixed GC parameterisation (which is always the case when running NoFib), we would expect an optimisation that reduces allocations by 10% to lead to less GC time, thus higher productivity. Yet, in https://ghc.haskell.org/trac/ghc/ticket/9476#comment:55, there is a regression in total allocations by 18.6%, while counted instructions improve by 11.7% (similar results when measuring actual runtime). As the thread reveals, I had to do quite some digging to find out why (https://ghc.haskell.org/trac/ghc/ticket/9476#comment:71): The program produces more garbage, leading to more favorable points at which GC is done. We don't want that to dilute our comparison! This is also the reason why iterating the same program by restarting the whole process is impossible: GC paramerisation is deterministic (rightly so, IMO) and restarting the process will only measure the same dilusion over and over. On the other hand, iterating the logic $n times from within the program leads to different GC states at which the actual benchmark logic starts, thus leading to a more uniform distribution at the points in the program when GC happens. For every benchmark in the patch, I made sure that `replicateM_ 100` is actually a sensible thing to do. Compare that to the current version of [https://github.com/ghc/nofib/blob/f87d446b4e361cc82f219cf78917db9681af69b3/spectral/awards/Main.hs#L68 awards] where that is not the case: GHC will float out the actual computation and all that is measured is `IO`. In paraffins I used `relicateM_ 100` (or `forM_ [1..100] $ const`, rather, TODO), because the inner action has a call to `getArgs`, the result of which is used to build up the input data. GHC can't know that the result of `getArgs` doesn't change, so it can't memoize the benchmark result and this measures what we want. In other cases I actually had to use `forM_` and make use of the counter somewhere in generating the input data. > - You say "GC wibbles", but I'm not sure if these are actually GC wibbles. I > just checked paraffins: it doesn't do any IO (other than printing the > results), and it's not even threaded (does not use threaded runtime, does not > do `forkIO`). So I think it should be quite deterministic, and I think any > wibbles are due to OS side of things. In other words, if we could have an OS > that only runs `paraffins` and nothing else I think the results would be quite > deterministic. > > Of course this doesn't change the fact that we're getting non- deterministic > results and we should do something about it, I'm just trying to understand the > root cause here. The numbers are deterministic, but they are off in the sense above. By GC wibble, I mean that varying tiny parameters of the program or the GC has huge, non-monotonic, 'discontinuous' impact on the perceived performance, which makes the benchmark suite unsuited to evaluate any optimisation that changes allocations. Replying to [comment:3 osa1]: > I'm also wondering if having a fixed iteration number is a good idea. What if, > in 5 years, 100 iterations for paraffins is not enough to get reliable numbers? > I think `criterion` also has a solution for this (it does different number of > repetitions depending on results). The point of iterating 100 times is not to adjust runtime so that we measure something other than System overhead (type 1 in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38). It's solely to get smoother results in the above sense. There's still the regular fast/norm/slow mechanism which are there to tune for specific runtimes, which are quite likely to vary in the future. Of course, we could just as well increment 100 to 243 for even smoother results instead of modifying the actual input problem. But having it fixed means that the curve for fast is as smooth as slow, which is a good thing, I think. It means we can measure counted instructions on fast without having to worry too much about said dilusions. Replying to [comment:4 osa1]: > Here's a library that can be useful for this purpose: http://hackage.haskell.org/package/bench Ah, yes. That could indeed be worthwhile as a replacement for the current runner, but only if it would support measuring more than just time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 10:04:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 10:04:59 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.a5a2657f2aa34b6ba842e4bd2bcfea65@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): So as I understand it, the GC "wibbles" you're talking about are caused by the number of GCs we run? Making a small change to the nursery size can make the difference between N and N+1 GC runs, which could be a large difference in runtime. You're only looking at `-G1`, right? Generational GC often has weird effects based on the timing of when a GC runs. I think there will still be issues when there's an old-gen collection right around the end of the program run - making a small change may mean the difference between running or not running the expensive GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 10:18:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 10:18:02 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.5db3f463500f261eb5f5902f3c8cc337@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:6 simonmar]: > So as I understand it, the GC "wibbles" you're talking about are caused by the number of GCs we run? Making a small change to the nursery size can make the difference between N and N+1 GC runs, which could be a large difference in runtime. Yes, that's one source of wibble (in hindsight, that may have been a bad term to use here). But it's not exactly the reason why I'm doing this: Have a look at the numbers in https://ghc.haskell.org/trac/ghc/ticket/9476#comment:55. The `./default` had significantly fewer Gen 0 collections and the same number of Gen 1 collections as `./allow-cg` (which produces more garbage but is faster in total). Gen 1 collections where cheaper for `./allow-cg` for some reason. Also note how this correlates with the productivity rate: 10% vs 15% for the latter. The findings in the thread led me to plot the above curves. > > You're only looking at `-G1`, right? Generational GC often has weird effects based on the timing of when a GC runs. I think there will still be issues when there's an old-gen collection right around the end of the program run - making a small change may mean the difference between running or not running the expensive GC. This is not `-G1` and I agree that a single old-gen collection might make the difference. But when we modify the program in a way that there are ''more'' Gen 1 collections, at more uniformly distributed points in the program, I argue we will have a much better experience comparing nofib numbers. There are multiple ways to achieve this, but I think the simplest one is what I outline above and more closely corresponds to the workload of real applications (e.g. long running time, growing and shrinking working sets). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 10:20:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 10:20:39 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.25cc26f208440783fe952e34db9679c8@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 nh2): * Attachment "TraverseMaybePerformanceSimplified-GHC-bug-15717-GHC-8.2.2 .dump-simpl" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 10:20:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 10:20:54 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.f5ff9b6f45fcab5f49dd7971a0ae3c16@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 nh2): * Attachment "TraverseMaybePerformanceSimplified-GHC-bug-15717-GHC-8.4.3 .dump-simpl" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 11:54:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 11:54:32 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.07fb5e96331448131e4f0d8a5200862a@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): Thank you for the detailed explanation, Simon! I took a look at the core but missed seeing the allocation previously. Regarding fixing this or CPR, would nested CPR fix all cases 'like this', as you put it, or even if the nested CPR patch lands would there still be a need for functionality to catch cases like this? The reason I ask is that I'd be quite willing to take a look at either over the holiday in some free time, assuming I can find some guidance, and I'm wondering which would be best to attack. Regarding the nested-cpr patch, what kind of attention is needed? Do you think that, ''with'' said attention it could be landed for 8.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 13:27:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 13:27:44 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.3fd1f3c86f2102d174201baf14121e0e@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): I have a one-liner patch that now correctly judges `ghc- prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind` as not-worth-for- floating, but I have found another context (floating of specialised class dicts) when this is not enough. To diagnose this, I have instrumented my stage2 with traces and get (while compiling `TcHsType.hs`) : {{{ lvlMFE WORTH (noinline @ (HasDebugCallStack => Role -> TyCon -> [Coercion] -> Coercion) mkTyConAppCo C:(%%), noinline @ (Coercion -> Coercion -> Coercion) mkAppCo, noinline @ (CoAxiom Branched -> BranchIndex -> [Coercion] -> Coercion) mkAxiomInstCo, noinline @ (UnivCoProvenance -> Role -> Type -> Type -> Coercion) mkUnivCo, noinline @ (Coercion -> Coercion) mkSymCo, noinline @ (Coercion -> Coercion -> Coercion) mkTransCo, noinline @ (HasDebugCallStack => Role -> Int -> Coercion -> Coercion) mkNthCo C:(%%), noinline @ (LeftOrRight -> Coercion -> Coercion) mkLRCo, noinline @ (Coercion -> Coercion -> Coercion) mkInstCo, noinline @ (Coercion -> Coercion) mkKindCo, noinline @ (Coercion -> Coercion) mkSubCo, noinline @ (TyCoVar -> Coercion -> Coercion -> Coercion) mkForAllCo, noinline @ (Role -> Type -> MCoercionN -> Coercion) mkGReflCo) lvlMFE WORTH noinline @ (HasDebugCallStack => Role -> TyCon -> [Coercion] -> Coercion) mkTyConAppCo C:(%%) lvlMFE NOTWORTH mkTyConAppCo lvlMFE NOTWORTH C:(%%) lvlMFE NOTWORTH noinline @ (Coercion -> Coercion -> Coercion) mkAppCo lvlMFE NOTWORTH mkAppCo lvlMFE NOTWORTH noinline @ (CoAxiom Branched -> BranchIndex -> [Coercion] -> Coercion) mkAxiomInstCo lvlMFE NOTWORTH mkAxiomInstCo lvlMFE NOTWORTH noinline @ (UnivCoProvenance -> Role -> Type -> Type -> Coercion) mkUnivCo lvlMFE NOTWORTH mkUnivCo lvlMFE NOTWORTH noinline @ (Coercion -> Coercion) mkSymCo lvlMFE NOTWORTH mkSymCo lvlMFE NOTWORTH noinline @ (Coercion -> Coercion -> Coercion) mkTransCo lvlMFE NOTWORTH mkTransCo lvlMFE WORTH noinline @ (HasDebugCallStack => Role -> Int -> Coercion -> Coercion) mkNthCo C:(%%) lvlMFE NOTWORTH mkNthCo lvlMFE NOTWORTH C:(%%) lvlMFE NOTWORTH noinline @ (LeftOrRight -> Coercion -> Coercion) mkLRCo lvlMFE NOTWORTH mkLRCo lvlMFE NOTWORTH noinline @ (Coercion -> Coercion -> Coercion) mkInstCo lvlMFE NOTWORTH mkInstCo lvlMFE NOTWORTH noinline @ (Coercion -> Coercion) mkKindCo lvlMFE NOTWORTH mkKindCo lvlMFE NOTWORTH noinline @ (Coercion -> Coercion) mkSubCo lvlMFE NOTWORTH mkSubCo lvlMFE NOTWORTH noinline @ (TyCoVar -> Coercion -> Coercion -> Coercion) mkForAllCo lvlMFE NOTWORTH mkForAllCo lvlMFE NOTWORTH noinline @ (Role -> Type -> MCoercionN -> Coercion) mkGReflCo lvlMFE NOTWORTH mkGReflCo }}} Here `noinline @ (Role -> Type -> MCoercionN -> Coercion) mkGReflCo` is considered NOTWORTH for floating, but even with that the algorithm descends into it, and eventually the expression gets floated. I have to figure out why this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 13:52:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 13:52:42 -0000 Subject: [GHC] #16045: improve dwarf support on OSX In-Reply-To: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> References: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> Message-ID: <060.82e6f5044ae3c21bae9f0dfc28669d9e@haskell.org> #16045: improve dwarf support on OSX ---------------------------------+-------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 13:53:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 13:53:48 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.4bf76b24086c0e678b1559fd97f185d1@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 14:21:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 14:21:20 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.17d6d5b26b478bd4c344bc580d0c691a@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's another way to trigger (what I believe to be) the same issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where import Data.Kind type KindOf (a :: k) = k data T :: forall j (a :: j). KindOf a -> Type where MkT :: forall k (b :: k). T b }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Tidy Core *** : warning: In the type ‘forall (a :: k_aVT[sk:1]) k (b :: k). T b’ @ k_aVT[sk:1] is out of scope *** Offending Program *** $WMkT [InlPrag=INLINE[2]] :: forall (a :: k_aVT[sk:1]) k (b :: k). T b [GblId[DataConWrapper], Caf=NoCafRefs, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True) Tmpl= \ (@ (a_aWw :: k_aVT[sk:1])) (@ k_XVV) (@ (b_aVU :: k_XVV)) -> MkT @ k_XVV @ a_aWw @ b_aVU}] $WMkT = \ (@ (a_aWw :: k_aVT[sk:1])) (@ k_XVV) (@ (b_aVU :: k_XVV)) -> MkT @ k_XVV @ a_aWw @ b_aVU *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 14:28:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 14:28:53 -0000 Subject: [GHC] #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 In-Reply-To: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> References: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> Message-ID: <065.ae2bd5b068f65964b317eca248c3720b@haskell.org> #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This bug also affects rank-//n// //contexts// as well, as the following typechecks in GHC 8.4.4 and earlier, but not in GHC 8.6.3: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where f :: (forall a. a -> Show a => c) -> () f (x :: forall a. a -> Show a => c) = () }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:4: error: • Couldn't match type ‘c1’ with ‘Show a => c’ ‘c1’ is a rigid type variable bound by the type signature for: f :: forall c1. (forall a. a -> Show a => c1) -> () at Bug.hs:6:1-42 Expected type: a -> Show a => c Actual type: a -> c1 • When checking that the pattern signature: forall a. a -> Show a => c fits the type of its context: forall a. a -> Show a => c1 In the pattern: x :: forall a. a -> Show a => c In an equation for ‘f’: f (x :: forall a. a -> Show a => c) = () • Relevant bindings include f :: (forall a. a -> Show a => c1) -> () (bound at Bug.hs:7:1) | 7 | f (x :: forall a. a -> Show a => c) = () | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 14:42:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 14:42:35 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.b682d17b58bf9b68c079fa749a842a88@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 simonmar): What would it mean for Cmm to use the C11 memory model? Do you imagine having new atomic types, and adding all the C11 atomic operations to MachOp? What about the memory order stuff? My understand is that since GHC compiles Cmm to native code, the implementation of the memory model would entail inserting barriers in the appropriate places according to the target architecture. So we still need the barriers, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 15:27:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 15:27:32 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.c257c850f13cf11b5ff2a1f58553e0f4@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 ulan): [re-entering my reply via Trac UI as my email reply was not picked up] That's a good question. I am not sure what would be the best approach for Cmm. I am thinking about extending the existing atomic MachOps (MO_AtomicRead, MO_AtomicWrite, etc) with the memory order that would be similar to LlvmSyncOrdering. Then compiling to LLVM would be straightforward. For other backends, we indeed would have to provide architecture specific implementation of the atomics ops (e.g. https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 15:35:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 15:35:44 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.8d009cbd46b2867b430d6c19906349fb@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the underlying point is that you want `(noinline f)` to be treated very like `f`, for many purposes. Because it'll turn ''into'' `f` in `CorePrep`. Particularly, I think you want `exprIsTrivial` to be true of it. So maybe instead of {{{ exprIsTrivial (App e arg) = not (isRuntimeArg arg) && exprIsTrivial e }}} you want {{{ exprIsTrivial (App e arg) | not (isRuntimeArg arg) = exprIsTrivial e | App (Var f) _ <- e, isInlineId f = exprIsTrivial arg | otherwise = False }}} Not very nice, and it's possible that other functions may need similar treatment. But nothing better jumps out at me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 15:36:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 15:36:35 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.6b96cd0a8a3d0807214c5b4f84e53a61@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Have you made any progress on this, or should I pick it up (I will have the bandwidth for this soon) ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 15:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 15:40:42 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.0ccced85995cad30784c7cdabaebf90d@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Regarding fixing this or CPR, would nested CPR fix all cases 'like this', as you put it, or even if the nested CPR patch lands would there still be a need for functionality to catch cases like this? I think we want ''both'' nested CPR ''and'' better placement of heap checks. They do different things -- it just so happens that in this case either would solve it. Great that you can work on it. I'd suggest the heap-check placement one, because it's a well-contained problem, I think. Nested CPR may have a longer on-ramp. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 16:01:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 16:01:48 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.0479fdd880314472373b31788c26ff44@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Thanks, I did not have this `exprIsTrivial` change on my radar yet. So far I have: {{{#!hs notWorthFloating e abs_vars = go e (count isId abs_vars) where go (Var {}) n = n >= 0 go (Lit lit) n = ASSERT( n==0 ) litIsTrivial lit -- Note [Floating literals] go (Tick t e) n = not (tickishIsCode t) && go e n go (Cast e _) n = go e n go (App e arg) n | Type {} <- arg = go e n | Coercion {} <- arg = go e n | App (Var v) Type {} <- e -- added clause , v `hasKey` noinlineIdKey , is_triv arg = True | n==0 = False | is_triv arg = go e (n-1) | otherwise = False }}} `interestingDict` might need a similar treatment too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 16:52:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 16:52:59 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS In-Reply-To: <052.23d28fc3421f1bb560c819068174239d@haskell.org> References: <052.23d28fc3421f1bb560c819068174239d@haskell.org> Message-ID: <067.ed36b4fbb1f759d0be33aa7583effa2f@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: KQueue, | oneshot, parallel build Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 16:59:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 16:59:21 -0000 Subject: [GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter In-Reply-To: <046.07a20fc376700f524edfc9f92497a641@haskell.org> References: <046.07a20fc376700f524edfc9f92497a641@haskell.org> Message-ID: <061.4c6893842a6a5e50760057e319909a4a@haskell.org> #16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5447 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 17:09:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 17:09:15 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.2b96429c183a2558d9b0927ac3351ccc@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): “You think” - sounds promising! But yes if both are going to be useful then I think I’ll try my hand at the heap-check placemement one when I next find some time! It sounds like a decently well-contained problem, and I’ve been meaning to contribute more than just filing tickets for a while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 17:17:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 17:17:06 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.1fe671c0ed4e2e9a60b9839cebd8fbdc@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | 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 lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 17:26:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 17:26:22 -0000 Subject: [GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channel type In-Reply-To: <045.421d1478a12507075d7ed757b0375422@haskell.org> References: <045.421d1478a12507075d7ed757b0375422@haskell.org> Message-ID: <060.9389b257c9930cfad73202335364b9fb@haskell.org> #15267: Extend TVar/MVar to N capacity / Add primitive channel type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.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 lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 17:42:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 17:42:52 -0000 Subject: [GHC] #15485: GHC uses 300% CPU when calling into blocking C call In-Reply-To: <047.13adf0146883a7a0c2f9dc50bb228513@haskell.org> References: <047.13adf0146883a7a0c2f9dc50bb228513@haskell.org> Message-ID: <062.ce6cffd0f4cd75a46891d6ddf733c889@haskell.org> #15485: GHC uses 300% CPU when calling into blocking C call -------------------------------------+------------------------------------- Reporter: oconnore | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 17:59:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 17:59:13 -0000 Subject: [GHC] #15774: SIGKILL only reports backtrace for one capability In-Reply-To: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> References: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> Message-ID: <061.a72ebc2092c652357bace05be8f05f85@haskell.org> #15774: SIGKILL only reports backtrace for one capability -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lelf): Surely you meant SIGQUIT -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 18:00:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 18:00:31 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.bd22efb8c8d4d67c6ef17700075e8353@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 18:29:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 18:29:57 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.6f50aa86082ec4a2f3dbbc8528e76d23@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | 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): Hmm, there is something odd going on here. 396aac4c65a47b6252e0a73d2a3066e924d53f11 added the `amd64-portbld-freebsd` triple but this suggests that we should actually be using `x86_64-unknown-freebsd`. I guess I'll just add the missing triplet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 18:42:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 18:42:38 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.20f3df1e1c219d2a615faa5f07148de9@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5448 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5448 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 19:09:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 19:09:08 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.bd58b2db7a5bc2ddaa63c1888089fc08@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 19:14:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 19:14:03 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.d5502f0344a92b78912425c808eaefd4@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T13839 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5449 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => make test TEST=T13839 * status: new => patch * differential: => Phab:D5449 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 19:23:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 19:23:32 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.c4d50768e63515bd2dbf645579419a65@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): And today, it's better by still won't compile: {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.7 -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/hieFile -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 -Icompiler/stage2/build/. -Icompiler/stage2/build/parser -Icompiler/stage2/build/utils -Icompiler/stage2/build/../rts/dist/build -Icompiler/stage2/build/stage2 -optP-DGHCI -optP-DINTEGER_GMP -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.9.0 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.1 -package-id filepath-1.4.2.1 -package-id ghc-boot-8.7 -package-id ghc-boot-th-8.7 -package-id ghc- heap-8.7 -package-id ghci-8.7 -package-id hpc-0.6.0.3 -package-id integer- gmp-1.0.2.0 -package-id process-1.6.3.0 -package-id template- haskell-2.15.0.0 -package-id terminfo-0.4.1.2 -package-id time-1.9.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wno-name- shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail- instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O -dcore-lint -dno-debug-output -DDEBUG -Wcpp- undef -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir compiler/stage2/build -c compiler/specialise/Specialise.hs -o compiler/stage2/build/Specialise.p_o -dyno compiler/stage2/build/Specialise.dyn_o compiler/stranal/WwLib.hs:21:1: error: [-Wunused-imports, -Werror=unused- imports] The import of ‘vanillaIdInfo’ from module ‘IdInfo’ is redundant | 21 | import IdInfo ( JoinArity, vanillaIdInfo ) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <> make[1]: *** [compiler/ghc.mk:445: compiler/stage2/build/WwLib.p_o] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 19:31:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 19:31:51 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.e1f88bb5806c607d048203e8fcca12d3@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 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 andrewthad): I just ran into this problem as well. It's easy to work around by just omitting the single quotes. I may try to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 20:43:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 20:43:40 -0000 Subject: [GHC] #16046: -fno-stack-protector still necessary? Message-ID: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> #16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- aclocal.m4 has a block of code that checks to see if gcc supports -fno- stack-protector and adds that flag if so. That ends up in /usr/lib/ghc/settings, gets passed in whenever C bits get built, etc. I see that block was moved into place in 2010, but is even older than that. What I'm wondering is: is that still necessary to do, or do ghc and stack protection play nicely together now? I've searched around but can't find much information about it (searching for ghc and stack is a lot harder since that program appeared). The one thing I've found is: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev- lang/ghc?id=8cee49e4a6c8d9ec80faa4054b621467450d3ebb I'm in charge of building Haskell-related stuff for a semi-private Linux distribution and just want to make sure I'm getting things right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 22:19:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 22:19:13 -0000 Subject: [GHC] #15774: SIGQUIT only reports backtrace for one capability (was: SIGKILL only reports backtrace for one capability) In-Reply-To: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> References: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> Message-ID: <061.f388baf3268508efbc217abd568f5c04@haskell.org> #15774: SIGQUIT only reports backtrace for one capability -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > SIGKILL is intended to mirror the same signal's functionality provided by > the JVM. That is, provide a snapshot of a processes' state in the form of > backtraces on stderr. However, GHC's implementation currently only prints > a backtrace for a single, arbitrary thread. This should be fixed. New description: SIGQUIT is intended to mirror the same signal's functionality provided by the JVM. That is, provide a snapshot of a processes' state in the form of backtraces on stderr. However, GHC's implementation currently only prints a backtrace for a single, arbitrary thread. This should be fixed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 22:19:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 22:19:41 -0000 Subject: [GHC] #15774: SIGQUIT only reports backtrace for one capability In-Reply-To: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> References: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> Message-ID: <061.3d88a29f0458db5f1e08055106f00a38@haskell.org> #15774: SIGQUIT only reports backtrace for one capability -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:2 lelf]: > Surely you meant SIGQUIT Indeed I did. Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 22:53:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 22:53:14 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi In-Reply-To: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> References: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> Message-ID: <057.63a4a6e36cfff32c1dadcdfa4d1157bf@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: | artemohanjanyan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: operator | precedence, 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 sjs): * Attachment "0001-Adds-fixities-GHCi-command.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 22:55:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 22:55:53 -0000 Subject: [GHC] #15080: List Operators Sorted by Precedence in GHCi In-Reply-To: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> References: <042.0874d1a1880ecd8d77f20358849846e6@haskell.org> Message-ID: <057.e4c86503f1e3dff9df41c0f215b140f1@haskell.org> #15080: List Operators Sorted by Precedence in GHCi -------------------------------------+------------------------------------- Reporter: sjs | Owner: | artemohanjanyan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: operator | precedence, 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 sjs): The current iteration of this is really simple, it adds a `:fixities` command to GHCi that shows a table of all functions in scope with non- default fixities. With just the Prelude loaded, here's the output: {{{ Prelude> :fixities 9: right: . 8: right: ^ ** ^^ 7: left: * / div mod quot rem 6: left: + - right: <> 5: right: ++ 4: left: <*> *> <$ <* <$> none: elem >= == /= < <= > notElem 3: right: && 2: right: || 1: left: >>= >> right: =<< 0: right: $ seq $! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 13 23:39:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Dec 2018 23:39:12 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.f84b5ece8f19277b2e668a311dad40cc@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sigh. Sorry. I've pushed another micro-patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 01:38:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 01:38:28 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.dc050ca2e47beb142edd40da64e554d2@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Alp, if you've got bandwidth for this, I suggest you go ahead. Alternatively, I will be able to implement this when this semester is finally over :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 02:19:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 02:19:28 -0000 Subject: [GHC] #14345: Warning when linking with C++ code In-Reply-To: <047.f1b4db3acbc221c558e5c522a0ac645a@haskell.org> References: <047.f1b4db3acbc221c558e5c522a0ac645a@haskell.org> Message-ID: <062.9576caff02218382cf15e7aeb05fa6a3@haskell.org> #14345: Warning when linking with C++ code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 02:59:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 02:59:41 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.d5b08797d79b438867a1706369a83210@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: patch Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2634d840269c84c4f929af52f3b592ece64f3b86/ghc" 2634d84/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2634d840269c84c4f929af52f3b592ece64f3b86" Fix broken link in comment (#16010) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 02:59:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 02:59:41 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.8671bf66d30a495ea4d18e884e2179c6@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5448 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9b8713e8bf905c17251a0fad22eee690c4e50f0c/ghc" 9b8713e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b8713e8bf905c17251a0fad22eee690c4e50f0c" llvm-targets: Add amd64-unknown-freebsd triple 396aac4c65a47b6252e0a73d2a3066e924d53f11 added the amd64-portbld-freebsd triple but #15718 suggests that we should rather be using x86_64-unknown-freebsd. Not knowing which is correct I've left the amd64-portbld- triplet in place. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 02:59:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 02:59:41 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.ab30c86a1179c03e7167ebea3f821a9a@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | Version: 8.2.2 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 Ben Gamari ): In [changeset:"6cf8d0b3bf61bc4134780c9efab2ab882d57e0f0/ghc" 6cf8d0b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6cf8d0b3bf61bc4134780c9efab2ab882d57e0f0" Add some complexities to Data.List documentation (#15003) Describe complexity and add an example for `GHC.List.filter`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 03:00:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 03:00:30 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.238884a4198a7f0c8f030786395ab42b@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5448 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 03:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 03:01:47 -0000 Subject: [GHC] #16010: Broken Link in Data.OldList In-Reply-To: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> References: <048.5b1f1066d2780b83bda245032f343f2a@haskell.org> Message-ID: <063.c67a98dd8fcdde884b6f5494666ca149@haskell.org> #16010: Broken Link in Data.OldList -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: closed Priority: lowest | Milestone: ⊥ Component: libraries/base | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 03:02:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 03:02:56 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.5416d1c543aeda9420064c1c6c51bef2@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | Version: 8.2.2 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 bgamari): I'm a bit unsure of whether there is more to be done here. supersven, feel free to close this if you feel it's done otherwise keep throwing patches my way :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 05:28:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 05:28:15 -0000 Subject: [GHC] #16047: Incorrect hscTarget in DynFlags when building hs-boot files Message-ID: <043.e06f5cca4c2b09a29027db21c584c6e5@haskell.org> #16047: Incorrect hscTarget in DynFlags when building hs-boot files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We don't generate code for hs-boot files, but currently `hscTarget` field of `DynFlags` does not reflect that and we see `HscAsm` etc. when building boot files. I think we should see `HscNothing` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 09:03:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 09:03:54 -0000 Subject: [GHC] #16007: Implement `-Os` In-Reply-To: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> References: <044.4100e79eeb5d600245ddfab8559b700b@haskell.org> Message-ID: <059.125a677086dfa33c4489f7007b3fde1b@haskell.org> #16007: Implement `-Os` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16005, #12915, | Differential Rev(s): #14226 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Popular C compilers like GCC or clang allow to optimise for binary size. > > Since there are multiple ways in which GHC trades code size for faster > programs, it might make sense to follow suit. This ticket is for tracking > which optimisations/hacks in the compiler might be affected, as well as > > Feel free to add items to the following list: > > - potentially huge impact due to specialisation, liberate case and > inlining > - potential of -0.9% due to a second run of common block elimination > (#14226) > - +0.1% increase in code size due to known calls instead of re-using > generic apply thunks in #16005 > - -0.1% due to `-fstg-lift-lams` #9476 New description: Popular C compilers like GCC or clang allow to optimise for binary size. Since there are multiple ways in which GHC trades code size for faster programs, it might make sense to follow suit. This ticket is for tracking which optimisations/hacks in the compiler might be affected. Feel free to add items to the following list: - potentially huge impact due to specialisation, liberate case and inlining - potential of -0.9% due to a second run of common block elimination (#14226) - +0.1% increase in code size due to known calls instead of re-using generic apply thunks in #16005 - -0.1% due to `-fstg-lift-lams` #9476 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 13:35:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 13:35:08 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) In-Reply-To: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> References: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> Message-ID: <062.d4f35f858bb91adedcded8662e9fa262@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: takenobu Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13126 #9224 | Differential Rev(s): Phab:D4235 Wiki Page: | -------------------------------------+------------------------------------- Comment (by takenobu): > Pygments (which is used from trac, readthedocs, pandoc, ...) > This is pending review. > ​https://bitbucket.org/birkenfeld/pygments-main/pull-requests/745 The patch for Pygments has been merged. (Development of Pygments was restarted.) Syntax hightlight for NumericUnderscores, BinaryLiterals and HexFloatLiterals will be available on Pygments, Sphinx, readthedocs and pandoc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 14:17:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 14:17:39 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.e19152a324e7faacf3f3da8157063f44@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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:D5454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan * differential: => Phab:D5454 Comment: I have one part done: the ability to override the default flavour (not the flavour whose name is `default`, I instead mean the flavour that we use when no `--flavour=...` argument is passed to hadrian). See https://phabricator.haskell.org/D5454, feedback welcome! Regarding `buildThreads`, I'm finding it a little hard to get a chance to set the parallelism (through the `shakeThreads` field of `ShakeOptions`) when 1/ it's not overriden on the command line with `-j` 2/ using the default value specified by that `buildThreads` field I'm adding, since I don't have a handle on the flavour just yet. The same applies to the build root, I think, even though I haven't looked into that one a lot yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 15:20:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 15:20:37 -0000 Subject: [GHC] #16046: -fno-stack-protector still necessary? In-Reply-To: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> References: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> Message-ID: <061.06678ccbf239adb614ed8e5f3271bfb2@haskell.org> #16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.4.3 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clumens): * component: Compiler => Build System (make) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 15:22:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 15:22:08 -0000 Subject: [GHC] #15333: Nursery size adulterates cachegrind metrics in nofib In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.6051bf26b23fff5036f760fcef2c9b21@haskell.org> #15333: Nursery size adulterates cachegrind metrics in nofib -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #15999 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #5793 #15999 Comment: See my recent concerns about the non-monotone impact of allocations on productivity. Here's a productivity curve: [[Image(https://i.imgur.com/kiZwF0R.png)]] It's not as bad as with paraffins in #15999, but not really monotone either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 16:52:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 16:52:54 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.a5dbea837dbf23726d6b5fa449e90081@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) Comment: Although serialising and deserialising the result of `with_ccs` gets rid of the non-determinism in total allocations AFAICT (using Read/Show is pretty slow, so I only did ~20 iterations), the average residency/number of samples seems to vary by one (23 vs. 24). Not sure if it's important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 16:54:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 16:54:56 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.806a23a1f806ae58fa3f2bd4b986a0c9@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): If I seq `with_ccs` like this: {{{ foldr seq () with_ccs `seq` return final }}} where `final = final_cleanup with_synth_2`, the non-determinism seems irreproducible. Still, the number of samples (and average residency, consequently) varies between 10 and 11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 17:11:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 17:11:50 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.64b18b871f30d2fc8681aa4ab0c615bd@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): If I force `data_areas` in `synth_2` like this: {{{ foldr seq () data_areas `seq` synthd_assy ++ data_areas }}} the non-determinism is irreproducible. If I instead force the whole list, like this: {{{ let res = synthd_assy ++ data_areas in foldr seq () res `seq` res }}} it's non-deterministic still. Seems like this isn't really possible to localise?! I'll leave this for another day. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 17:13:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 17:13:53 -0000 Subject: [GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile In-Reply-To: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> References: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> Message-ID: <064.c9d4a2755a27c00e560a62f4811488e7@haskell.org> #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 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 investigated some more and get the basic support working. None of the call stack stuff is useful for GHC as every call is a tail call so the call hierarchy is completely flat. Here is the branch: https://github.com/mpickering/ghc/tree/llvm-xray See this thread on llvm-devs for some of the problems and suggestions of the LLVM devs: http://lists.llvm.org/pipermail/llvm- dev/2018-December/128184.html Here's an example comment I was using to compile which correctly instrumented a binary. {{{ _build/stage1/bin/ghc -fllvm -ddump-llvm llvm.hs -opta="-v" -pgma=clang -pgmc=clang -pgml=clang -optl="-fxray-instrument" -optl="-fxray- instruction-threshold=1" -optlo="-O0" -O2 -g3 -fforce-recomp nofib/real/fulsom/Main.hs -inofib/real/fulsom/ }}} Problems 1. You have to pass `-O0` to `opt` as otherwise the LLVM verifier complains about our debugging information. See the email list for more information about this. 2. It didn't seem like every call was actually counted in some simple tests but I didn't look too closely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 17:21:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 17:21:51 -0000 Subject: [GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile In-Reply-To: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> References: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> Message-ID: <064.3cca8b34975403557c152cf942e074f7@haskell.org> #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 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 adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 17:23:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 17:23:48 -0000 Subject: [GHC] #16048: Show Instance for IOException discards error code Message-ID: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> #16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Show` instance for `IOException` currently looks like this: {{{ instance Show IOException where showsPrec p (IOError hdl iot loc s _ fn) = (case fn of Nothing -> case hdl of Nothing -> id Just h -> showsPrec p h . showString ": " Just name -> showString name . showString ": ") . (case loc of "" -> id _ -> showString loc . showString ": ") . showsPrec p iot . (case s of "" -> id _ -> showString " (" . showString s . showString ")") }}} Notice that it discards the error code (the fifth field in the data constructor). This means that when we call `ioError` to raise an `IOException`, we end up missing out on useful information. For example, in a project I'm working on now, I get this: {{{ *** Exception: Network.Icmp.Ping: ping: permission denied (Permission denied) }}} But I expected to see the original error code in there as well, which would help me diagnose issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 17:47:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 17:47:38 -0000 Subject: [GHC] #15973: Int used to represent target integer literals In-Reply-To: <046.8d7be0ce7920b1b1ea4653aefb2fa9b9@haskell.org> References: <046.8d7be0ce7920b1b1ea4653aefb2fa9b9@haskell.org> Message-ID: <061.c651aad828412fab904bbd67685fbaa4@haskell.org> #15973: Int used to represent target integer literals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 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 chessai): Some questions: Should this be `Int64`, `Int32`, or what? How could one filter out which uses of `Int` are problematic in this way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 18:05:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 18:05:46 -0000 Subject: [GHC] #15882: :load in ghci should expose the entire namespace of a module In-Reply-To: <048.6a2e149d17b2fdb2cdd8b7fb78fbd1d6@haskell.org> References: <048.6a2e149d17b2fdb2cdd8b7fb78fbd1d6@haskell.org> Message-ID: <063.9c0267cc39361af6148adb376fb584ec@haskell.org> #15882: :load in ghci should expose the entire namespace of a module -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.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 adamse): I think you're describing the current behaviour: {{{ $ cat T.hs module T (f) where import Data.Monoid f :: Int f = 2 g :: Double g = 2 $ ghci GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help :l Loaded GHCi configuration from /Users/adam/.ghci Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) ... Ok, one module loaded. *T> g 2.0 it :: Double *T> :t Sum Sum :: a -> Sum a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 19:37:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 19:37:09 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.ae1220e49774bd2d63678872d6836b54@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Thanks. Well we're now back to ```dist-install/build/HSghc- prim-0.5.3.p_o: copyFile: does not exist (No such file or directory)``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 20:25:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 20:25:51 -0000 Subject: [GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide" In-Reply-To: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> References: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> Message-ID: <061.51ac5344097206055b0f8719e0daae65@haskell.org> #15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * status: new => patch * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 21:09:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 21:09:55 -0000 Subject: [GHC] #16049: Add a warning flag that warns when a datatype could be a newtype Message-ID: <046.2e896791074592453fd18aea416912d8@haskell.org> #16049: Add a warning flag that warns when a datatype could be a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: flags | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- More often than not, `newtype` is desirable over `data` if a type has a single field. I propose a warning flag `-Wdata-could-be-newtype` that would warn users if a data type they've defined has a single field (and thus could be a `newtype`). It would need to be explicitly enabled (and of course enabled by `-Weverything`). An example (relevant Trac ticket: #15995): {{{#!hs -- Control.Concurrent.QSem: data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} There's a bang pattern on its single field, but this could just be supplied at every pattern-matching site of `QSem`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 21:16:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 21:16:29 -0000 Subject: [GHC] #16049: Add a warning flag that warns when a datatype could be a newtype In-Reply-To: <046.2e896791074592453fd18aea416912d8@haskell.org> References: <046.2e896791074592453fd18aea416912d8@haskell.org> Message-ID: <061.f7ed7b20cc6734b35c3396f6bc419ad5@haskell.org> #16049: Add a warning flag that warns when a datatype could be a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: flags 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 chessai: Old description: > More often than not, `newtype` is desirable over `data` if a type has a > single field. I propose a warning flag `-Wdata-could-be-newtype` that > would warn users if a data type they've defined has a single field (and > thus could be a `newtype`). It would need to be explicitly enabled (and > of course enabled by `-Weverything`). An example (relevant Trac ticket: > #15995): > > {{{#!hs > -- Control.Concurrent.QSem: > > data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) > > }}} > > There's a bang pattern on its single field, but this could just be > supplied at every pattern-matching site of `QSem`. New description: More often than not, `newtype` is desirable over `data` if a type has a single field. I propose a warning flag `-Wdata-could-be-newtype` that would warn users if a data type they've defined has a single field (and thus could be a `newtype`). It would need to be explicitly enabled (and of course enabled by `-Weverything`). An example (relevant Trac ticket: #15995): {{{#!hs -- Control.Concurrent.QSem: data QSem = QSem !(MVar (Int, [MVar ()], [MVar ()])) }}} could be a newtype {{{#!hs -- Control.Concurrent.QSem: newtype QSem = QSem (MVar (Int, [MVar ()], [MVar ()])) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 21:37:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 21:37:24 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral In-Reply-To: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> References: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> Message-ID: <057.56c75d32d0b2d549b90aeaa12b561587@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 chessai): > It would be very useful for tooling if `ghc`'s CLI had some flag to dump an extended version of `--supported-languages` that's easy to parse What kind of format do you have in mind, if any? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 21:52:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 21:52:22 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information Message-ID: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- consider the following modules: {{{#!hs module A where (.) :: forall (a :: TYPE 'UnliftedRep) (b :: TYPE 'UnliftedRep) (c :: TYPE 'UnliftedRep). (b -> c) -> (a -> b) -> (a -> c) (.) f g = \x -> f (g x) data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a mapFB :: forall (a :: TYPE 'UnliftedRep) (elt :: TYPE 'UnliftedRep) (lst :: Type). (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst mapFB c f = \x ys -> c (f x) ys {-# RULES "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f . g) #-} }}} {{{#!hs module B where import Control.Category ((.)) data UList (a :: TYPE 'UnliftedRep) where UNil :: UList a UCons :: a -> UList a -> UList a mapFB :: forall (a :: TYPE 'UnliftedRep) (elt :: TYPE 'UnliftedRep) (lst :: Type). (elt -> lst -> lst) -> (a -> elt) -> a -> lst -> lst mapFB c f = \x ys -> c (f x) ys {-# RULES "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f . g) #-} }}} Module 'A' works fine. Module 'B', fails with the following error: {{{#!hs • No instance for (Category (->)) arising from a use of ‘.’ • In the second argument of ‘mapFB’, namely ‘(f . g)’ In the expression: mapFB c (f . g) When checking the transformation rule "mapFB" | line| "mapFB" forall c f g. mapFB (mapFB c f) g = mapFB c (f . g) | ^^^ }}} I expected this failure because of the kind mismatch; the category instance for `(->)` obviously requires that it be kinded `Type -> Type -> Type`. However, it confused someone I am teaching, who said to me that they didn't understand the error, since they expected it to work as `(->)` does indeed have a Category instance. (They are very unfamiliar with Levity-Polymorphism). My question is this: Would it be preferable to include such kind information in the error message? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 14 22:06:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Dec 2018 22:06:25 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.9d9001f3e305d178f1dc46206839dff0@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 chessai): Now that I think of this, this confused me a lot more the first time I came across such an error. The error message just says nothing about the kinds, so saying that an instance doesn't exist is pretty confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 00:58:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 00:58:11 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian Message-ID: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- Hadrian falls over essentially immediately when cross-compiling: {{{ $ ./boot $ ./configure --target=aarch64-linux-gnu $ hadrian/build.cabal.sh -j32 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 00:58:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 00:58:21 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian In-Reply-To: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> References: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> Message-ID: <061.118b17f39e6d31a17dbb7b30531ad969@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: 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: alpmestan, snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 00:58:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 00:58:48 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian In-Reply-To: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> References: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> Message-ID: <061.930adef4f55e06afbb0fa9695a321342@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: 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: > Hadrian falls over essentially immediately when cross-compiling: > {{{ > $ ./boot > $ ./configure --target=aarch64-linux-gnu > $ hadrian/build.cabal.sh -j32 > }}} New description: Hadrian falls over essentially immediately when cross-compiling: {{{ $ ./boot $ ./configure --target=aarch64-linux-gnu $ hadrian/build.cabal.sh -j32 Up to date Up to date | Copy file: settings => _build/stage1/lib/settings | Copy file: settings => _build/stage0/lib/settings | Copy file: utils/hsc2hs/template-hsc.h => _build/stage0/lib/template- hsc.h | Copy file: llvm-targets => _build/stage0/lib/llvm-targets | Copy file: driver/ghc-usage.txt => _build/stage0/lib/ghc-usage.txt | Copy file: llvm-passes => _build/stage0/lib/llvm-passes | Copy file: driver/ghci-usage.txt => _build/stage0/lib/ghci-usage.txt shakeArgsWith 0.000s 0% Function shake 0.084s 20% ====== Database read 0.000s 0% With database 0.000s 0% Running rules 0.329s 79% ========================= Total 0.415s 100% Error when running Shake build system: at src/Rules.hs:(35,19)-(48,17): at src/Rules.hs:48:5-17: * Depends on: _build/stage2/bin/aarch64-linux-gnu-ghctags at src/Hadrian/Utilities.hs:292:5-18: * Depends on: _build/stage0/bin/aarch64-linux-gnu-ghctags * Raised the exception: Unknown program "_build/stage0/bin/aarch64-linux-gnu-ghctags" CallStack (from HasCallStack): error, called at src/Rules/Program.hs:26:29 in main:Rules.Program }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 01:02:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 01:02:53 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian In-Reply-To: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> References: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> Message-ID: <061.e74b19737cd88aaa85dc61e6c4516894@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: 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 believe this broke due to 665f8b0c778b3a5dac4696f81da0cea88b101ea9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 01:47:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 01:47:03 -0000 Subject: [GHC] #16045: improve dwarf support on OSX In-Reply-To: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> References: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> Message-ID: <060.5ffd10eafe919e9b37bdf50b50905f29@haskell.org> #16045: improve dwarf support on OSX ---------------------------------+-------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 fghibellini): From recent communication with @bgamari > At the moment it's not even possible to compile GHC with debug > symbols enabled due to apparent limitations in the MachO object format > (we seem to generate more sections than MachO can represent). > > It would be helpful if you could open a GHC ticket. ... it would be good > to record the current status of DWARF on Darwin. Currently https://ghc.haskell.org/trac/ghc/wiki/DWARF has a paragraph: > For Mac Os, debug information is kept separate from the binary, so we first have to package it using dsymutil: And from https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /debug-info.html : > Under Mac OS X debug information is kept apart from the executable. After compiling the executable you’ll need to use the dsymutil utility to extract the debugging information and place them in the debug archive, Both pages make the user think that this is possible - I don't understand how the comments got there in the first place if there is no support for it. Would be nice to replace those comments with warnings so others don't spend time trying to understand why it doesn't work on their machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 02:02:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 02:02:18 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range Message-ID: <049.35f339a100b576d6db7c28659297f61e@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been doing some API bindings lately that require zeroing out memory before poking values into the appropriate places. Sometimes, these are small data structures. For instance, on linux, the internet socket struct `sockaddr_in` is 16 bytes. Here's an example (not involving `sockaddr_in`) of the kind of situation that arises: {{{ {-# language MagicHash #-} {-# language UnboxedTuples #-} module FillArray ( fill ) where import GHC.Exts import GHC.IO data ByteArray = ByteArray ByteArray# fill :: IO ByteArray fill = IO $ \s0 -> case newByteArray# 24# s0 of (# s1, m #) -> case setByteArray# m 0# 24# 0# s1 of s2 -> case writeWord8Array# m 4# 14## s2 of s3 -> case writeWord8Array# m 5# 15## s3 of s4 -> case unsafeFreezeByteArray# m s4 of (# s5, r #) -> (# s5, ByteArray r #) }}} This `fill` function allocates a 24-byte array, sets everything to zero, and then writes the numbers 14 and 15 to elements 4 and 5 respectively. With `-O2`, here's the relevant part of the core we get: {{{ fill1 fill1 = \ s0_a140 -> case newByteArray# 24# s0_a140 of { (# ipv_s16i, ipv1_s16j #) -> case setByteArray# ipv1_s16j 0# 24# 0# ipv_s16i of s2_a143 { __DEFAULT -> case writeWord8Array# ipv1_s16j 4# 14## s2_a143 of s3_a144 { __DEFAULT -> case writeWord8Array# ipv1_s16j 5# 15## s3_a144 of s4_a145 { __DEFAULT -> case unsafeFreezeByteArray# ipv1_s16j s4_a145 of { (# ipv2_s16p, ipv3_s16q #) -> (# ipv2_s16p, ByteArray ipv3_s16q #) } } } } } }}} And, here's the relevant assembly: {{{ fill1_info: _c1kL: addq $56,%r12 cmpq 856(%r13),%r12 ja _c1kP _c1kO: movq $stg_ARR_WORDS_info,-48(%r12) movq $24,-40(%r12) leaq -48(%r12),%rax subq $8,%rsp leaq 16(%rax),%rdi xorl %esi,%esi movl $24,%edx movq %rax,%rbx xorl %eax,%eax call memset addq $8,%rsp movb $14,20(%rbx) movb $15,21(%rbx) movq $ByteArray_con_info,-8(%r12) movq %rbx,(%r12) leaq -7(%r12),%rbx jmp *(%rbp) _c1kP: movq $56,904(%r13) movl $fill1_closure,%ebx jmp *-8(%r13) .size fill1_info, .-fill1_info }}} What a bummer that using `memset` for something as small setting three machine words (on a 64 bit platform) results in a `call` instruction getting generated. Why not simply generate three `movb` instructions for the zero initialization instead? Currently, users can work around this by translating their `setByteArray#` call to several `writeWordArray#` calls. This optimization obscures the meaning of written code and is not portable across architectures (so you have to use `CPP` to make it work on 32 bit and 64 bit). I'd like to add a cmm-to-assembly optimization to GHC that does unrolling instead so that the user can write more natural code. Specifically, here's what I'm thinking: * This only happens when the offset into the `ByteArray#` and the length of the range are constant that are multiples of the machine word size. So, `setByteArray# arr 8# 16# x` is eligible on 32-bit and 64-bit platforms. And `setByteArray# arr 4# 8# x` is eligible only on a 32-bit platform. And `setByteArray# arr 16# y x` is not eligible on any platform. * This only happens when the `call memset` instruction has a range of 32 bytes or less. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 09:06:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 09:06:39 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian In-Reply-To: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> References: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> Message-ID: <061.d8e84eb0ef48a2de77be8dc0fa2f646a@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 15:28:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 15:28:34 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.79d1e879139d41f79a4998beb167430f@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): This also seems to fail periodically on amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 17:19:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 17:19:35 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") Message-ID: <042.d2a891901a0626563f3984239b07084f@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.7 (make) | 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: -------------------------------------+------------------------------------- Ben asked me to file this here: Some time between 8.7.20181015+git.1.2e1df7c and 8.7.20181210+git.1.4773b43 the GHC build process as orchestrated by the automated PPA Debian package builds started failing with {{{ /usr/bin/install -c -m 755 -d "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts" for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts- ghc8.7.20181210.so rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug- ghc8.7.20181210.so rts/dist/build/libHSrts_thr-ghc8.7.20181210.so rts/dist/build/libHSrts_thr_debug-ghc8.7.20181210.so rts/dist/build /libHSrts_l-ghc8.7.20181210.so rts/dist/build/libHSrts_thr_l- ghc8.7.20181210.so rts/dist/build/libHSrts_thr_debug_p.a rts/dist/build/libHSrts_debug_p.a rts/dist/build/libffi.so rts/dist/build/libffi.so.7 rts/dist/build/libffi.so.7.1.0 rts/dist/build/libCffi.a rts/dist/build/libCffi_p.a rts/dist/build/libCffi_l.a rts/dist/build/libCffi_debug.a rts/dist/build/libCffi_thr.a rts/dist/build/libCffi_thr_debug.a rts/dist/build/libCffi_thr_l.a rts/dist/build/libCffi_thr_p.a rts/dist/build/libCffi_thr_debug_p.a rts/dist/build/libCffi_debug_p.a; do case $i in *.a) /usr/bin/install -c -m 644 $i "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts"; true "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts" ; strip "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts";; *) /usr/bin/install -c -m 644 $i "/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210/rts"; esac; done "inplace/bin/ghc-cabal" copy libraries/ghc-prim dist-install "strip" '/<>/ghc-head-8.7.20181210+git.1.4773b43/debian/tmp' '/opt/ghc/head' '/opt/ghc/head/lib/ghc-8.7.20181210' '/opt/ghc/head/share/doc/ghc-8.7.20181210/html/libraries' 'v dyn p' Installing library in /<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp/opt/ghc/head/lib/ghc-8.7.20181210 /ghc-prim-0.5.3 dist-install/build/HSghc-prim-0.5.3.p_o: copyFile: does not exist (No such file or directory) make[2]: *** [install_packages] Error 1 make[1]: *** [install] Error 2 make[1]: Leaving directory `/<>/ghc- head-8.7.20181210+git.1.4773b43' dh_auto_install: make -j4 install DESTDIR=/<>/ghc- head-8.7.20181210+git.1.4773b43/debian/tmp AM_UPDATE_INFO_DIR=no returned exit code 2 }}} Full logs available at https://launchpadlibrarian.net/401081604 /buildlog_ubuntu-trusty-amd64.ghc- head_8.7.20181210+git.1.4773b43-9~14.04_BUILDING.txt.gz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 19:34:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 19:34:50 -0000 Subject: [GHC] #16054: Unable to build stage3 with hadrian Message-ID: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> #16054: Unable to build stage3 with hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that stage3 is unsupported by hadrian. I am trying to build the target `_build/stage2/bin/ghc` but it is reported as an unknown program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 22:10:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 22:10:13 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.85645e741e937d9f96adfeadd8226a13@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 andrewthad): Weird. According to https://ghc.haskell.org/trac/ghc/wiki/MemcpyOptimizations, GHC already does this. Except that I can see that it doesn’t actually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 22:11:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 22:11:26 -0000 Subject: [GHC] #15662: Line pragmas appear to be slightly broken with Clang's CPP In-Reply-To: <046.2a012973b0e74ae240426b655456015f@haskell.org> References: <046.2a012973b0e74ae240426b655456015f@haskell.org> Message-ID: <061.751ab2d661fc09a010c4ec5b32440548@haskell.org> #15662: Line pragmas appear to be slightly broken with Clang's CPP -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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): This appears to be fixed in Xcode 10.1 and macOS 10.14.2. It's not entirely clear how we should handle the broken annotation now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 22:22:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 22:22:28 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.d82a691dc872f138667ffc1f08849a35@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Some notes from my Windows machine: - In the default build configuration with `-O2`, allocations are completely stable. Maximum residency is unstable, though. - The instability in max residency goes away if I do similar surgically `seq`s as above. - In `-O0`, I even get unstable allocations on Windows, with the samples spread wider than on Linux the other day. - In `-O0 -prof -fprof-auto` there's still a seldom, minimal instability of 40 bytes delta - Judging from `+RTS -S` output, the culprit seems to be an errorneous life set. Comparing two reports from different runs, there was always a point at which the live bytes differed and only much later total bytes allocated would differ. I had a sample where the difference was 1488 bytes in (minor) collection no. 11. These allocations seem to be kept live until the end of the program, and more live data is added during the run of the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 22:25:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 22:25:05 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.5c62af4ec487e53fe8b65d15cddee84b@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 15 23:47:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Dec 2018 23:47:48 -0000 Subject: [GHC] #16055: libffi build logic is quite spread out Message-ID: <049.69c0585ce2ec738f86fe1ddce161d6b4@haskell.org> #16055: libffi build logic is quite spread out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The rules for building libffi are in `Rules.Libffi` and at a first glance they just use the normal `Make` builder in order to build the project. However, if one looks carefully, you actually need to run `make install` so the normal `Make` builder has an argument appended in `Settings.Builders.Make`. The problem here is that the two modules are completely unrelated to each other. In order to discover this I had to wonder why the build was failing to copy a file and then by chance guess that it wasn't running `make install`. I think grepped for `"install"` and managed to find this additional rule. Is there a way to move this logic into one place? I considered two possibilities but it didn't seem to be "how things are done". 1. Modify the `Make` builder to take an additional argument which indicates whether to add the `install` flag. 2. Move the override of `Make` for libffi into `Rules.Libffi` and then import it into `Settings.Builders.Make`. This seems better but you still not entirely obvious what is going on. Do the hadrian experts have any opinion on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 04:30:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 04:30:45 -0000 Subject: [GHC] #16056: Hadrian failure: Values have changed since being depended upon Message-ID: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> #16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Hadrian build on Windows appears to fail with: {{{ /--------------------------------------------------------------------------\ | Successfully built program 'haddock' (Stage2). | | Executable: _build/stage2/bin/haddock.exe | | Program synopsis: A documentation-generation tool for Haskell libraries. | \--------------------------------------------------------------------------/ shakeArgsWith 0.002s 0% Function shake 0.035s 0% Database read 0.003s 0% With database 0.001s 0% Running rules 2815.075s 99% ========================= Pool finished (9025 threads, 8 max) 0.001s 0% Lint checking 0.641s 0% Total 2815.758s 100% Lint checking error - 520 values have changed since being depended upon: Key: _build/stage1/gmp/objs/zero_p.o Old: (Just File {mod=0x88773CC6,size=0x2EA,digest=0xACFF03E6},"") New: File {mod=0x8C6CE092,size=0x2EA,digest=0xACFF03E6} Key: _build/stage1/gmp/objs/zero.o Old: (Just File {mod=0x88DC1816,size=0x2F8,digest=0x586B32DC},"") New: File {mod=0x8CA46DC3,size=0x2F8,digest=0x586B32DC} Key: _build/stage1/gmp/objs/xor_n.o Old: (Just File {mod=0x88D86EC7,size=0x1DF,digest=0xFBB5353},"") New: File {mod=0x8CA1D672,size=0x1DF,digest=0xFBB5353} ... }}} All paths listed are in `_build/stage1/gmp` and all changed only in their mtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 04:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 04:30:56 -0000 Subject: [GHC] #16056: Hadrian failure: Values have changed since being depended upon In-Reply-To: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> References: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> Message-ID: <061.5c97a92d8ea8648de5a4ade4eb82afdb@haskell.org> #16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: alpmestan, snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 04:35:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 04:35:53 -0000 Subject: [GHC] #16056: Hadrian failure: Values have changed since being depended upon In-Reply-To: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> References: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> Message-ID: <061.364db4205e5fb476321c1343e1331d7b@haskell.org> #16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): See https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/1817 for an example of this failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 08:40:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 08:40:59 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.16e30c17f2710f1819855b9b370dc3dc@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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:D5454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Another problem with `UserSettings.hs` is that it's tracked by version control. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 08:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 08:57:21 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.66b77210bc6d54c78cc37e8ac9a965c4@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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:D5454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Matthew, see this comment on top: {{{ -- If you want to customise your build you should copy this file from -- hadrian/src/UserSettings.hs to hadrian/UserSettings.hs and edit your copy. -- If you don't copy the file your changes will be tracked by git and you can -- accidentally commit them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 09:02:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 09:02:15 -0000 Subject: [GHC] #16056: Hadrian failure: Values have changed since being depended upon In-Reply-To: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> References: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> Message-ID: <061.089b471bed7e42ac162a9690ff9e76da@haskell.org> #16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Wait, this is a duplicate of https://ghc.haskell.org/trac/ghc/ticket/15971 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 13:30:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 13:30:52 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 Message-ID: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Have these two files in a directory: Main.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import Helper main = return () test }}} Helper.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Helper where import Language.Haskell.TH test :: Q [Dec] test = return [] }}} If compiled with `ghc Main.hs`, the compilation freezes, when it reaches `Main`. This works well on Linux (Ubuntu 18) using GHC 8.6.3, and there is no problem in GHC 8.4.3 on either Windows or Linux. GCC version: 8.2.0 Rev3 (from MSYS2) / 7.2.0 Rev1 (from cmd.exe) Adding -dcore-lint does not change the outcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 13:33:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 13:33:56 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.9c6b71b4f9093285e0f6bf2bc77b85a3@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by gizmo.mk0: Old description: > Have these two files in a directory: > > Main.hs: > {{{#!hs > {-# LANGUAGE TemplateHaskell #-} > module Main where > import Helper > > main = return () > > test > }}} > > Helper.hs: > {{{#!hs > {-# LANGUAGE TemplateHaskell #-} > module Helper where > import Language.Haskell.TH > > test :: Q [Dec] > test = return [] > }}} > > If compiled with `ghc Main.hs`, the compilation freezes, when it reaches > `Main`. > > This works well on Linux (Ubuntu 18) using GHC 8.6.3, and there is no > problem in GHC 8.4.3 on either Windows or Linux. > > GCC version: 8.2.0 Rev3 (from MSYS2) / 7.2.0 Rev1 (from cmd.exe) > Adding -dcore-lint does not change the outcome. New description: Have these two files in a directory: Main.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import Helper main = return () test }}} Helper.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Helper where import Language.Haskell.TH test :: Q [Dec] test = return [] }}} If compiled with `ghc Main.hs`, the compilation freezes, when it reaches `Main`. This compiles without problems on Linux (Ubuntu 18) using GHC 8.6.3, and there is no problem in GHC 8.4.3 on either Windows or Linux. GCC version: 8.2.0 Rev3 (from MSYS2) / 7.2.0 Rev1 (from cmd.exe) Adding -dcore-lint does not change the outcome. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 15:17:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 15:17:15 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.26e602f6dc484471e94c69a349ffbc49@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Indeed it sounds like the current optimisation is broken. This is a bit surprising given that this is tested in the testsuite. Have you tried raising `-fmax-inline-memset-insns`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 15:26:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 15:26:53 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.f3e87889d7fc87dfe216ff503e475fd2@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer * milestone: => 8.9 Comment: Actually, now that I think of it, I believe the problem is that we don't know enough about the `ByteArray#`'s alignment for the inline memset logic to fire, given the current implementation. The current implementation is (found in `compiler/nativeGen/X86/CodeGen.hs`) is too strict in its condition: {{{#!hs genCCall dflags _ (PrimTarget (MO_Memset align)) _ [dst, CmmLit (CmmInt c _), CmmLit (CmmInt n _)] _ | fromInteger insns <= maxInlineMemsetInsns dflags && align .&. 3 == 0 = do }}} Another problem is that the codegen logic (`StgCmmPrim.doSetByteArrayOp`) makes too weak a claim about the alignment. It claims that the region is merely byte-aligned, even if the offset is aligned. Given that we know that the beginning of the bytearray is aligned to 16-bytes, we should be able to do better here (and the copy primops). Fixing this would be a nice project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 16:23:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 16:23:10 -0000 Subject: [GHC] #16056: Hadrian failure: Values have changed since being depended upon In-Reply-To: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> References: <046.073c9b8faaa9328d418f47c3944842e8@haskell.org> Message-ID: <061.c24204101dd4c6217d8d712ff80fb05b@haskell.org> #16056: Hadrian failure: Values have changed since being depended upon -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #15971 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #15971 Comment: Oh dear, how embarrassing! A duplicate of my own ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 16:26:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 16:26:16 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.c6108544414eafeab93ccc0139bb1b57@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 16:38:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 16:38:28 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.e2d7e6f16f8a3109d9aa3014ccfaf229@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | 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): * priority: high => highest * cc: alpmestan (added) * milestone: => 8.8.1 Comment: I haven't quite finished bisecting yet but I strongly suspect that this is due to the Cabal changes introduced in fb9971607c5a41ade71338188c683ee9cb8ca6fc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 16:49:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 16:49:27 -0000 Subject: [GHC] #16055: libffi build logic is quite spread out In-Reply-To: <049.69c0585ce2ec738f86fe1ddce161d6b4@haskell.org> References: <049.69c0585ce2ec738f86fe1ddce161d6b4@haskell.org> Message-ID: <064.59541128fb4a9bb61775fc753fbdfcdb@haskell.org> #16055: libffi build logic is quite spread out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: alpmestan, snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 16:53:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 16:53:13 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.00569819ffa0b7c185639af7198a5468@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yeah I've started taking a look at it, I can't reproduce it in HEAD nor can I with 8.6.2, only 8.6.3. Where it ends is an endless loop in {{{ #0 0x0000000003d53506 in interpretBCO (cap=0x4604380 ) at rts\Interpreter.c:395 #1 0x0000000003d588b7 in schedule (initialCapability=initialCapability at entry=0x4604380 , task=, task at entry=0x4d6ef00) at rts\Schedule.c:458 #2 0x0000000003d5914b in scheduleWaitThread (tso=0x7505ba8, ret=ret at entry=0x0, pcap=pcap at entry=0x4cdfd18) at rts\Schedule.c:2533 #3 0x0000000003d50968 in rts_evalLazyIO (cap=cap at entry=0x4cdfd18, p=p at entry=0x3d9f0d8 , ret=ret at entry=0x0) at rts\RtsAPI.c:530 #4 0x0000000003d4fc95 in hs_main (argc=, argv=, main_closure=0x3d9f0d8 , rts_config=...) at rts\RtsMain.c:72 }}} But since it's a release build everything has been optimized out. I started a debug build of 8.6.3 to see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 17:07:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 17:07:36 -0000 Subject: [GHC] #16054: Unable to build stage3 with hadrian In-Reply-To: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> References: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> Message-ID: <064.50cd0257159a92dc5423f92fa1a509de@haskell.org> #16054: Unable to build stage3 with hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 17:54:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 17:54:52 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.8b3e824ff2f7d6bea4ab752789510be7@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.7 Resolution: | Keywords: Data.Fixed, | Show, newcomer 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 supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 18:50:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 18:50:32 -0000 Subject: [GHC] #16058: GHC built on macOS Mojave nondeterministically segfaults Message-ID: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> #16058: GHC built on macOS Mojave nondeterministically segfaults -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- I am seeing perhaps a quarter of GHC builds on the GitLab Darwin builder (running Mojave) fail with a segfault in `ghc-stage1`. Unfortunately I've been entirely unable to reproduce this in a debugger (which isn't surprising given the low probability of the crash manifesting). Given that we haven't seen this in any Darwin builds until now I'm suspicious of either the XCode toolchain or Mojave itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 18:55:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 18:55:30 -0000 Subject: [GHC] #16058: GHC built on macOS Mojave nondeterministically segfaults In-Reply-To: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> References: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> Message-ID: <061.7bfba94c34c4390670af3485441afbd4@haskell.org> #16058: GHC built on macOS Mojave nondeterministically segfaults -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 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 bgamari): One such crash https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/1857. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 19:44:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 19:44:53 -0000 Subject: [GHC] #16054: Unable to build stage3 with hadrian In-Reply-To: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> References: <049.b64da234f183ed7471f5aea0bd18292a@haskell.org> Message-ID: <064.6738b2fa5db60f109dd195ec71605ccd@haskell.org> #16054: Unable to build stage3 with hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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:D5458 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D5458 Comment: See D5458 for a patch which seems to get us most of the way there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 19:59:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 19:59:39 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.ac027c8d0bbf5004e732a59f287f0a2a@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I’m going to try to fix this. You’ve listed two problems: 1. Condition too strong 2. Weak alignment claim I don’t understand problem the first one. As far as I can tell, the condition is that the length of the region is less than 128 and that the memory is four-byte aligned. If anything, this condition seems too weak on 64-bit platforms (but correct on 32-bit platforms). I don’t know how the NCG normally deals with the 32 bit vs 64 bit distinction in other places. But the second problem, I agree that that seems like a problem. It’s probably difficult to add a better test for this once it’s fixed. It would need to compile starting with STG, not Cmm (which is what the current test does), and go all the way down to asm. But it might be brittle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 20:22:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 20:22:42 -0000 Subject: [GHC] #16055: libffi build logic is quite spread out In-Reply-To: <049.69c0585ce2ec738f86fe1ddce161d6b4@haskell.org> References: <049.69c0585ce2ec738f86fe1ddce161d6b4@haskell.org> Message-ID: <064.fb8779333b275df172c7afdd8ebc80db@haskell.org> #16055: libffi build logic is quite spread out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 snowleopard): > The problem here is that the two modules are completely unrelated to each other. Note that the situation is the same across all build rules, not just `libffi`: the build rule and the command line flags of the corresponding builder(s) are specified in different modules. > 1. Modify the Make builder to take an additional argument which indicates whether to add the install flag. This may be consistent with so-called builder modes, e.g. see `GhcMode`, `ArMode`, etc. We could have `MakeMode`, one possible choice could be: {{{ data MakeMode = Default | BuildGMP | InstallLibFFI }}} Not only this allows us to get red of stringly-typed builder `Make FilePath`, but also it makes it clearer that some invocations of Make pass the `install` flag. This seems to be more consistent with how things are currently done, although we could of course have exceptions if they make code clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 20:48:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 20:48:51 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.dae29ddaaf6d059502e42e59f3d4fb82@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Confirmed. fb9971607c5a41ade71338188c683ee9cb8ca6fc is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 21:49:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 21:49:08 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.921b51eb4347737b2ea94720820d0882@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * priority: normal => highest Comment: Bisected to `ed86e3b531322f74d2c2d00d7ff8662b08fabde6`. Now the question is why.. rebuilding stage2 without rebuilding any of the libs works.. The change somehow causes an invalid info table to be created, this triggers a segfault {{{ Thread 1 received signal SIGSEGV, Segmentation fault. 0x0000000002dc3602 in interpretBCO (cap=0x36da520 ) at rts\Interpreter.c:395 395 switch ( get_itbl(obj)->type ) { }}} Which jumps to the signal handlers, which try to recover from the error in order to print the call stack, and ends up triggering the segfault again. Causing the infinite loop. The signal handler looping I have a patch for that I will upstream next week (need to split it from another patch), however the question is why the info table becomes invalid with this patch.. {{{ (gdb) p *obj $1 = {header = {info = 0xec003ac00000000}, payload = 0xec004d8} (gdb) p obj->info There is no member named info. (gdb) p obj->header.info $2 = (const StgInfoTable *) 0xec003ac00000000 (gdb) p *obj->header.info Cannot access memory at address 0xec003ac00000000 }}} Note that this doesn't fail in HEAD, so I don't think the change is actual cause.. Just exposing it. Another question remains.. do we not have any actual TH tests in the testsuite??? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 16 22:26:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Dec 2018 22:26:19 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.7ff1158fcf7c004ab3b99ec0b13a77ad@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 Phyx-]: > Another question remains.. do we not have any actual TH tests in the testsuite??? We certainly do—see the `testsuite/tests/th` directory. I have no idea if any of those tests are exercising this particular code path, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 01:21:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 01:21:25 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.bdb046ec3e2db0438c7cde3bcb5985b9@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | 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:D5169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5169 Comment: I see; this will be fixed when we merge Phab:D5169, which is in my merge queue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 03:12:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 03:12:19 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym Message-ID: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (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: -------------------------------------+------------------------------------- GHC throws an error message on this code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where f :: forall b (a :: Eq b => b). Int f = 42 }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20181211: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:6: error: • Illegal constraint in a kind: Eq b => b • In the type signature: f :: forall b (a :: Eq b => b). Int | 6 | f :: forall b (a :: Eq b => b). Int | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, it does //not// throw an error message if you hide `Eq b => b` behind a type synonym, as the following variant of the code above is accepted: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where type Foo b = Eq b => b f :: forall b (a :: Foo b). Int f = 42 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 04:18:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 04:18:19 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.57e160d25c3d71675cc6f2e17206c557@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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): The culprit appears to be [http://git.haskell.org/ghc.git/blob/ebb7613a66a784fc0015e13a6379453e6d5af44d:/compiler/typecheck/TcValidity.hs#l536 these lines] of `check_syn_tc_app`: {{{#!hs = do { -- See Note [Liberal type synonyms] ; liberal <- xoptM LangExt.LiberalTypeSynonyms ; if not liberal || isTypeFamilyTyCon tc then -- For H98 and synonym families, do check the type args mapM_ check_arg tys else -- In the liberal case (only for closed syns), expand then check case tcView ty of Just ty' -> let syn_tc = fst $ tcRepSplitTyConApp ty err_ctxt = text "In the expansion of type synonym" <+> quotes (ppr syn_tc) in addErrCtxt err_ctxt $ check_type env ctxt rank ty' Nothing -> pprPanic "check_tau_type" (ppr ty) } }}} When checking a type synonym application (like `Foo`) without `LiberalTypeSynonyms` enabled, then we don't check the expanded type at all—we only check the arguments! As a consequence, we never validity-check the underlying `Eq b => b` that is lurking behind the scenes in `f :: forall b (a :: Foo b). Int`. (This also reveals that enabling `LiberalTypeSynonyms` will cause the program to be rejected as well.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 06:16:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 06:16:41 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.33ef7aa3a055edd3c056d703e5792bbb@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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:D5454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c42eb2e67ae7f1e77c7bf365b7a41f808bc606cc/ghc" c42eb2e6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c42eb2e67ae7f1e77c7bf365b7a41f808bc606cc" Hadrian: introduce userDefaultFlavour, making default flavour overridable This patch introduces the `userDefaultFlavour` user setting. It should be the name of the default flavour to use when no --flavour argument is passed. Before this patch, we would just always default to... the `default` flavour. With this patch, we default to whatever Flavour whose name is `userDefaultFlavour`, therefore providing a way for users to "persist" their choice of flavour, not having to repeat --flavour=[...] in every hadrian command. Test Plan: Set `userDefaultFlavour = "quickest"`, run `hadrian/build.sh`, check that the quickest flavour is indeed picked. Reviewers: snowleopard, bgamari Reviewed By: snowleopard Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15890 Differential Revision: https://phabricator.haskell.org/D5454 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 08:28:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 08:28:30 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.21757b60e572ad933faae09b3e102095@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): I agree. For equality mis-matches, GHC already tries not to report `T Int` does not match `T Int`, by seeing if the only differences are in the kinds. (The logic is in `TcErrors.pprWithExplicitKindsWhenMismatch`.) It would be tiresome, but not hard, to do the same for instance matching, printing the kinds if the only reason for the lack of a match is in the kinds. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 09:45:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 09:45:17 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.91c0101bfdc816f935b1332600e7d945@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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): Huh. Yes, I suppose hat `Foo` is acceptable in some usage contexts (e.g. as a quantified constraint) but not others (in a kind). So we can't validity-check `Foo` on its own. So I suppose we should always validity-check the expansion, tiresome though that is. Would you like to do that? The `synIsTau` field of a `SynonymTyCon` might allow us to short-circuit the common case where the RHS is totally vanilla. (To do so we'd need to ensure that `synIsTau` is false if there is a `=>` in the RHS, not just a forall.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 09:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 09:59:52 -0000 Subject: [GHC] #16060: Missing AArch64 builds for latest GHC 8.6.3 Message-ID: <045.49f4c01ff8e0dcffd250bd7f0f507b7c@haskell.org> #16060: Missing AArch64 builds for latest GHC 8.6.3 -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Documentation | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here there is a link to AArch64, but there is no such a section: https://www.haskell.org/ghc/download_ghc_8_6_3.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 10:04:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 10:04:48 -0000 Subject: [GHC] #16061: Missing FreeBSD build for 8.6.2 Message-ID: <045.b55f15194cbbcc49ed6d712f4b24be93@haskell.org> #16061: Missing FreeBSD build for 8.6.2 -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.2 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Documentation (amd64) | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://www.haskell.org/ghc/download_ghc_8_6_2.html#freebsd11_x86_64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 11:36:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 11:36:54 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.cf9cab74e12a8e7b7add5e0e959f0464@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by simonpj): These two patches (comment:91 and comment:92) finally close this surprisingly rich ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 12:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 12:48:21 -0000 Subject: [GHC] #16062: Improve -dynamic-too progress messages Message-ID: <043.ad5c23976dc1e7038ab1cdfb3d5c0b5c@haskell.org> #16062: Improve -dynamic-too progress messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.7 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `-dynamic-too` we run the code generator twice and generate two object files: `.o` and `.o_dyn`. However the progress messages do not reflect that: {{{ $ ghc Main.hs -dynamic-too [1 of 1] Compiling Lib ( Main.hs, Main.o ) }}} I think a better message would be: {{{ [1 of 1] Compiling Lib ( Main.hs, Main.o, Main.dyn_o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 13:58:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 13:58:32 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.8cfc8bb423c35432cc9c2272d44bcf3e@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13992, #14146 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13992, #14146 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 13:59:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 13:59:12 -0000 Subject: [GHC] #13992: Error message, room for improvement (polykinds) In-Reply-To: <051.6f945668be54c814cbc564ab110fec2b@haskell.org> References: <051.6f945668be54c814cbc564ab110fec2b@haskell.org> Message-ID: <066.5c97621958da31cfce710d6b7b0b0817@haskell.org> #13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14146, #16050 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14146, #16050 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 13:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 13:59:56 -0000 Subject: [GHC] #14146: Can GHC propose kind restrictions? In-Reply-To: <051.9c4bef303d701cf3cc969a87a4fa4019@haskell.org> References: <051.9c4bef303d701cf3cc969a87a4fa4019@haskell.org> Message-ID: <066.f46e184552ea3d7141a490a122ea7678@haskell.org> #14146: Can GHC propose kind restrictions? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13992, #16050 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13992, #16050 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 14:26:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 14:26:05 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.09797ea2fdb0421e5c1e6ee22f5cdd30@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | 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 alpmestan): * differential: Phab:D5169 => Comment: Herbert, could you provide me with instructions to reproduce those issues? Even if it requires running a container/VM or something. I'm afraid that's the kind of problem that's hard to debug without some degree of interactivity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 14:27:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 14:27:19 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.623302852255144aa7366c96ef0354d1@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | 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:D5169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: => Phab:D5169 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 14:50:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 14:50:39 -0000 Subject: [GHC] #16044: Transition to C11 memory model In-Reply-To: <043.054a438919fd40e60f8103a09032ee12@haskell.org> References: <043.054a438919fd40e60f8103a09032ee12@haskell.org> Message-ID: <058.0fb599628a306f1c7daa9a3e3d65acd2@haskell.org> #16044: Transition to C11 memory model -------------------------------------+------------------------------------- Reporter: ulan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 16:30:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 16:30:35 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.62a1c94912596e71ac68a41b7104c2c1@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by chessai): * owner: (none) => chessai * related: #13992, #14146 => Comment: I can work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:15:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:15:28 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.b099c17e0ba010679845e21ddc87cf6a@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks plausible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:21:32 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.06259e05297eeebac2384ebadb6d6610@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13992, #14146 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13992, #14146 Comment: (The related tickets were removed for some mysterious reason.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:24:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:24:43 -0000 Subject: [GHC] #16058: GHC built on macOS Mojave nondeterministically segfaults In-Reply-To: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> References: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> Message-ID: <061.ecffbf8fd69278cb2b15043ee5799b72@haskell.org> #16058: GHC built on macOS Mojave nondeterministically segfaults -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 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 bgamari): For the record I have seen this while using both `gcc` and Apple's `clang`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:31:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:31:12 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.ed08c7c6b0b539ca999b4f5e8c76551d@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > As far as I can tell, the condition is that the length of the region is less than 128 and that the memory is four-byte aligned. If anything, this condition seems too weak on 64-bit platforms (but correct on 32-bit platforms). I don’t know how the NCG normally deals with the 32 bit vs 64 bit distinction in other places. We could use sub-word-sized stores in the case of non-aligned offsets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:33:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:33:31 -0000 Subject: [GHC] #16048: Show Instance for IOException discards error code In-Reply-To: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> References: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> Message-ID: <064.ac1a71087c0a667e37f9e3c8a3cf7923@haskell.org> #16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: The error code sounds to me like a reasonable thing to include. Patches welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:45:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:45:09 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.083fdd533c755a8716df98dd49d69417@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5381 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"22c2865ad5417b94ffd24ea55882722d7b5d19c4/ghc" 22c2865a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22c2865ad5417b94ffd24ea55882722d7b5d19c4" gitlab-ci: Disable Hadrian linting on Windows The lint checks currently fail due to #15950. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:45:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:45:09 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.ccb622f9fd85537f6c68a4bf076f505a@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ebe8438cd29448291229d5ce23c9f73216e9650/ghc" 1ebe8438/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ebe8438cd29448291229d5ce23c9f73216e9650" StgCRun: Disable unwinding on Darwin See #15207. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:51:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:51:28 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.9981cfbe1adcd44b7404c63a22555c08@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:52:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:52:10 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.68e47a233d791e1d0315c171c11610ac@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5381 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sigh, that was supposed to refer to #15971. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:55:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:55:28 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.4960121a0e9f55eb82b6f8a9b69a83f9@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Can you include the output from building with `ghc -v3`? That would help us at least pin down what compilation phase has slowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:56:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:56:08 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.3a24b4313903bf06e88c4303c1f9ecf1@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Perhaps also add `-ddump-timings`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 17:57:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 17:57:46 -0000 Subject: [GHC] #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") In-Reply-To: <042.d2a891901a0626563f3984239b07084f@haskell.org> References: <042.d2a891901a0626563f3984239b07084f@haskell.org> Message-ID: <057.ca55945ce2df626fe88678d645f62a75@haskell.org> #16053: GHC build regression ("HSghc-prim-0.5.3.p_o: copyFile: does not exist") -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (make) | 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:D5169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged with de56a67acf39098dd94693c6e265dfaade867d2f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 18:03:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 18:03:37 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.2a093a67b2fdb4c1a02b00b35c28df44@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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): Replying to [comment:2 simonpj]: > So I suppose we should always validity-check the expansion, tiresome though that is. > > Would you like to do that? I tried this, and while this fixes this particular program, it introduces a myriad of test failures elsewhere: {{{ Unexpected results from: TEST="Dep05 T13035 T14515 T9858a syn-perf2 tc160 tc238" }}} These can be categorized into the following categories: * Unexpected failures (`T14515`, `tc160`, `T9858a`) This is tricky. Consider the following minimized example: {{{#!hs {-# LANGUAGE RankNTypes #-} module A where type Foo = forall a. a -> a }}} {{{#!hs module B where import A foo :: Foo -> a -> a foo f x = f x }}} Currently, GHC HEAD accepts `B`. If we apply your suggested change, however, it is rejected: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 B.hs [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) B.hs:5:8: error: • Illegal polymorphic type: forall a1. a1 -> a1 Perhaps you intended to use RankNTypes or Rank2Types • In the expansion of type synonym ‘Foo’ In the type signature: foo :: Foo -> a -> a | 5 | foo :: Foo -> a -> a | ^^^^^^^^^^^^^ }}} Is this desirable? FWIW, GHC 8.6 also rejects `B`—it's only the current GHC HEAD that accepts it. * Timeouts (`T13035`, `tc238`, `syn-perf2`) It appears that having to fully expand every type synonym for validity- checking purposes imposes quite a bit of runtime cost. * Error message wibbles (`Dep05`) This happens simply because the more aggressive validity checking happens earlier now: {{{#!diff diff -uw "safeHaskell/unsafeLibs/Dep05.run/Dep05.stderr.normalised" "safeHaskell/unsafeLibs/Dep05.run/Dep05.comp.stderr.normalised" --- safeHaskell/unsafeLibs/Dep05.run/Dep05.stderr.normalised 2018-12-17 08:54:30.765476910 -0500 +++ safeHaskell/unsafeLibs/Dep05.run/Dep05.comp.stderr.normalised 2018-12-17 08:54:30.765476910 -0500 @@ -1,3 +1,23 @@ -Dep05.hs:5:1: - GHC.Arr: Can't be safely imported! The module itself isn't safe. +Dep05.hs:9:1: + Illegal unboxed tuple type as function argument: + (# GHC.Prim.State# s, a #) + Perhaps you intended to use UnboxedTuples + In the expansion of type synonym ‘GHC.ST.STRep’ + When checking the inferred type + bad2 :: forall s e a. + GHC.Prim.MutableArray# s e + -> (Int, e) -> GHC.ST.STRep s a -> GHC.ST.STRep s a + +Dep05.hs:11:1: + Illegal unboxed tuple type as function argument: + (# GHC.Prim.State# s, Array i e #) + Perhaps you intended to use UnboxedTuples + In the expansion of type synonym ‘GHC.ST.STRep’ + When checking the inferred type + bad3 :: forall i s e. + i + -> i + -> Int + -> GHC.Prim.MutableArray# s e + -> GHC.ST.STRep s (Array i e) }}} This isn't too big of a deal, since we can suppress the new error message by enabling `UnboxedTuples`. > The `synIsTau` field of a `SynonymTyCon` might allow us to short-circuit the common case where the RHS is totally vanilla. (To do so we'd need to ensure that `synIsTau` is false if there is a `=>` in the RHS, not just a forall.) That would work for this particular example, although there will likely be //other// validity checks that can't take advantage of this `synIsTau` shortcut. In fact, the original place I discovered this bug was in the context of a WIP patch I have which adds visible dependent quantification (i.e., [https://github.com/ghc-proposals/ghc- proposals/blob/36070b13d3f0970cda1faebc76afc220483340d6/proposals/0035 -forall-arrow.rst this GHC proposal]). I discovered that GHC rejects this (since we can't yet have visible dependent quantification in the type of a term): {{{#!hs f :: forall k -> k -> Bool f = undefined }}} But //does// accept this: {{{#!hs type Foo = forall k -> k -> Bool f :: Foo f = undefined }}} The reason this happens is for the same reason as the original program in this ticket, so it would be nice if we could come up with a fix that covers both programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 18:08:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 18:08:01 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.a928e6842e869b864f62814c37d0522f@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Phab:D5436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:7 carter]: > @Ben: your logic means that clang will do " #define FALLTHROUGH GNU_ATTRIBUTE(fallthrough)" > > is that what you want? I don't understand. After this patch `FALLTHROUGH` should be defined as {{{#!c #define FALLTHROUGH ((void)0) }}} Right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 18:10:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 18:10:50 -0000 Subject: [GHC] #16047: Incorrect hscTarget in DynFlags when building hs-boot files In-Reply-To: <043.e06f5cca4c2b09a29027db21c584c6e5@haskell.org> References: <043.e06f5cca4c2b09a29027db21c584c6e5@haskell.org> Message-ID: <058.2f74a72c65ae8306a5c1a2f6bde4185e@haskell.org> #16047: Incorrect hscTarget in DynFlags when building hs-boot files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Are you seeing some adverse effect due to the current setting of `hscTarget`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 18:11:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 18:11:46 -0000 Subject: [GHC] #16019: Harbormaster: OS X build fails In-Reply-To: <047.60bba0568024ee8f0292c613569e5373@haskell.org> References: <047.60bba0568024ee8f0292c613569e5373@haskell.org> Message-ID: <062.7d1441eab2ed380604ed20ec696c6a08@haskell.org> #16019: Harbormaster: OS X build fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Runtime System | Version: 8.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14613 | Differential Rev(s): Phab:D5436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 19:36:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 19:36:27 -0000 Subject: [GHC] #16046: -fno-stack-protector still necessary? In-Reply-To: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> References: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> Message-ID: <061.6300e938641fbb8575bab83b0d8f1f09@haskell.org> #16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.4.3 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: Interesting. Initially this change was added for openbsd specifically for ghc-6.5: changeset:f638fdfe1d9de1307355c8074fbff9c28342c0ef (2006) and later it was extended to cover osx: changeset:c2cd83e7d85c11e6a33e1cde263eb2312566d535 (2009) None of the reports hint at exact breakage. I guess both happened in -fvia-C mode where GHC's Evil Mangler had a chance to mangle stack canaries generated by fstack-protector. As ghc has no evil mangler anymore it could work. I'll prepare a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 20:54:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 20:54:49 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.6891a5dbda8698de1e2c6fe067aff260@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13992, #14146 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): This looks to be the same problem, but for equality: {{{ #!haskell {-# LANGUAGE GADTs, TypeOperators, PolyKinds #-} import GHC.Types data a :~: b where Refl :: a :~: a foo :: TYPE a :~: TYPE b foo = Refl }}} gives an error message {{{ • Couldn't match type ‘'LiftedRep’ with ‘'LiftedRep’ ‘a’ is a rigid type variable bound by the type signature for: foo :: * :~: * at Repr.hs:7:1-24 ‘b’ is a rigid type variable bound by the type signature for: foo :: * :~: * at Repr.hs:7:1-24 }}} To see the problem, you need to use `-fprint-explicit-runtime-reps`. (I'm not sure if this should be a separate ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 21:13:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 21:13:06 -0000 Subject: [GHC] #15923: Skip performance tests if not in a git repo In-Reply-To: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> References: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> Message-ID: <060.d41de4f597a3227b6d120da1374349a8@haskell.org> #15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: closed Priority: high | Milestone: Component: Test Suite | Version: 8.6.2 Resolution: fixed | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5367 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Changes (by davide): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:18:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:18:29 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.36b1b39d8613b074159b55d487155fe0@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by augustss): * Attachment "ghc-8.4.4-compile.stdout.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:18:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:18:45 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.b454f0b54c23cfcf95166dab0f1d61da@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by augustss): * Attachment "ghc-8.4.4-compile.stderr.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:24:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:24:02 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure Message-ID: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am trying to build this library: https://github.com/GaloisInc/grift The build works perfectly on my Mac OS X system under ghc-8.4.4 via the README instructions. However, if I update to ghc-8.6.3, I get the following error: {{{ Building library for bv-sized-float-0.1.0.. [1 of 2] Compiling Data.BitVector.Sized.Float ( src/Data/BitVector/Sized/Float.hs, /Users/benselfridge/grift/dist- newstyle/build/x86_64-osx/ghc-8.6.3/bv-sized- float-0.1.0/build/Data/BitVector/Sized/Float.o ) [2 of 2] Compiling Data.BitVector.Sized.Float.App ( src/Data/BitVector/Sized/Float/App.hs, /Users/benselfridge/grift/dist- newstyle/build/x86_64-osx/ghc-8.6.3/bv-sized- float-0.1.0/build/Data/BitVector/Sized/Float/App.o ) ghc: loadArchive: Failed reading header from `/Users/benselfridge/grift /dist-newstyle/build/x86_64-osx/ghc-8.6.3/softfloat- hs-0.1.0/build/SoftFloat' ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): loadArchive "/Users/benselfridge/grift/dist- newstyle/build/x86_64-osx/ghc-8.6.3/softfloat-hs-0.1.0/build/SoftFloat": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The library "softfloat-hs" is a Haskell library that calls C functions that are dynamically linked. If I try to run it within this project via "cabal new-repl softfloat-hs", the dependency works fine. It's only when I try to build "bv-sized-float", which depends on softfloat-hs, that I get the above error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:49:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:49:19 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.1030c83cf9bde88a31c5eabdeaacab89@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by augustss): * Attachment "ghc-8.6.3-compile.stdout.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:49:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:49:35 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.8ac5014aeaead30d4e7d1b2e70df54f6@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by augustss): * Attachment "ghc-8.6.3-compile.stderr.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:51:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:51:02 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.1728dc8740defa393adae5ebe2ff5804@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 augustss): I've added some compiler output. The slowest file, OneDUInstructionFrag.hs is quite short (185 lines), but uses Generic heavily for deriving instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 17 22:52:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Dec 2018 22:52:28 -0000 Subject: [GHC] #16032: Compile speed regression In-Reply-To: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> References: <047.af0194e0855047cbec7a63c66a62be5c@haskell.org> Message-ID: <062.6ff89e2cbbe648198e3c5369bf7d1010@haskell.org> #16032: Compile speed regression -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Thanks Lennart! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 01:13:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 01:13:03 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.de7662132c3135408d18af65ba390406@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmmm, that archive name doesn't look quite right. I tried to reproduce this but ran into two issues: * I do not have root access to a macOS box; can you modify the `install` rule of `softfloat-hs` to accomodate non-root users? * the commit 1d4010468c307c7262fc66c3d1caeb3b3d468640 of `test/riscv- tests` is not reachable via any branch: {{{ $ git submodule update error: Server does not allow request for unadvertised object 1d4010468c307c7262fc66c3d1caeb3b3d468640 Fetched in submodule path 'test/riscv-tests', but it did not contain 1d4010468c307c7262fc66c3d1caeb3b3d468640. Direct fetching of that commit failed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 01:13:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 01:13:14 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.77ff5f94b44ebd3ba64710ccba97867b@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 01:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 01:21:28 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.553f4b32669d8a0bdd8981dc3563ffae@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * cc: AndreasK (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 04:37:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 04:37:28 -0000 Subject: [GHC] #15995: Make Control.Concurrent.QSem a newtype In-Reply-To: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> References: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> Message-ID: <061.bfdccb8393bcf464b29d0aba2a8b1f11@haskell.org> #15995: Make Control.Concurrent.QSem a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.6.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 Ben Gamari ): In [changeset:"f5e98bb31cf4dae740c8dc598ef207aa79d5a179/ghc" f5e98bb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5e98bb31cf4dae740c8dc598ef207aa79d5a179" make QSem and QSemN newtypes Reviewers: RyanGlScott, ekmett, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15995 Differential Revision: https://phabricator.haskell.org/D5456 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 04:37:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 04:37:28 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found In-Reply-To: <042.925a06cf3801c7d8163448594b84be93@haskell.org> References: <042.925a06cf3801c7d8163448594b84be93@haskell.org> Message-ID: <057.21fab1c41114eea8df203349f0de904f@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5424 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"126aa794743b807b7447545697b96dd165ec3e16/ghc" 126aa79/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="126aa794743b807b7447545697b96dd165ec3e16" Add missing comma in 'libdw' configure check Fix a bug from cb882fc993b4972f7f212b291229ef9e9ade0af9. Without the comma, all non-diverging codepaths set 'UseLibdw=NO'. Reviewers: bgamari, nh2 Reviewed By: nh2 Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15968 Differential Revision: https://phabricator.haskell.org/D5459 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 05:08:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 05:08:31 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found In-Reply-To: <042.925a06cf3801c7d8163448594b84be93@haskell.org> References: <042.925a06cf3801c7d8163448594b84be93@haskell.org> Message-ID: <057.74976c29ad72c11c977ebd5de553254d@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | 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:D5424 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 05:08:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 05:08:41 -0000 Subject: [GHC] #15995: Make Control.Concurrent.QSem a newtype In-Reply-To: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> References: <046.bc96e80d6ffe6eb91bf8e8f9ed01b26f@haskell.org> Message-ID: <061.02bc3ab8d64d4994d260b84b4a7e77db@haskell.org> #15995: Make Control.Concurrent.QSem a newtype -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 05:13:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 05:13:00 -0000 Subject: [GHC] #16047: Incorrect hscTarget in DynFlags when building hs-boot files In-Reply-To: <043.e06f5cca4c2b09a29027db21c584c6e5@haskell.org> References: <043.e06f5cca4c2b09a29027db21c584c6e5@haskell.org> Message-ID: <058.bd7a1999a24208431d8067215f7b090f@haskell.org> #16047: Incorrect hscTarget in DynFlags when building hs-boot files -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Yes, I can't use `hscTarget` reliably in my code but it's sometimes incorrect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 06:16:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 06:16:40 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.4f90faa2d87c3d3f31c853ce9e73f49d@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by benselfridge): Removed the riscv-tests submodule, so that shouldn't be an issue anymore if you clone grift again. I removed the sudo calls in the Makefile (they probably shouldn't have been there anyway), but I'm not sure if that will do the trick for you -- softfloat-hs needs to dynamically link against pre-compiled C libraries in /usr/lib or /usr/local/lib, and they have to be installed there or runtime will crash. Is there no way for you to run make install inside softfloat- hs? -Ben -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 09:20:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 09:20:17 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.e09d6c6eb7729522790533f87e6e9d38@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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): `T14515` and friends. I think it's reasonable to reject. Type synonyms are not proper abstractions; they are more like macros. The current behaviour: * Triggers unexpected new errors when you switch on `LiberalTypeSynonyms`. * Ditto if you manually expand a synonym, which should be innocuous. ---------------- '''Timeouts'''. Look at `tc238`. I thought at first that we were simply making an exponentially large type, as we easily could do: {{{ type T1 = Int -> Int -- Size = N type T2 = T1 -> T1 -- Size = 2N type T3 = T2 -> T2 -- Size = 4N .. }}} For such programs, I think it'd be fine to time out; we'd time out when ''using'' such a large synonym anyway. But that is NOT what is happening here. For `tc238` we have {{{ data T i r c = K (c i) (r c) type TIACons2 t x = T t (T t x) type TIACons3 t x = TIACons2 t (TIACons1 t x) type TIACons4 t x = TIACons2 t (TIACons2 t x) type TIACons7 t x = TIACons4 t (TIACons3 t x) type TIACons8 t x = TIACons4 t (TIACons4 t x) }}} So `TIACons2` has two occurrences of `T`; `TIACons3` has three, `TIACons4` has four; and so on. The number in the name indicates the number of occurrences of T. Big but not exponential. The problem comes because at each synonym we check validity with and without expansion. So if we have {{{ type S = ... f :: S (S (S (S (S (S ....(S Int)...)))) }}} we'll typecheck the outer S application with and without expansion; and in ''each'' of those checks we'll check the next S application with and without... result exponential! This goes right back to Trac #323, 14 years ago. What to do? In general, we can't check both with and without expansion. So we could do one of these: 1. Always expand. That is simple and sound, but I suppose that it might occasionally yield a worse error message. 2. Always expand; but if you get an error message, then try without expansion to see if you also get an error; in the latter case report the latter error message not the former. 3. Within the validity checker have a 3-way flag: Expand, NoExpand, Both. For Liberal start with Expand; for non-Liberal start with Both. Now at a synonym, in the Both case, switch to NoExpand when checking the non-expanded version, and to Both when checking the expanded version. I think (1) seems like a simpler starting point. ------------ I agree about `synIsTau`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 12:03:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 12:03:29 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.5e91561bad475b37bcc87691f981367e@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Old description: > My team has observed a 2x performance degradation in code that makes use > of `StateT` that appears to be related to strictness and unboxing, even > when built with `-O2`. Our code makes heavy use of the state monad, and > when GHC fails to optimise this performance > > We've managed to minimise the behaviour to the following reproducer (that > ignores state entirely), consisting of two files. It depends on > `criterion` > > `Lib.hs`: > > {{{#!hs > {-# LANGUAGE BangPatterns #-} > > module Lib where > > -- A type to take the place of state > data X a = X { runX :: !a } > > test1 :: Int -> Int > test1 = \(!i) -> go i where > go = \(!i) -> if i > 0 > then go $! i - 1 > else i > {-# NOINLINE test1 #-} > > test2 :: Int -> Int > test2 = \(!i) -> runX (go i) where > go = \(!i) -> if i > 0 > then go $! i - 1 > else X i > {-# NOINLINE test2 #-} > }}} > > `Main.hs`: > > {{{#!hs > {-# LANGUAGE Strict #-} > module Main where > > import Lib > import Criterion > import Criterion.Main > > main :: IO () > main = defaultMain > [ bgroup "main" > [ bgroup "small" > [ bench "without state" $ whnf test1 100000000 > , bench "with state" $ whnf test2 100000000 > ] > ] > ] > }}} > > Run as above, the code takes twice as long to execute `test2` as it does > `test1`. However, when the signature for `runX` is changed to `runX :: > !Int`, the code in `test2` exhibits identical performance to `test1`. > > It has been reproduced across multiple linux64 machines, but not tested > on any other architecture or operating system. > > Please find the full (stack - yes, I know) project as an attachment. You > can simply `stack run` to observe the issue. If you have any further > queries please let me know. New description: My team has observed a 2x performance degradation in code that makes use of `StateT` that appears to be related to strictness and unboxing, even when built with `-O2`. Our code makes heavy use of the state monad, and when GHC fails to optimise this usage, the performance becomes untenably slow. We've managed to minimise the behaviour to the following reproducer (that ignores state entirely), consisting of two files. It depends on `criterion` `Lib.hs`: {{{#!hs {-# LANGUAGE BangPatterns #-} module Lib where -- A type to take the place of state data X a = X { runX :: !a } test1 :: Int -> Int test1 = \(!i) -> go i where go = \(!i) -> if i > 0 then go $! i - 1 else i {-# NOINLINE test1 #-} test2 :: Int -> Int test2 = \(!i) -> runX (go i) where go = \(!i) -> if i > 0 then go $! i - 1 else X i {-# NOINLINE test2 #-} }}} `Main.hs`: {{{#!hs {-# LANGUAGE Strict #-} module Main where import Lib import Criterion import Criterion.Main main :: IO () main = defaultMain [ bgroup "main" [ bgroup "small" [ bench "without state" $ whnf test1 100000000 , bench "with state" $ whnf test2 100000000 ] ] ] }}} Run as above, the code takes twice as long to execute `test2` as it does `test1`. However, when the signature for `runX` is changed to `runX :: !Int`, the code in `test2` exhibits identical performance to `test1`. It has been reproduced across multiple linux64 machines, but not tested on any other architecture or operating system. Please find the full (stack - yes, I know) project as an attachment. You can simply `stack run` to observe the issue. If you have any further queries please let me know. -- Comment (by _recursion): Unfinished sentence in the report because I am sometimes unobservant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 13:59:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 13:59:44 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.67f0582871ff45a4b480f3b12300248b@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I'm happy to take a look once there is something to look at. > I don’t know how the NCG normally deals with the 32 bit vs 64 bit distinction in other places. A lot of code is in the spirit of `is32Bit then foo32 else foo64`. > It’s probably difficult to add a better test for this once it’s fixed. It would need to compile starting with STG, not Cmm (which is what the current test does), and go all the way down to asm. But it might be brittle. Brittle in what sense? Just grepping for calls to memset should be quite stable as far as making sure we don't emit calls like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 14:47:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 14:47:12 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.15824c557a6568f8ac614b88f7600072@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | Version: 8.2.2 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 Ben Gamari ): In [changeset:"ae4e4ba655f2d0d8a5cc8488ada628726e9cc147/ghc" ae4e4ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae4e4ba655f2d0d8a5cc8488ada628726e9cc147" Add some complexities to Data.List documentation (#15003) Namely for: - stripPrefix - isPrefixOf - intersperse - tails - map - scanl - scanl1 - scanl' - scanr - scanr1 - zip - zipWith Add examples to `zipWith` and `map`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 15:12:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 15:12:31 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.958239be15c4f2dcdd6cb2f9448578fc@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I didn't realize we could have tests that just grepped for things. That seems like exactly what I would want. I'll wait to try doing this until after the switch to gitlab is complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 15:40:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 15:40:04 -0000 Subject: [GHC] #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code Message-ID: <049.c5d88a821daeb893ad451522924a9efa@haskell.org> #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: Keywords: CodeGen, | Operating System: Unknown/Multiple Performance | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #16040, #14791, | #8326, #12231, #1498 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When generating both heap and stack checks in Cmm, GHC can sometimes be fairly obtuse about their placement. As a result, they can be generated for paths in hot code that actually do not perform any allocation. Examples can be found in the related tickets, particularly #14791 and #16040. This ticket exists to track the work [https://ghc.haskell.org/trac/ghc/ticket/16040#comment:5 proposed] by Simon to detect such code patterns. They are described as follows: 1. A primitive case with no allocation upstream from it. 2. One alternative that performs no allocation. Under such circumstances the stack/heap checks can be moved from being performed on every iteration to being performed just prior to the allocation itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 15:40:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 15:40:16 -0000 Subject: [GHC] #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code In-Reply-To: <049.c5d88a821daeb893ad451522924a9efa@haskell.org> References: <049.c5d88a821daeb893ad451522924a9efa@haskell.org> Message-ID: <064.f45c88ab0392318e6edc580768c55512@haskell.org> #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code -------------------------------------+------------------------------------- Reporter: _recursion | Owner: _recursion Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: Resolution: | Keywords: CodeGen, | Performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #16040, #14791, | Differential Rev(s): #8326, #12231, #1498 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by _recursion): * owner: (none) => _recursion -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 15:57:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 15:57:42 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.90abed96203a749bbe4282bc37ba79a8@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #4450 Comment: Just a few notes while it's still fresh in my head. I always compared two traces via `rr`. - Based on my observation that bytes copied was the first metric to diverge, I did some printf debugging in the RTS. - I noticed that the first divergence comes from copying additional blackholes. After evacuating the blackhole in trace B, it resumes 'normal' operation, e.g. does the same thing trace A would do instead of evacuating the black hole. - The black holes are evacuated when the stack is scavenged. They're pointed to by update frames, all of which originally pointed to `stg_sel_0_upd` selector thunks. - I also noticed that the `mut_list_size` output of `+RTS -Dg` varies between the two traces, and it's never because of any mutable primitives (e.g., arrays, MVars, etc.). I'm not sure what pushes (or fails to push) the update frames. Maybe it has to do with `ThreadPaused.c:stackSqueeze()`? Maybe this is related to #4450? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 16:25:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 16:25:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.d2f88687620f3a4c66442c076fe777b1@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: simonmar (added) Comment: Indeed, never making the call to `ThreadPaused.c:stackSqueeze()` gets rid of the non-determinism. So does `+RTS -V0` (which disables the master tick timer that triggers context switches, if understand correctly) as proposed in #4450 and `+RTS -Z` (which just deactivates stack squeezing completely). The latter seems like an easy fix for this particular benchmark, but this will probably come up again in the future. Maybe we can teach the RTS not do stack squeezing during context switches? CCing simonmar for input, as I'm not particularly familiar with RTS internals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 16:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 16:28:08 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.5a038e692a394eaa61d47027429a832d@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by osa1): * priority: normal => highest * owner: (none) => osa1 Comment: Bumping priority as this may cause segfaults in GHC today. I'll be looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 16:40:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 16:40:24 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.9d58bd10f994ced47f1d66e4d549fa96@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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 goldfire): The problem in this code {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where type Foo b = Eq b => b f :: forall b (a :: Foo b). Int f = 42 }}} is the ''definition'' of `Foo`, not the usage of it. As comment:3 illustrates and comment:4 elaborates, we don't really want to check the expansion of a type synonym in this way. (Hold off on considering `LiberalTypeSynonyms` for now.) Even with the rather transparent interpretation of type synonyms in GHC, I think they should offer ''some'' level of abstraction (in contrast to the position in comment:4): it seems that allowing type synonyms at least to hide what extensions are enabled is sensible. What about `LiberalTypeSynonyms`? I don't know. But let's see if we can agree on conservative synonyms first, and then we'll move to liberal ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 16:54:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 16:54:48 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.bb5dec7e4d529d24bcbc512c319ed3fb@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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): But there is nothing fundamentally wrong with `Foo`. You might write {{{ f :: Foo Int }}} which means the same as {{{ f :: Eq Int => Int }}} which is a perfectly legal type. `checkValidType` checks for reasons a type might be invalid ''other than'' its kind. Are you sure you want type synonyms to hide all the things we check thereby? TL;DR: I'm suggesting that if it's valid, it should be valid after expanding synonyms. You are suggesting that ''they should offer some level of abstraction''. I'm unconvinced. Exactly what level of abstraction? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 16:57:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 16:57:32 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.dd19506453fa41f5745094d11fb11213@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 | Differential Rev(s): Phab:D5460 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * differential: => Phab:D5460 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 17:03:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 17:03:43 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations Message-ID: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime | Version: 8.6.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4450, #8861 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As #4450 and #8611 show, stack squeezing in the RTS makes allocation numbers between two different runs of the same binary non-deterministic, because its effect is depending on when context switches are bound to happen. A short-term solution might be to deactivate stack squeezing for vulnerable benchmarks with `+RTS -Z` like in Phab:D5460, but IMO a more elegant solution would be to only deactivate stack squeezing in `threadPause` calls that happen due to context switches. Would you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 17:04:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 17:04:22 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.cff6699f3d7270bbf0d9ceb7ff21ab77@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 | Differential Rev(s): Phab:D5460 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:11 sgraf]: > The latter seems like an easy fix for this particular benchmark, but this will probably come up again in the future. Maybe we can teach the RTS not do stack squeezing during context switches? > > CCing simonmar for input, as I'm not particularly familiar with RTS internals. Continuing discussion in #16065. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 17:07:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 17:07:49 -0000 Subject: [GHC] #16059: checkValidType is defeated by a type synonym In-Reply-To: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> References: <050.4bbda0251aa0e4131d726d2fe5d57d93@haskell.org> Message-ID: <065.f51902dbd41385043a160e93c3318157@haskell.org> #16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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 goldfire): Silly me. I looked quickly and assumed that the problem was the lack of a `-XQuantifiedConstraints`. This is clearly wrong. Bah. I guess I take back my comment:5 then, as I can't see any better way out of this mess other than to implement kind-level constraints, which, in turn, requires dependent types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 17:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 17:35:12 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.f00c45371d482550088637465e6237fe@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Good catch, but I don't fully understand stack squeezing affects allocation. As far as I'm aware it should just reduce the stack size, not increase it, so it shouldn't require any extra allocation. I'm OK with putting in some fix for this to make the benchmarks stable, but I'd like to completely understand the cause first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 18:47:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 18:47:56 -0000 Subject: [GHC] #16048: Show Instance for IOException discards error code In-Reply-To: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> References: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> Message-ID: <064.6e235c8dd047bff9d72eed8e856ca42c@haskell.org> #16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): PR on github at https://github.com/ghc/ghc/pull/241 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 18:51:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 18:51:07 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.85d8f17115d2e7282636da166e0fb306@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ah, I just realised what causes the allocation: if we *don't* do stack squeezing, then the larger stack size means that we might overflow the stack in the future, which will entail allocating for the new stack chunk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 19:04:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 19:04:21 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.fa8c136d9474f0bb83f01cf620a12470@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 | Differential Rev(s): Phab:D5460 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Whoohoo, thanks for drilling down here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 19:18:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 19:18:36 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.68f190b18288c5235ce17a4ea44c89e8@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danidiaz): * cc: danidiaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 20:05:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 20:05:16 -0000 Subject: [GHC] #16066: internal error: PAP object entered! Message-ID: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> #16066: internal error: PAP object entered! ----------------------------------------+---------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: iOS Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- While trying to debug why my test didn't seem to be running, I got an internal error (below). After a clean and rebuild it happened again so it's not a flake. Unfortunately I don't know what's causing it so I can't produce an MWE, but I can link to the project and commit on GitHub: https://github.com/dspies- leapyear/persistwrap/tree/885a079923cb3eefb24db344f5e2fddee9fab425 Just run the test with: {{{ stack test persistwrap:persistwrap-test }}} {{{ Progress 9/10: persistwrap-0.1.0.0test/Driver.hs test_widget_schemas: persistwrap-test: internal error: PAP object entered! (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug persistwrap-test: SignalException 6 persistwrap-0.1.0.0: Test suite persistwrap-test failed Completed 10 action(s). Test suite failure for package persistwrap-0.1.0.0 persistwrap-test: exited with: ExitFailure (-6) Logs printed to console }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 21:11:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 21:11:39 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.dfdde8d52ac921e8f6d10870c84296fd@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): Interestingly, there appears to be some sort of check for this already, but only when kind-checking. Given this: {{{#!hs data P k :: k -> Type }}} Then GHC accept the following: {{{#!hs type Foo = forall k (a :: k). P k a }}} However, it does //not// accept the following: {{{#!hs type Bar = forall k. P k }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:22: error: • Expected kind ‘k0’, but ‘P k’ has kind ‘k -> *’ • In the type ‘forall k. P k’ In the type declaration for ‘Bar’ | 10 | type Bar = forall k. P k | ^^^ }}} The current error message doesn't really give a clear indication as to the underlying cause, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 21:50:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 21:50:35 -0000 Subject: [GHC] #15681: Take exhaustiveness checking into consideration when using MonadFailDesugaring (was: Take {-# COMPLETE #-} pragma into consideration when using MonadFailDesugaring) In-Reply-To: <047.47a45e7308c6a8ffbc7451de73cfa648@haskell.org> References: <047.47a45e7308c6a8ffbc7451de73cfa648@haskell.org> Message-ID: <062.e6f653ca0d9492770726752164d668d2@haskell.org> #15681: Take exhaustiveness checking into consideration when using MonadFailDesugaring -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: pattern- | matching,monadfail,desugaring,PatternSynonyms,PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, it turns out this problem affects more than just pattern synonyms. It also affects GADTs, too, as the following //should// compile, but doesn't: {{{#!hs {-# LANGUAGE GADTs #-} module Bug where data T a where TInt :: T Int TBool :: T Bool f :: Monad m => m (T Int) -> m () f t = do TInt <- t pure () }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:3: error: • Could not deduce (Control.Monad.Fail.MonadFail m) arising from a do statement with the failable pattern ‘TInt’ from the context: Monad m bound by the type signature for: f :: forall (m :: * -> *). Monad m => m (T Int) -> m () at Bug.hs:8:1-33 Possible fix: add (Control.Monad.Fail.MonadFail m) to the context of the type signature for: f :: forall (m :: * -> *). Monad m => m (T Int) -> m () • In a stmt of a 'do' block: TInt <- t In the expression: do TInt <- t pure () In an equation for ‘f’: f t = do TInt <- t pure () | 10 | TInt <- t | ^^^^^^^^^ }}} Again, the culprit is the fact that we're trying to determine whether a function needs a `MonadFail` constraint all the way back in the renamer/typechecker, well before the pattern-match coverage checker runs. It feels like there ought to be a way to only emit `MonadFail` constraints if the coverage checker deems a `do`-pattern match to be non-exhaustive, although I don't know how to do that... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 21:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 21:52:40 -0000 Subject: [GHC] #16067: Profiled GHCi segfaults under Windows. Message-ID: <047.a3da9be285802dfd4db4904f14511124@haskell.org> #16067: Profiled GHCi segfaults under Windows. ----------------------------------------+------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Building ghc with the prof flavour and trying to run ghci segfaults on master. {{{ C:\ghc\msys64\home\Andi\ghc_head\inplace\bin\ghc-stage2.exe --interactive GHCi, version 8.7.20181218: https://www.haskell.org/ghc/ :? for help Access violation in generated code when reading 0xffffffffffffffff Attempting to reconstruct a stack trace... Frame Code address * 0x67cd990 0x4d6634c C:\ghc\msys64\home\Andi\ghc_head\inplace\bin \ghc-stage2.exe+0x496634c * 0x67cd9f0 0x4d51848 C:\ghc\msys64\home\Andi\ghc_head\inplace\bin \ghc-stage2.exe+0x4951848 * 0x67cda50 0x4d5192f C:\ghc\msys64\home\Andi\ghc_head\inplace\bin \ghc-stage2.exe+0x495192f * 0x67cda80 0x4d678a1 C:\ghc\msys64\home\Andi\ghc_head\inplace\bin \ghc-stage2.exe+0x49678a1 * 0x67cda88 0x4c5fe64 C:\ghc\msys64\home\Andi\ghc_head\inplace\bin \ghc-stage2.exe+0x485fe64 * 0x67cda90 0x1083d0 * 0x67cda98 0x88e5020 * 0x67cdaa0 0x88e36a1 * 0x67cdaa8 0x2000000 C:\ghc\msys64\home\Andi\ghc_head\inplace\bin \ghc-stage2.exe+0x1c00000 }}} Just starting it in gdb tells me this is happening in registerCcsList in the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 22:20:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 22:20:57 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.e735de346d6cdf0ec2340fdb5bb4fd83@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by RyanGlScott): I can confirm that this code also panics on 8.6.3 (after lots of tweaking to make it compile). Alas, this repo is absolutely massive, and I haven't the slightest clue where to begin minimizing it. Any help you could provide would be massively helpful. One thing to note is that the `insertX` function appears to be important here. The program still crashes if you make the following change to `test/PersistWrap/WidgetSpec.hs`: {{{#!diff diff --git a/persistwrap/test/PersistWrap/WidgetSpec.hs b/persistwrap/test/PersistWrap/WidgetSpec.hs index 8055d52..2c9435e 100644 --- a/persistwrap/test/PersistWrap/WidgetSpec.hs +++ b/persistwrap/test/PersistWrap/WidgetSpec.hs @@ -47,6 +47,7 @@ widgetAssertions = atomicTransaction $ do w1 = Blarg (False, True, BS.pack "hello world") w2 = Glorp fk3 fkw1 <- insertX @"widget" w1 + {- fkw2 <- insertX @"widget" w2 fkw3 <- insertWidget3 traceM "Hi" @@ -60,6 +61,8 @@ widgetAssertions = atomicTransaction $ do result1 `shouldBe` Just w1 result2 `shouldBe` Just w2 result3 `shouldBe` Just widget3 + -} + undefined widget3 :: Widget fk widget3 = }}} If I comment out the first two uses of `insertX` in `widgetAssertions`, however, then the crash no longer occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 23:02:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 23:02:49 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.857ddd5fd59a7bd3dedb65db7faff045@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16067 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #16067 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 23:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 23:21:29 -0000 Subject: [GHC] #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol In-Reply-To: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> References: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> Message-ID: <061.c45b595d2e678b3d734afb52111089e1@haskell.org> #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.2 Resolution: | Keywords: clang Operating System: OpenBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5461 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) * differential: => Phab:D5461 * component: Build System (make) => Runtime System Comment: Stumbled on the same failure today. Proposed change as: https://phabricator.haskell.org/D5461 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 23:24:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 23:24:53 -0000 Subject: [GHC] #15681: Take exhaustiveness checking into consideration when using MonadFailDesugaring In-Reply-To: <047.47a45e7308c6a8ffbc7451de73cfa648@haskell.org> References: <047.47a45e7308c6a8ffbc7451de73cfa648@haskell.org> Message-ID: <062.dcf0d3aea70ce4cd75ff322ffdf4d647@haskell.org> #15681: Take exhaustiveness checking into consideration when using MonadFailDesugaring -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: pattern- | matching,monadfail,desugaring,PatternSynonyms,PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The real problem here is that we are trying to ''infer'' whether any of the patterns can fail -- if so, generate a `MonadFail` constraint, but not if not. But pattern-match-coverage is a tricky thing, as the examples demonstrate. And making the generation of a constraint depend on how another set of constraints is solved is pretty thin ice. I wish it were possible to ''specify unambiguously'' whether you want `Applicative` or `Monad` or `MonadFail`. Something like `do{Monad}` or `do{Applicative}` or `do{MonadFail}`. That would be a lot clearer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 23:26:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 23:26:21 -0000 Subject: [GHC] #16067: Profiled GHCi segfaults under Windows. In-Reply-To: <047.a3da9be285802dfd4db4904f14511124@haskell.org> References: <047.a3da9be285802dfd4db4904f14511124@haskell.org> Message-ID: <062.b67ca0b2be193c2fea22eb9d109b70a7@haskell.org> #16067: Profiled GHCi segfaults under Windows. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #15808 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #15808 Comment: Pretty sure the underlying issue is similar to #15808. We get the following call stack: {{{ #0 0x0000000005e599bd in registerCcsList (cc_list=0xc2f3020) at rts\Profiling.c:326 #1 0x0000000005e42db9 in ocRunInit_PEi386 (oc=0x76a58c0) at rts\linker\PEi386.c:2031 #2 0x0000000005e42efd in ocTryLoad (oc=0x76a58c0) at rts\Linker.c:1615 #3 0x0000000005e5d9af in resolveObjs_ () at rts\Linker.c:1643 #4 0x0000000005e5d969 in resolveObjs () at rts\Linker.c:1662 #5 0x0000000005d5d0c4 in ghcizm8zi7_GHCiziObjLink_resolveObjs1_info () #6 0x00000000066f73e0 in MULTI_CHUNK_SLOW_CALL_ctr () #7 0x000000000a34d000 in ?? () }}} We call registerCcsList in the initializer functions of modules with profiling. Which then calls the rts code. The RTS and the initializer end up being farther than 2GB from each other so if any offset is limited to 32bit that will do. It seems the first pointer in cc_list is what causes the segfault (pointing to 0xfffffff225ff). But I haven't dug into it enough to find out where the overflow comes from. Likely a relocation overflow somewhere (as in #15808) but could also be some ghc internal offset. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 23:29:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 23:29:34 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms In-Reply-To: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> References: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> Message-ID: <065.b9073e901b6e0040bce6cb8dac4f3307@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 simonpj): I think comment:8 is quite a separate matter: see the kinding rule for foralls in #15791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 18 23:33:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Dec 2018 23:33:33 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.600b6b8cc7f678e7b4d0a4a218e9e706@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Augmenting {{{#!hs exprIsCheapX :: CheapAppFun -> CoreExpr -> Bool exprIsCheapX ok_app e = ok e where ok e = go 0 e -- n is the number of value arguments go n (Var v) = ok_app v n go _ (Lit {}) = True go _ (Type {}) = True go _ (Coercion {}) = True go n (Cast e _) = go n e go n (Case scrut _ _ alts) = ok scrut && and [ go n rhs | (_,_,rhs) <- alts ] go n (Tick t e) | tickishCounts t = False | otherwise = go n e go n (Lam x e) | isRuntimeVar x = n==0 || go (n-1) e | otherwise = go n e go n (App f e) | App (Var v) Type {} <- f -- added clause , v `hasKey` noinlineIdKey , isRuntimeArg e = go n e go n (App f e) | isRuntimeArg e = go (n+1) f && ok e | otherwise = go n f go n (Let (NonRec _ r) e) = go n e && ok r go n (Let (Rec prs) e) = go n e && all (ok . snd) prs }}} helped a lot :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 00:23:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 00:23:31 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.619804cd02ad0d7829f1f3cfe87d10b4@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) Comment: I can replicate and have a story for what is going wrong here, which involves 3d17f1f10fc00540ac052f2fd03182906aa47e35. I'll prepare a patch shortly, but testing it might be a bit frustrating (I doubt `grift`'s dependencies all easily build on HEAD). I'll try to put together a more minimal test case too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 00:26:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 00:26:53 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.c49b8f5b5018906d358d246659d03249@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by benselfridge): Cool, thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 01:11:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 01:11:07 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.970bcf0e056b360453aaf7451e3fe0b0@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by dnspies): I don't know about shrinking but I was able to isolate where it's happening. It's in the call to `STM`'s `return` method here: https://github.com/dspies- leapyear/persistwrap/blob/885a079923cb3eefb24db344f5e2fddee9fab425/persistwrap/src/PersistWrap/Persistable/Insert/Utils.hs#L130 I've added a `Monad2` typeclass and threaded it through the program in order to make it easy to play with the bug and get more info: https://github.com/dspies- leapyear/persistwrap/blob/e8ee02716acdd42ceea8210c9ef333c0f6c9d08d /persistwrap-table/src/PersistWrap/Table/Monad2.hs#L20 When I run {{{ stack test persistwrap:persistwrap-test --ta '-p "Widget.should get back"' }}} I get {{{ Progress 1/2: persistwrap-0.1.0.0test/Driver.hs widget Widget should get back what you put in: STM returning ValueSnd (V (PV 3)) persistwrap-test: internal error: PAP object entered! (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So the message ''outside'' the return is getting printed but not the one on the inside. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 01:46:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 01:46:28 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.493b5d930d47b7841541d082d3f7f216@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5462 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: infoneeded => patch * differential: => Phab:D5462 Comment: Here's what I think is happening: starting in 3d17f1f10fc00540ac052f2fd03182906aa47e35, when told to find an archive for `softfloat`, GHC no longer looks for just `libsoftfloat.a` and `softfloat.a`, it also looks for `libsoftfloat` and `softfloat`. GHC's method for "looking" for an archive is to make a bunch of calls to GCC. Something like {{{ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/atheriault/Code/grift/dist-newstyle/build/x86_64-osx/ghc-8.6.3 /softfloat-hs-0.1.0/build --print-file-name libsoftfloat.a ... gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/atheriault/Code/grift/dist-newstyle/build/x86_64-osx/ghc-8.6.3 /softfloat-hs-0.1.0/build --print-file-name softfloat }}} We "find" a library when the path that GCC prints out is a full path (instead of just the path we pass in). And there's the problem: GCC will print out a full path to a //folder// if an appropriately named folder is found in the base location. In this case, GHC ends up finding the `Users/atheriault/Code/grift/dist-newstyle/build/x86_64-osx/ghc-8.6.3 /softfloat-hs-0.1.0/build/SoftFloat` folder and thinking that this is the `softfloat` library it has been asked to find. One workaround is to name the `softfloat` library to `softfloat1`. Or rename the `SoftFloat` directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 03:03:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 03:03:10 -0000 Subject: [GHC] #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure In-Reply-To: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> References: <051.4bb5f90b04bc5044bc015c1b7b9cbc69@haskell.org> Message-ID: <066.1338c6350f3808dd82080a5b35be4f9b@haskell.org> #16063: ghc-8.6.3 + Mac OSX + FFI dependency causes 'impossible happened' compiler failure -------------------------------------+------------------------------------- Reporter: benselfridge | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by benselfridge): Okay -- I'll do something like that for now. Thanks, Alec. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 04:31:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 04:31:04 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.0c65eba586f246477b62b704eebe6456@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 04:37:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 04:37:50 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.8493c58a0464d1449b1314c289423173@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > because its effect is depending on when context switches are bound to happen Any ideas why -V0 doesn't fix this? It seems to have fixed the same problem in #4450. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 06:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 06:34:59 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.71ba3e3e5e39da2b149c0bafe7236c2d@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 osa1): I think what's happening is this: in the boot file we're declaring a dictionary for `Eq i => Eq (HsExpr i)` without saying anything about the implementation. In `B.hs` we then refer to this dictionary in `Eq i => Eq (HsOverLit i)` because `HsOverLit` refers to `HsExpr`. At this point there isn't a loop yet because we don't know that `HsExpr` will be referring to `HsOverLit`. Then in A.hs we define `HsExpr` with a reference to `HsOverLit`. The dictionary definitions are now recursive but in the current module there's no way to see that. At this point if we don't do any inlining we'll still have a recursive group, but functions in the group will be living in different object files. I don't know if this is something we support. Maybe this is also a problem. If we inline `Eq (HsExpr i) => Eq (HsOverLit i)` and its methods then we get a recursive group in `A.hs`, but I guess we don't do "glomming" in the right places and don't realize this. So I think we may have two problems here: - Without any inlining we get a recursive group where functions live in different object files. Is this something we support? - With inlining we don't realize that after inlining we make new recursive groups (previously non-recursive definitions become recursive). This seems to be a problem with "glomming", and the same thing should be happening with RULEs too. I'll read the relevant code for RULEs to see how this is handled for RULEs. One hacky thing I tried was to do glomming always in `occurAnalyzePgm`, but that didn't fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 08:53:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 08:53:55 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.3990ec9b9a228f8126f8537c87376e07@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 osa1): If I add print statements to print input and output of `occurAnalysePgm`, and also force it to do glomming always, I see that at one point this is the input: {{{ Rec { $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V) $c/=_a287 $c/=_a287 = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 -> case $c==_a27X $dEq_a27V eta_B2 eta_B1 of { False -> True; True -> False } $c==_a27X $c==_a27X = \ @ id_a27U $dEq_a27V -> let { $dEq_a283 $dEq_a283 = $fEqHsExpr $dEq_a27V } in let { $dEq_a281 $dEq_a281 = $fEqHsOverLit $dEq_a27V } in \ ds_d2jB ds_d2jC -> join { fail_d2jD fail_d2jD _ = False } in case ds_d2jB of { HsOverLit a1_a27Q -> case ds_d2jC of { HsOverLit b1_a27R -> let { $dEq1_a2k1 $dEq1_a2k1 = noinline $fxEqHsExpr $dEq_a27V } in case a1_a27Q of { OverLit a1_a2k8 -> case b1_a27R of { OverLit b1_a2kc -> == $dEq1_a2k1 a1_a2k8 b1_a2kc } }; HsBracketOut ipv_s2kg -> False }; HsBracketOut a1_a27S -> case ds_d2jC of { HsOverLit ipv_s2kj -> False; HsBracketOut b1_a27T -> $c==_a27X $dEq_a27V a1_a27S b1_a27T } } end Rec } $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr ... }}} This is already incorrect (`$fxEqHsExpr` should be in the recursive group), but what I don't understand is even after flattening the whole program and doing occurance analysis we end up with incorrect recursive group: {{{ Rec { $c==_a27X $c==_a27X = \ @ id_a27U $dEq_a27V ds_d2jB ds_d2jC -> case ds_d2jB of { HsOverLit a1_a27Q -> case ds_d2jC of { HsOverLit b1_a27R -> let { $dEq1_a2k1 $dEq1_a2k1 = noinline $fxEqHsExpr $dEq_a27V } in case a1_a27Q of { OverLit a1_a2k8 -> case b1_a27R of { OverLit b1_a2kc -> == $dEq1_a2k1 a1_a2k8 b1_a2kc } }; HsBracketOut _ -> False }; HsBracketOut a1_a27S -> case ds_d2jC of { HsOverLit _ -> False; HsBracketOut b1_a27T -> $c==_a27X $dEq_a27V a1_a27S b1_a27T } } end Rec } $c/=_a287 $c/=_a287 = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 -> case $c==_a27X $dEq_a27V eta_B2 eta_B1 of { False -> True; True -> False } $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V) $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Perhaps this is a bug in the occurance analysis? I wonder if the `noinline` is relevant somehow ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 08:59:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 08:59:00 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.5d83010f2b410649ea5e3b415f308a28@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:3 osa1]: > > because its effect is depending on when context switches are bound to happen > > Any ideas why -V0 doesn't fix this? It seems to have fixed the same problem in #4450. Yes, it fixes that, too (https://ghc.haskell.org/trac/ghc/ticket/8611#comment:11). But it isn't enabled by default (and nor should it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 09:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 09:03:40 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.287425fbcd81ffafac8a76dc6ce51418@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm trying to understand; if both `-V0` and `-Z` fix the non-deterministic allocations in some tests, why not enable `-V0` instead of `-Z` in those tests? I don't prefer one over the other, I'm just trying to understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 11:24:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 11:24:48 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.6555dd8f2ddec2c9e196382f541f1b80@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): No reason, I just thought that `-Z` was less invasive. But I don't really know the implications of `-V0`, so YMMV... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 11:29:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 11:29:47 -0000 Subject: [GHC] #16011: GHCi leaks memory even with -fno-it. In-Reply-To: <047.87b5a3aa449632bbf05a6f556592069a@haskell.org> References: <047.87b5a3aa449632bbf05a6f556592069a@haskell.org> Message-ID: <062.f9e83c95580cdc5eca6610d937434c58@haskell.org> #16011: GHCi leaks memory even with -fno-it. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 11:36:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 11:36:17 -0000 Subject: [GHC] #16011: GHCi leaks memory even with -fno-it. In-Reply-To: <047.87b5a3aa449632bbf05a6f556592069a@haskell.org> References: <047.87b5a3aa449632bbf05a6f556592069a@haskell.org> Message-ID: <062.920db1c85bd2f6da7a0424ac030e60fb@haskell.org> #16011: GHCi leaks memory even with -fno-it. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #15503 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 11:36:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 11:36:33 -0000 Subject: [GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory In-Reply-To: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> References: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> Message-ID: <059.7f831814ee53e6cb881afffc031af802@haskell.org> #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #16011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #16011 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 11:57:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 11:57:42 -0000 Subject: [GHC] #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD Message-ID: <057.03812b58dffcdc5705847c5f83d83dbc@haskell.org> #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- Input, derived from code seen in the wild in hpack 0.31.1: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleContexts #-} module Main where type WithCommonOptions cSources cxxSources jsSources a = a data Traverse m cSources cSources_ cxxSources cxxSources_ jsSources jsSources_ = Traverse { traverseCSources :: cSources -> m cSources_ , traverseCxxSources :: cxxSources -> m cxxSources_ , traverseJsSources :: jsSources -> m jsSources_ } type Traversal_ t = forall m cSources cSources_ cxxSources cxxSources_ jsSources jsSources_ a. Monad m => Traverse m cSources cSources_ cxxSources cxxSources_ jsSources jsSources_ -> t cSources cxxSources jsSources a -> m (t cSources_ cxxSources_ jsSources_ a) traverseWithCommonOptions :: Traversal_ WithCommonOptions traverseWithCommonOptions = undefined main = return () }}} Using a GHC compiled from revision 074eae255793de6a94e8172015e7022c80a5cd15, I get this error: {{{ Main.hs:19:30: error: • The type synonym ‘WithCommonOptions’ should have 4 arguments, but has been given none • In the type signature: traverseWithCommonOptions :: Traversal_ WithCommonOptions | 19 | traverseWithCommonOptions :: Traversal_ WithCommonOptions | }}} GHC 8.6.3 accepts the module without complaint. I'm actually surprised that the previous code worked and I wouldn't complain if this is closed as working as intended. However, there's no mention of this change in the migration guide for 8.8 yet, so I'm not certain it's intentional. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 12:08:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 12:08:41 -0000 Subject: [GHC] #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD In-Reply-To: <057.03812b58dffcdc5705847c5f83d83dbc@haskell.org> References: <057.03812b58dffcdc5705847c5f83d83dbc@haskell.org> Message-ID: <072.83cc14b0c9c568c3ec3b0d1e3013738a@haskell.org> #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes -- you should really need `LiberalTypeSynonyms` to accept this; and it's a bug in 8.6 that it doesn't check for that. Perhaps it'd be worth adding to the 8.8 migration guide (Ben)? There are a number of other tickets on `LiberalTypeSynonyms` that Ryan is working on: eg #16059, #16013 I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 12:17:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 12:17:22 -0000 Subject: [GHC] #16069: Proposal to resolve some confusion about stages in Hadrian Message-ID: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> #16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current situation with hadrian is that 1. We build libraries required to build the stage2 compiler with stage1 and place them in `_build/stage1`. 2. The `stage2` compiler is built with `stage1` and then placed in `_build/stage1`. 3. Executables built using the `stage2` compiler such as haddock then also use the libraries built by the `stage1` compiler even though they are being built with the `stage2` compiler. However, this is problematic because when you want to build a `stage3` compiler, we want to actually build the libraries again using the `stage2` compiler and place them in `_build/stage2`. If we follow the existing logic for executables built using the `stage2` compiler then in order to build a `stage3` compiler we would just reuse all the libraries from `_build/stage1` which seems incorrect. The proposal is simply thus: 1. When building an executable at stageN, we use libraries also built at stageN. Concretely, if we want to build `haddock`, a stage2 executable, then we also have to build all the libraries it needs with the `stage2` compiler and install them into a package database in `_build/stage2`. 2. The definition of "build" can be configured. By default, in order to "build" a stage2 library we copy it from the stage1 database but it is configurable to rebuild it with the stage2 compiler as we would want to for stage3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 12:27:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 12:27:56 -0000 Subject: [GHC] #16070: Better inferred signatures Message-ID: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this (taken from [https://github.com/ghc-proposals/ghc- proposals/pull/158#issuecomment-448549030 here]) {{{ class FieldType x r ~ a => HasField (x :: k) r a where type FieldType x r getField :: r -> a setField :: r -> a -> r f r = setField @"bar" r (getField @"foo" r) }}} We get this type inferred for `f`: {{{ f :: forall r. (HasField "bar" r (FieldType "bar" r), HasField "foo" r (FieldType "bar" r)) => r -> r }}} But actually this signature is equivalent {{{ f :: forall r a. (HasField "bar" r a, HasField "foo" r a) => r -> r }}} and it's quite a bit shorter. Similarly, from this definition {{{ g r = setField r }}} We get this inferred type {{{ g :: forall r p. HasField "bar" r (FieldType "bar" r) => p -> r -> FieldType "bar" r -> r }}} where again we might prefer {{{ g :: forall r a. HasField "bar" r a => r -> a -> r }}} '''Question''': could we make GHC infer the briefer types? After all, it does some similar abbreviation with type classes. Where we could infer `(Ord a, Eq a)` we collapse out the `Eq a` and just infer the context `(Ord a)`. There is nothing record-specific about this ticket. It's just about using inferred equality constraints to simplify the inferred signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 12:35:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 12:35:58 -0000 Subject: [GHC] #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD In-Reply-To: <057.03812b58dffcdc5705847c5f83d83dbc@haskell.org> References: <057.03812b58dffcdc5705847c5f83d83dbc@haskell.org> Message-ID: <072.797e842d665d64dbb940d93defefcf46@haskell.org> #16068: Unsaturated type synonyms as arguments work in 8.6.3 but not HEAD -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 quasicomputational): * status: new => closed * resolution: => invalid Comment: OK, thanks - I'd suspected as much. I'll add a note to the migration guide myself, since it seems straightforward enough. It looks like #15954 is the ticket that led to the change directly, for posterity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 12:37:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 12:37:03 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.ab58fb6e00707685294fba03d7d94103@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): To eliminate determinism, `-V0` by itself is preferable. Stack squeezing by itself is perfectly deterministic, the non-determinism arises when it is done at non-deterministic times, which is a result of time-based context switches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 12:48:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 12:48:20 -0000 Subject: [GHC] #16069: Proposal to resolve some confusion about stages in Hadrian In-Reply-To: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> References: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> Message-ID: <064.dfe364875711b2cd63b1f9d82aa77a5d@haskell.org> #16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 13:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 13:46:01 -0000 Subject: [GHC] #16071: GHC is stuck (runs indefinitely) compiling a module Message-ID: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> #16071: GHC is stuck (runs indefinitely) compiling a module -------------------------------------+------------------------------------- Reporter: dirtypaw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling [https://github.com/agda/agda/commit/e68360b16af7865519bef77c21c66ff88139ea7e Agda] with ghc-8.6.3 using stack, ghc is stuck at [https://github.com/agda/agda/blob/master/src/full/Agda/Syntax/Internal.hs this module] (runs for 20+ min with no progress). It looks like a regression in ghc-8.6.3 on Windows as Agda is successfully built with ghc-8.6.2 on the same machine, and Agda build with ghc-8.6.3 is generally supported (see [https://github.com/agda/agda/issues/3442 this issue]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 13:49:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 13:49:42 -0000 Subject: [GHC] #16069: Proposal to resolve some confusion about stages in Hadrian In-Reply-To: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> References: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> Message-ID: <064.160531132a8c55e84ea47b256acb5fc4@haskell.org> #16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 15:02:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 15:02:14 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.d8cb885bda037c6e1a30647ef3ce2ba7@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > As #4450 and #8611 show, stack squeezing in the RTS makes allocation > numbers between two different runs of the same binary non-deterministic, > because its effect is depending on when context switches are bound to > happen. > > A short-term solution might be to deactivate stack squeezing for > vulnerable benchmarks with `+RTS -Z` like in Phab:D5460, but IMO a more > elegant solution would be to only deactivate stack squeezing in > `threadPause` calls that happen due to context switches. Would you agree? New description: As #4450 and #8611 show, stack squeezing in the RTS makes allocation numbers between two different runs of the same binary non-deterministic, because its effect is depending on when context switches are bound to happen. A short-term solution might be to deactivate stack squeezing for vulnerable benchmarks with ~~`+RTS -Z`~~ `+RTS -V0` like in Phab:D5460, but IMO a more elegant solution would be to only deactivate stack squeezing in `threadPause` calls that happen due to context switches. Would you agree? -- Comment (by sgraf): Updated the patch for #8611 to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 15:13:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 15:13:03 -0000 Subject: [GHC] #16072: All dependencies of packages must be explicitly listed when defining flavour packages Message-ID: <049.65a0491f525922e661add96b45114214@haskell.org> #16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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 the Hadrian user guide, it explains that you can use the `packages` variable in order to describe what is built. However, unless you list all the dependencies of what you want to build also in `packages` then it will fail to build. For example, if I want to just build `ghctags` then I might try to modify `packages` to {{{ ghcTagsPackages stage = case stage of Stage2 -> [ghcTags] _ -> [] }}} but this will fail as I haven't listed any dependencies of `ghcTags` at all. The culprit here is the `contextDependencies` function. {{{ contextDependencies :: Context -> Action [Context] contextDependencies Context {..} = do depPkgs <- go [package] return [ Context depStage pkg way | pkg <- depPkgs, pkg /= package ] where depStage = min stage Stage1 go pkgs = do deps <- concatMapM step pkgs let newPkgs = nubOrd $ sort (deps ++ pkgs) if pkgs == newPkgs then return pkgs else go newPkgs step pkg = do deps <- pkgDependencies pkg active <- sort <$> stagePackages depStage return $ intersectOrd (compare . pkgName) active deps }}} Notice in the definition of `step`, the actual package dependencies are intersected with `stagePackages`. It is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 15:42:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 15:42:23 -0000 Subject: [GHC] #16072: All dependencies of packages must be explicitly listed when defining flavour packages In-Reply-To: <049.65a0491f525922e661add96b45114214@haskell.org> References: <049.65a0491f525922e661add96b45114214@haskell.org> Message-ID: <064.b9717847a6f7ac2244f1765994e445b2@haskell.org> #16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: 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): Fixing this causes some problems because the way that windows specific packages (for example, win32) are not compiled on unix is by this mechanism. It would be much more robust for this check to be moved to the place where `win32` is built. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 15:59:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 15:59:23 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.a1785abb04727d2de5ef695fa2de31d9@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:14:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:14:06 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows Message-ID: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:17:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:17:18 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.7188fd84ae3c0e9e28c686d6e2039659@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 simonpj): Gah. I know what is happening. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:43:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:43:53 -0000 Subject: [GHC] #16074: Hopelessly confusing error involving runtime-reps Message-ID: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> #16074: Hopelessly confusing error involving runtime-reps -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE GADTs, TypeOperators, PolyKinds #-} import GHC.Types data a :~: b where Refl :: a :~: a foo :: TYPE a :~: TYPE b foo = Refl }}} We get {{{ • Couldn't match type ‘'LiftedRep’ with ‘'LiftedRep’ ‘a’ is a rigid type variable bound by the type signature for: foo :: * :~: * at Repr.hs:7:1-24 ‘b’ is a rigid type variable bound by the type signature for: foo :: * :~: * at Repr.hs:7:1-24 }}} That's a ridiculous message. But if you asdd `-fprint-explicit-runtime- reps` we get {{{ • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: foo :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a :~: TYPE b at T16050.hs:9:1-24 ‘b’ is a rigid type variable bound by the type signature for: foo :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a :~: TYPE b at T16050.hs:9:1-24 Expected type: TYPE a :~: TYPE b Actual type: TYPE a :~: TYPE a • In the expression: Refl In an equation for ‘foo’: foo = Refl • Relevant bindings include foo :: TYPE a :~: TYPE b (bound at T16050.hs:10:1) }}} which is the right error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:47:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:47:06 -0000 Subject: [GHC] #16074: Hopelessly confusing error involving runtime-reps In-Reply-To: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> References: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> Message-ID: <061.9efd4b7148768d449e3731c6f46dfa7f@haskell.org> #16074: Hopelessly confusing error involving runtime-reps -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): The reason is that when pretty-printing types, we carefully suppress runtime-rep vars (see `IfaceType.defaultRuntimeRepVars`. But that should only apply to ''quantified'' runtime-rep vars like {{{ ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b }}} where we want to default `r` to `LiftedRep`, and just show the type {{{ forall a b. (a->b) -> a -> b }}} But in fact `defaultRuntimeRepVars` was also defaulting ''free'' type variables, and that means that the skolems `a` and `b` were being printed as `LiftedRep`. Gah! The fix is probably just to treat free variables differently; I'll try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:48:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:48:25 -0000 Subject: [GHC] #16074: Hopelessly confusing error involving runtime-reps In-Reply-To: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> References: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> Message-ID: <061.a3eabbd58aad05337c8c24abfdc0a0ce@haskell.org> #16074: Hopelessly confusing error involving runtime-reps -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > {-# LANGUAGE GADTs, TypeOperators, PolyKinds #-} > > import GHC.Types > > data a :~: b where Refl :: a :~: a > > foo :: TYPE a :~: TYPE b > foo = Refl > }}} > We get > {{{ > • Couldn't match type ‘'LiftedRep’ with ‘'LiftedRep’ > ‘a’ is a rigid type variable bound by > the type signature for: > foo :: * :~: * > at Repr.hs:7:1-24 > ‘b’ is a rigid type variable bound by > the type signature for: > foo :: * :~: * > at Repr.hs:7:1-24 > }}} > That's a ridiculous message. But if you asdd `-fprint-explicit-runtime- > reps` we get > {{{ > • Couldn't match type ‘a’ with ‘b’ > ‘a’ is a rigid type variable bound by > the type signature for: > foo :: forall (a :: RuntimeRep) (b :: RuntimeRep). > TYPE a :~: TYPE b > at T16050.hs:9:1-24 > ‘b’ is a rigid type variable bound by > the type signature for: > foo :: forall (a :: RuntimeRep) (b :: RuntimeRep). > TYPE a :~: TYPE b > at T16050.hs:9:1-24 > Expected type: TYPE a :~: TYPE b > Actual type: TYPE a :~: TYPE a > • In the expression: Refl > In an equation for ‘foo’: foo = Refl > • Relevant bindings include > foo :: TYPE a :~: TYPE b (bound at T16050.hs:10:1) > }}} > which is the right error. New description: Consider {{{ {-# LANGUAGE GADTs, TypeOperators, PolyKinds #-} import GHC.Types data a :~: b where Refl :: a :~: a foo :: TYPE a :~: TYPE b foo = Refl }}} We get {{{ • Couldn't match type ‘'LiftedRep’ with ‘'LiftedRep’ ‘a’ is a rigid type variable bound by the type signature for: foo :: * :~: * at Repr.hs:7:1-24 ‘b’ is a rigid type variable bound by the type signature for: foo :: * :~: * at Repr.hs:7:1-24 }}} That's a ridiculous message. But if you asdd `-fprint-explicit-runtime- reps` we get {{{ • Couldn't match type ‘a’ with ‘b’ ‘a’ is a rigid type variable bound by the type signature for: foo :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a :~: TYPE b at T16050.hs:9:1-24 ‘b’ is a rigid type variable bound by the type signature for: foo :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a :~: TYPE b at T16050.hs:9:1-24 Expected type: TYPE a :~: TYPE b Actual type: TYPE a :~: TYPE a • In the expression: Refl In an equation for ‘foo’: foo = Refl • Relevant bindings include foo :: TYPE a :~: TYPE b (bound at T16050.hs:10:1) }}} which is the right error. Reported in comment:5 of #16050 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:48:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:48:56 -0000 Subject: [GHC] #16050: Instance resolution error message unclear, because of missing kind information In-Reply-To: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> References: <046.77bc22801d90d30c8d1bea625d88d94e@haskell.org> Message-ID: <061.2634130df003838ee896ae44d74a062d@haskell.org> #16050: Instance resolution error message unclear, because of missing kind information -------------------------------------+------------------------------------- Reporter: chessai | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13992, #14146 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed comment:6 is a separate bug: #16074 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 16:52:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 16:52:13 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.76048024f1fa8419a5f00b95b5947e2f@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by dnspies): I pushed the failing return call much closer to the top to make it clear that it's not a lazy evaluation thing: Now it's happening here: https://github.com/dspies- leapyear/persistwrap/blob/c6923216c126e9125e4ce80a33bd4e416b3922c7/persistwrap/src/PersistWrap/Persisted.hs#L44 When I run it I get: {{{ Progress 9/10: persistwrap-0.1.0.0test/Driver.hs widget Widget should get back what you put in: Before: STM returning persistwrap-test: internal error: PAP object entered! (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:06:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:06:35 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.7a6531f04b5b8868c97dc7cabcbae288@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): @terei\\ Do you still plan to fix this? If yes, please go ahead; if no, I kindly ask you to unassign the ticket.\\ Many thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:13:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:13:33 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.514cefe279b5b86a1d45b3adeb6d91c3@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * cc: RolandSenn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:25:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:25:57 -0000 Subject: [GHC] #16071: GHC is stuck (runs indefinitely) compiling a module In-Reply-To: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> References: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> Message-ID: <062.097b896cd50971349bcdd0913234c1b3@haskell.org> #16071: GHC is stuck (runs indefinitely) compiling a module -------------------------------------+------------------------------------- Reporter: dirtypaw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #16057 Comment: Thanks for the bug report. Given that that module uses Template Haskell splices, this is a duplicate of #16057, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:26:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:26:34 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.b97f0cfa6f34fe53f75a80f61591594d@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #16071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #16071 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:45:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:45:27 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.5e33a5b2639783a21158867c24be7c0c@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | 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 bgamari: Old description: > See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838. New description: {{{ /---------------------------------------------------\ | Successfully built library 'rts' (Stage1, way v). | | Library: _build/stage1/rts/build/libHSrts-1.0.a | \---------------------------------------------------/ | Run Ld Stage1: _build/stage1/rts/build/c/Adjustor.o (and 117 more) => _build/stage1/rts/build/HSrts-1.0.o copyFile: does not exist (The system cannot find the file specified.) shakeArgsWith 0.001s 0% Function shake 0.017s 0% Database read 0.337s 0% With database 0.033s 0% Running rules 4047.874s 99% ========================= Total 4048.261s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: binary-dist at src/Rules/BinaryDist.hs:97:9-21: * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf * Raised the exception: ExitFailure 1 }}} See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:48:47 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.5ab9c1837c91f78f3ad09f51e8de15c2@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | 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 alpmestan): * cc: snowleopard, alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 17:57:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 17:57:37 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.cdcdd5c5c0ebe76c0fce647926cd9cd0@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Since the ticket had no activity for over 2 years, I think you can go ahead. I suspect that that this can be done using code similar to https://phabricator.haskell.org/D5452. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 18:21:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 18:21:07 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.c4b97fe9152416234b3ff82cc1698bba@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: dterei => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 18:33:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 18:33:36 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.658fc551126a83f981cad1b789fb2020@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): RyanGlScott, have you tried enabling core lint while building the reproducer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 18:38:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 18:38:40 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.cc54fced8e6be4216746127f24ea9600@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:3 trommler]: > I am going to look into this. I just installed FreeBSD on my PowerMac. > > Do you know if the linux execution environment is available for powerpc64? > Never mind, I built an unregisterised cross-compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 18:39:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 18:39:18 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.deab6aecc8ae8f3055f6108ebd330d67@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by RyanGlScott): That test builds without issue when enabling `-dcore-lint` (on GHC 8.4.4, at least). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 18:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 18:39:28 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.4e2c9e14dcbcb7bfd784e238676cc9ef@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ----------------------------------------+--------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Changes (by trommler): * milestone: Research needed => 8.10.1 Comment: I might be able to do this for 8.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 18:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 18:41:56 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.ae2cd4154178ee907fae4cb4deae72a5@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ----------------------------------------+--------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: 15411 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Changes (by trommler): * blockedby: => 15411 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 19:56:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 19:56:52 -0000 Subject: [GHC] #14794: -Weverything should not enable -Wmissing-exported-signatures In-Reply-To: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> References: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> Message-ID: <064.ee50155632e58c3f5aeb043ff02f7eeb@haskell.org> #14794: -Weverything should not enable -Wmissing-exported-signatures -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 crockeea): +1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 19:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 19:57:38 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.3f36128454f26f7cf22455bfa09e57de@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D807 -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"d555d4beb457f485aa122d118903f6f926f054f8/ghc" d555d4be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d555d4beb457f485aa122d118903f6f926f054f8" Use unicode arrows with -fprint-unicode-syntax Summary: See #8959, this is one more place where we can pretty-print Unicode syntax. Test Plan: validate Reviewers: nomeata, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #8959 Differential Revision: https://phabricator.haskell.org/D5439 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 19:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 19:57:38 -0000 Subject: [GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter In-Reply-To: <046.07a20fc376700f524edfc9f92497a641@haskell.org> References: <046.07a20fc376700f524edfc9f92497a641@haskell.org> Message-ID: <061.986b2452937891ab6ef2bd2e1416cdde@haskell.org> #16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"de50f8fd432f88d26a08b07c7bf08c5bff25472e/ghc" de50f8f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="de50f8fd432f88d26a08b07c7bf08c5bff25472e" don't suggest Rank2Types in error messages (Fixed #16000) Summary: Rank2Types is deprecated. Don't suggest to users to use it. Reviewers: bgamari, RyanGlScott, simonpj Reviewed By: RyanGlScott, simonpj Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #16000 Differential Revision: https://phabricator.haskell.org/D5447 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 19:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 19:57:38 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi In-Reply-To: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> References: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> Message-ID: <065.a0fdaa2500b4888016c291480eef5fa9@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5440 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"9d9e35574a92773d872efd58a67339a9e054a9f1/ghc" 9d9e3557/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d9e35574a92773d872efd58a67339a9e054a9f1" Fix #16030 by refactoring IfaceSyn's treatment of GADT constructors Summary: GHCi's `:info` command was pretty-printined GADT constructors suboptimally in the following ways: 1. Sometimes, fields were parenthesized when they did not need it, e.g., ```lang=haskell data Foo a where MkFoo :: (Maybe a) -> Foo a ``` I fixed this by refactoring some code in `pprIfaceConDecl` to be a little smarter with respect to GADT syntax. See `pprFieldArgTy` and `pprArgTy`. 2. With `-fprint-explicit-kinds` enabled, there would be times when specified arguments would be printed without a leading `@` in GADT return types, e.g., ```lang=haskell data Bar @k (a :: k) where MkBar :: Bar k a ``` It turns out that `ppr_tc_app`, the function which pretty-prints these return types, was not using the proper machinery to print out the arguments, which caused the visibilities to be forgotten entirely. I refactored `ppr_tc_app` to do this correctly. Test Plan: make test TEST=T16030 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #16030 Differential Revision: https://phabricator.haskell.org/D5440 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 20:02:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 20:02:05 -0000 Subject: [GHC] #16000: Don't suggest Rank2Types and RankNTypes, only the latter In-Reply-To: <046.07a20fc376700f524edfc9f92497a641@haskell.org> References: <046.07a20fc376700f524edfc9f92497a641@haskell.org> Message-ID: <061.def191d4e8794e0379362eb3ac9238a7@haskell.org> #16000: Don't suggest Rank2Types and RankNTypes, only the latter -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Parser) | 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:D5447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 20:03:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 20:03:48 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi In-Reply-To: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> References: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> Message-ID: <065.74937aec493c4bda0aa0b4365368b63e@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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:D5440 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 20:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 20:17:23 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.6265329d63cb7605f81e9a5ff5a20d04@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 20:47:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 20:47:08 -0000 Subject: [GHC] #16039: 'GHC.Magic.noinline ' should not float out In-Reply-To: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> References: <048.a6d6c2346a4e78a48c53327782a77984@haskell.org> Message-ID: <063.e17777b038f71794d2bbd2c067b64d11@haskell.org> #16039: 'GHC.Magic.noinline ' should not float out -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): `exprArity` is another candidate for the `noinline` check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 21:41:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 21:41:12 -0000 Subject: [GHC] #16075: OPTIONS_GHC Ignored Message-ID: <047.71239b51b70aad041042b035411a0e7b@haskell.org> #16075: OPTIONS_GHC Ignored -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file {{{ main = print "hello" foo :: (Num a, Show a) => a -> IO () foo = print . show }}} generates warnings about: 1. missing an export list 2. top-level binding [main] with no type sig 3. redundant constraint [Num a] If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing- export-lists -fno-warn-redundant-constraints #-}` to the top of the file and recompile, I expect all warnings to go away. But GHC still reports that `main` has no signature. Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code snippet warns about the missing signature on `main`, but when I add the `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be unique to `Weverything`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:32:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:32:36 -0000 Subject: [GHC] #16071: GHC is stuck (runs indefinitely) compiling a module In-Reply-To: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> References: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> Message-ID: <062.c91e8c09afb983aedfc3bc6f541e84ab@haskell.org> #16071: GHC is stuck (runs indefinitely) compiling a module -------------------------------------+------------------------------------- Reporter: dirtypaw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): #16057 seems Windows-specific. Is this ticket Windows-specific too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:33:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:33:14 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.acfd0b428894a46e6a4ff426017d9110@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #16071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This looks serious. Prevents Agda compiling (see #16071). Tamar are you happy to dig or do you need help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:40:38 -0000 Subject: [GHC] #16071: GHC is stuck (runs indefinitely) compiling a module In-Reply-To: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> References: <047.74d96e90dad0c8aa29f437c83b771c2f@haskell.org> Message-ID: <062.1c42081ac6d2ae412643515b84720e31@haskell.org> #16071: GHC is stuck (runs indefinitely) compiling a module -------------------------------------+------------------------------------- Reporter: dirtypaw | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To quote the ticket description: > It looks like a regression in ghc-8.6.3 on Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:44:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:44:28 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.d3f9c5d6f3313fa8971a3fc4627dc036@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T16030 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/T16030 * status: new => closed * resolution: => fixed Comment: Replying to [comment:6 crockeea]: > The ticket as reported is really just about when the kind-roles should be printed, as that's the part I found confusing. In that case, this ticket is fixed. The `T16030` test case provides a regression test for this, as it displays: {{{#!hs type role Foo1 phantom }}} When `-fprint-explicit-kinds` is disabled, and displays: {{{#!hs type role Foo1 nominal phantom }}} When `-fprint-explicit-kinds` is enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:45:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:45:01 -0000 Subject: [GHC] #16069: Proposal to resolve some confusion about stages in Hadrian In-Reply-To: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> References: <049.afb2ab68b601d08525a0afa7da51cd3a@haskell.org> Message-ID: <064.38bebbbb970af09c4860dc769369f605@haskell.org> #16069: Proposal to resolve some confusion about stages in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 snowleopard): This simplification is something I wanted to do for a while, but there is an important question to answer: are we going to build Haddock using Stage1 GHC or Stage2 GHC? The Make build system builds Haddock using Stage2 GHC. I therefore copy my question from the GitHub issue (https://github.com/snowleopard/hadrian/issues/661): We know that building Haddock with Stage1 GHC works, but is this the right thing to do? Why does the Make build system uses the Stage2 GHC to build Haddock? Is it OK for Hadrian to deviate from Make in this respect? If the answer to the above is "It is OK for Hadrian to use Stage1 GHC to build Haddock" then I'll happily support this proposal. However, if the answer is "Hadrian must also use Stage2 GHC to build Haddock" then I'm afraid this proposal means significantly longer build times, since now we'll need to build Stage2 libraries, just in order to build Haddock and docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:51:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:51:14 -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.68a2f69332cca27fb030e0ab95edd50b@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: CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:51:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:51:28 -0000 Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR In-Reply-To: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> References: <046.257cc2180dce5fcae9e4dfcb90ad22aa@haskell.org> Message-ID: <061.311a8dcca18a7b393f57a54202120f70@haskell.org> #8598: IO hack in demand analyzer gets in the way of CPR -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T8598 Blocked By: | Blocking: Related Tickets: #1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:51:57 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.34ed9382e72f6691ba5c3716c78d0e8b@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance, CPRAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: boxing, loops, performance => boxing, loops, performance, CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:52:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:52:48 -0000 Subject: [GHC] #2387: Optimizer misses unboxing opportunity In-Reply-To: <044.f6f12d90c4b64de9fb4d129e27bf4881@haskell.org> References: <044.f6f12d90c4b64de9fb4d129e27bf4881@haskell.org> Message-ID: <059.1b7bcdd1619c3ef347e0d87a19ccd82b@haskell.org> #2387: Optimizer misses unboxing opportunity -------------------------------------+------------------------------------- Reporter: dolio | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: optimizer | unbox box,CPRAnalysis Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: optimizer unbox box => optimizer unbox box,CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:54:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:54:01 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.d077b7fb8c21e39d2d016cb08aa7f98c@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: CPRAnalysis 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: => CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 22:55:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 22:55:25 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.ff391160ce11fc04d7f03d623588c11b@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: CPRAnalysis 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: => CPRAnalysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 23:27:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 23:27:34 -0000 Subject: [GHC] #16046: -fno-stack-protector still necessary? In-Reply-To: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> References: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> Message-ID: <061.7295c2f8efed65dfa744652b8994a53e@haskell.org> #16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.4.3 (make) | 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:D5465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D5465 Comment: I spent some time trying to reproduce failure on modern OpenBSD and got no new failures. Let's remove the option. Sent https://phabricator.haskell.org/D5465 for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 19 23:31:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Dec 2018 23:31:59 -0000 Subject: [GHC] #16072: All dependencies of packages must be explicitly listed when defining flavour packages In-Reply-To: <049.65a0491f525922e661add96b45114214@haskell.org> References: <049.65a0491f525922e661add96b45114214@haskell.org> Message-ID: <064.07739fca22dce31e1d9112076941e6ef@haskell.org> #16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I agree that having a more intelligent `packages` setting would be convenient, although I'm not sure what would be the best way forward. > It is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on. This function doesn't `need` anything, it's purpose is to compute the list of transitive dependencies of a `Context`. I believe one of the call sites of this function does rely on transitive dependencies being included into the result, although I'm afraid I don't recall right now where exactly this call site is. It might have something to do with package registration/configuration. How is the current recursive definition problematic, apart from complexity? I don't think this is immediately relevant to this issue. > It would be much more robust for this check to be moved to the place where `win32` is built. What do you mean? There is no one place where `win32` is built: several different build rules are involved in building `win32`, as any other package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 09:33:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 09:33:04 -0000 Subject: [GHC] #14794: -Weverything should not enable -Wmissing-exported-signatures In-Reply-To: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> References: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> Message-ID: <064.9c5904d5345eccd147507dd2f9a09ce3@haskell.org> #14794: -Weverything should not enable -Wmissing-exported-signatures -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 quasicomputational): * cc: quasicomputational (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 10:19:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 10:19:32 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi In-Reply-To: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> References: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> Message-ID: <065.239b0daf4e79967d3017a408f86333d1@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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:D5440 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): Does this patch also add `@`s in the following situation? {{{#!hs data Foo (is :: [Type]) where AnyFoo :: Foo is type NilFoo = (AnyFoo :: Foo '[]) }}} `> :set -fprint-explicit-kinds`\\ `> :info NilFoo`\\ `type NilFoo = 'AnyFoo ('[] Type) :: Foo ('[] Type)` I've got code which uses a lot of different kinds, and `-fprint-explicit- kinds` helps me to understand why e.g. some type family applications are not computing (because of kind reasons), but I find the output quite hard to read because some types are passed as arguments where I would be expecting a type application. I would prefer the output to be: `type NilFoo = 'AnyFoo ('[] @Type) :: Foo ('[] @Type)` Let me know if that's reasonable. (I don't know what the visible kind application patch changes about this either.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 10:23:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 10:23:42 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi In-Reply-To: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> References: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> Message-ID: <065.f4570b6568c2bf649813a80c08b6653f@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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:D5440 Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Yes, GHC now outputs that kind. (Though you need -XNoStarIsType, otherwise you get `@*` instead of `@Type`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 10:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 10:59:56 -0000 Subject: [GHC] #16030: Poor pretty-printing of GADT constructors in GHCi In-Reply-To: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> References: <050.3175d9e0196a7c6c1593c8950b52a30d@haskell.org> Message-ID: <065.990976c534931d3cda00cb5515ead7c3@haskell.org> #16030: Poor pretty-printing of GADT constructors in GHCi -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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:D5440 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): Excellent, thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 11:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 11:19:52 -0000 Subject: [GHC] #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.5f77ae9f07ee58e3e08a4cc2a4c0e583@haskell.org> #16057: GHC 8.6.3 hangs with Template Haskell on Windows 10 -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #16071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi Simon, I started looking last weekend and will continue coming one. Luckily the byte code interpreter seems to crash already at the first BCO it's trying to interpret. Just working my way through the scheduler to try to figure out what it was supposed to be. If I don't find the cause this weekend I'll be sure to ask for help. I only have time to look at GHC in the weekends so don't want to hold things up on me :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 15:02:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 15:02:09 -0000 Subject: [GHC] #16074: Hopelessly confusing error involving runtime-reps In-Reply-To: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> References: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> Message-ID: <061.ce14374277f6c9afef7b904b30dadccc@haskell.org> #16074: Hopelessly confusing error involving runtime-reps -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Simon Peyton Jones ): In [changeset:"5f2a8793514918eaa670347ce0d95dfdbbdd4f4d/ghc" 5f2a8793/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f2a8793514918eaa670347ce0d95dfdbbdd4f4d" Refine the suppression of RuntimeRep variables When we pretty-print types, we suppress RuntimeRep variables, but we were being too aggressive in doing so, resulting in Trac #16074. This patch makes the suppression a bit less aggressive. See Note [Defaulting RuntimeRep variables] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 15:02:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 15:02:09 -0000 Subject: [GHC] #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 In-Reply-To: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> References: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> Message-ID: <065.1b613747b2fdb9ab853d7678d46a4db2@haskell.org> #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a1c3ad0450baedadc223969dd2b09f59872a38e7/ghc" a1c3ad0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a1c3ad0450baedadc223969dd2b09f59872a38e7" Add solveLocalEqualities to tcHsPatSigType This call plain missing, and as a result the casts messed up deep-skolemisation in tcSubType Fixes Trac #16033 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 15:41:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 15:41:35 -0000 Subject: [GHC] #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 In-Reply-To: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> References: <050.3c5c4a254c5cfc365eee754c034c5266@haskell.org> Message-ID: <065.5adc2f6aa7a81f0f8fb481628c81abee@haskell.org> #16033: Rank-n typechecking regression between GHC 8.4 and 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16033 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T16033 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 15:42:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 15:42:04 -0000 Subject: [GHC] #16074: Hopelessly confusing error involving runtime-reps In-Reply-To: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> References: <046.77b694719e0d56df2e8d9884a7071efe@haskell.org> Message-ID: <061.6108b2364e26f1fac548ffab54ce32dc@haskell.org> #16074: Hopelessly confusing error involving runtime-reps -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T16074 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T16074 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 16:18:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 16:18:21 -0000 Subject: [GHC] #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell Message-ID: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell -------------------------------------+------------------------------------- Reporter: | Owner: (none) radekchannable | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When one module defines an FFI function and uses it in an instance, and a Template Haskell function to derive an instance of the same class, using the function in another module causes GHC to crash, complaining it cannot find the FFI function. See the attached modules for an example. Use the following command to trigger the bug (ensure template-haskell is available): {{{ $ ghc Bar.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Bar ( Bar.hs, Bar.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc13955_0/libghc_6.so: undefined symbol: showFoo Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 16:18:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 16:18:38 -0000 Subject: [GHC] #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell In-Reply-To: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> References: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> Message-ID: <068.5b0e845f5311b42c5b846415b4d457d8@haskell.org> #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell -------------------------------------+------------------------------------- Reporter: radekchannable | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by radekchannable): * Attachment "Foo.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 16:18:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 16:18:45 -0000 Subject: [GHC] #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell In-Reply-To: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> References: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> Message-ID: <068.f95211318b460237c59c382bea0943c0@haskell.org> #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell -------------------------------------+------------------------------------- Reporter: radekchannable | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by radekchannable): * Attachment "Bar.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 17:08:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 17:08:43 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.373173b82ef216e88166c7bbd029886f@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): @monodial: > I suspect that that this can be done using code similar to ​https://phabricator.haskell.org/D5452 It's not quite simple as this. -XSafe is not a dynamic flag, and is not meant be be reset. Therefore a simple function similar to `gopt_set :: DynFlags -> GeneralFlag -> DynFlags` is not available to set `SafeHaskellMode` ! The return type of the function `setSafeHaskell :: SafeHaskellMode -> DynP ()` is more complicated to use, and I think, adding a new public function to the DynFlags module for this ticket is probably not the best idea. However, I have still some other ideas to solve this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 17:30:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 17:30:13 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) In-Reply-To: <050.727e460d0083534afd4869db4aa81c30@haskell.org> References: <050.727e460d0083534afd4869db4aa81c30@haskell.org> Message-ID: <065.bfe24755a8964a2498545120c9dbf131@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 17:30:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 17:30:35 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) In-Reply-To: <050.727e460d0083534afd4869db4aa81c30@haskell.org> References: <050.727e460d0083534afd4869db4aa81c30@haskell.org> Message-ID: <065.3048f1159933907a18889799302ced50@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Reopening because of comment:5. Richard, Ningning, might you look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 18:31:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 18:31:40 -0000 Subject: [GHC] #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell In-Reply-To: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> References: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> Message-ID: <068.3b29daf5e3a50703a58988fe3587b900@haskell.org> #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell -------------------------------------+------------------------------------- Reporter: radekchannable | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by quasicomputational): I think the primary problem here is the error message. To run the TH code, GHC is trying to call the `showFoo` symbol that you've promised exists (with the FFI declaration) and, as it doesn't actually exist, it's failing to do so. That's manifesting as the GHCi linker error you're seeing. I've got confused and gone on a minor wild goose chase for a GHC bug because of this message myself. I wonder if the linker can be improved and give a better error here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 18:33:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 18:33:12 -0000 Subject: [GHC] #16075: Weverything ignores some OPTIONS_GHC flags (was: OPTIONS_GHC Ignored) In-Reply-To: <047.71239b51b70aad041042b035411a0e7b@haskell.org> References: <047.71239b51b70aad041042b035411a0e7b@haskell.org> Message-ID: <062.91ad19a38b561e26315f074e76c13c05@haskell.org> #16075: Weverything ignores some OPTIONS_GHC flags -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 18:50:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 18:50:55 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.d9321d5a2c78b466dc857bd2556ec4b8@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by diatchki): * cc: diatchki (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 20:37:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 20:37:04 -0000 Subject: [GHC] #16077: AvailTC Invariant being violated Message-ID: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> #16077: AvailTC Invariant being violated -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `AvailTC Invariant` (from `basicTypes/Avail.hs`) states that: {{{ If the type or class is itself to be in scope, it must be *first* in this list. Thus, typically: @AvailTC Eq [Eq, ==, \/=]@ }}} Here is a case where this invariant is not upheld: * `pkgA/pkgA.cabal`: {{{ name: pkgA version: 1.0.0 build-type: Simple cabal-version: >= 1.2 library exposed-modules: A build-depends: base }}} * `pkgA/A.hs` {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeFamilies #-} module A ( C(..) , T(TI) , error ) where class C a where data T a instance C Int where data T Int = TI { ti :: Int } }}} * `pkgB/pkgB.cabal` {{{ name: pkgB version: 1.0.0 build-type: Simple cabal-version: >= 1.2 library exposed-modules: B build-depends: base, pkgA }}} * `pkgB/B.hs` {{{ module B ( module A ) where import A hiding (error) }}} Now, check out the exports for `A` vs. `B`: {{{ $ cabal new-build pkgA pkgB --ghc-options -ddump-rn-trace | grep rnExports Warning: The package list for 'hackage.haskell.org' is 38 days old. Run 'cabal update' to get the latest list of available packages. rnExports: Exports: [error, C{C, T;}, T{T, TI;}] rnExports: Exports: [C{C, T;}, T{TI;}] }}} Why is `T{TI;}` in the second line not `T{T, TI;}`? Shouldn't the exports for `B` be identical to those for `A` (except for `error`)? This is causing a crash in Haddock: https://github.com/haskell/haddock/issues/979. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 20:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 20:40:07 -0000 Subject: [GHC] #16077: AvailTC Invariant being violated In-Reply-To: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> References: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> Message-ID: <065.910ba8b17f41b5d2e0000d8023037275@haskell.org> #16077: AvailTC Invariant being violated -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by watashi): * cc: watashi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 21:39:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 21:39:07 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) In-Reply-To: <050.727e460d0083534afd4869db4aa81c30@haskell.org> References: <050.727e460d0083534afd4869db4aa81c30@haskell.org> Message-ID: <065.4d65c73340b87f621af392f55aecb399@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 23:14:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 23:14:06 -0000 Subject: [GHC] #16075: Weverything ignores some OPTIONS_GHC flags In-Reply-To: <047.71239b51b70aad041042b035411a0e7b@haskell.org> References: <047.71239b51b70aad041042b035411a0e7b@haskell.org> Message-ID: <062.84d0e9069d71eed66dcecc5751bfa69f@haskell.org> #16075: Weverything ignores some OPTIONS_GHC flags -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Similarly, adding `{-# OPTIONS_GHC -w #-}` (turn off all warnings) still results in warnings about missing top-level bindings, but hides other errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 23:17:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 23:17:27 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.7c78b453d03bae44c14617505894d533@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 23:22:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 23:22:20 -0000 Subject: [GHC] #16078: Hide -Weverything warnings for GHCi internals Message-ID: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> #16078: Hide -Weverything warnings for GHCi internals -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider Bar.hs {{{ module Bar where }}} Main.hs {{{ import Bar main :: IO () main = print "" }}} `stack ghci Main.hs --ghc-options -Weverything` produces {{{ ... GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help :1:1: warning: [-Wmissing-local-signatures] Polymorphic local binding with no type signature: _compileParsedExpr :: forall a. GHC.Types.IO a -> GHC.Types.IO a :1:1: warning: [-Wmissing-import-lists] The module `Prelude' does not have an explicit import list Loaded GHCi configuration from C:\Users\ericcro\Desktop\VPC-Key- Distribution\src\.ghci : warning: [-Wmissing-home-modules] Modules are not listed in command line but needed for compilation: Bar [1 of 2] Compiling Bar ( Bar.hs, interpreted ) ... }}} Those three errors have nothing to do with my code, and seem to be related to the internals of how GHCi works. It would be nice to hide all three. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 23:24:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 23:24:07 -0000 Subject: [GHC] #16078: Hide -Weverything warnings for GHCi internals In-Reply-To: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> References: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> Message-ID: <062.6a84b7b73084b39617be02f0f3ddb6b9@haskell.org> #16078: Hide -Weverything warnings for GHCi internals -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 20 23:58:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Dec 2018 23:58:49 -0000 Subject: [GHC] #16066: internal error: PAP object entered! In-Reply-To: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> References: <046.d63af513af092d4033ec1aed5c69c6f4@haskell.org> Message-ID: <061.8b2eaa684bf340b59a6cd212effe0396@haskell.org> #16066: internal error: PAP object entered! ----------------------------------+---------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: iOS | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by dnspies): The failure occurs when running the test; not when building. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 04:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 04:29:15 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.58194273bcc4f98b9f7780dc8767589d@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeFamilies 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:D5420 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"28f41f1a7a0ebae7b50ca41dbf78c04ee5b8b5b7/ghc" 28f41f1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28f41f1a7a0ebae7b50ca41dbf78c04ee5b8b5b7" Fix #16002 by moving a validity check to the renamer Summary: The validity check which rejected things like: ```lang=haskell type family B x where A x = x ``` Used to live in the typechecker. But it turns out that this validity check was //only// being run on closed type families without CUSKs! This meant that GHC would silently accept something like this: ```lang=haskell type family B (x :: *) :: * where A x = x ``` This patch fixes the issue by moving this validity check to the renamer, where we can be sure that the check will //always// be run. Test Plan: make test TEST=T16002 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, carter GHC Trac Issues: #16002 Differential Revision: https://phabricator.haskell.org/D5420 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 04:31:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 04:31:03 -0000 Subject: [GHC] #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) In-Reply-To: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> References: <050.7bf7a969250224782dcf5d75c87fcc1f@haskell.org> Message-ID: <065.a6b2fb56a2fa3417bef25d1a7e980574@haskell.org> #16002: Type family equation with wrong name is silently accepted (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | rename/should_fail/T16002 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5420 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => rename/should_fail/T16002 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 08:41:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 08:41:19 -0000 Subject: [GHC] #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell In-Reply-To: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> References: <053.527b6d6990783e203a9929149e0ead4f@haskell.org> Message-ID: <068.f647ebd87e0e34e3d5959220ad696d4f@haskell.org> #16076: Internal compiler error when instance uses FFI function and defining other instance of the same class through Template Haskell -------------------------------------+------------------------------------- Reporter: radekchannable | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by radekchannable): But there is no reason for it to call the showFoo function; its result is not used in any Template Haskell code. This would be a rather arbitrary limitation; not being able to define instances using Template Haskell just because an FFI function was declared in some module somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 09:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 09:09:41 -0000 Subject: [GHC] #16079: runTestTT from ghci caused a panic. Message-ID: <053.5b1aa7be67942a6a4b55cc830af13cd6@haskell.org> #16079: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: | Owner: (none) emacstheviking | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function. I have attached the tar-balled stack project for completeness, apologies for the size but I didn't want to risk omiotting anything important to you guys if this ever gets looked at in the melee! {{{ runTestTT classificationTests ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): nameModule system $dShow_a5Xw Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 09:10:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 09:10:32 -0000 Subject: [GHC] #16080: runTestTT from ghci caused a panic. Message-ID: <053.34b4d518efefb7683003b02513dac18d@haskell.org> #16080: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: | Owner: (none) emacstheviking | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function. {{{ runTestTT classificationTests ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): nameModule system $dShow_a5Xw Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 09:12:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 09:12:42 -0000 Subject: [GHC] #16080: runTestTT from ghci caused a panic. In-Reply-To: <053.34b4d518efefb7683003b02513dac18d@haskell.org> References: <053.34b4d518efefb7683003b02513dac18d@haskell.org> Message-ID: <068.cc20dcdef2afe17602d9f87aa5c36373@haskell.org> #16080: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: emacstheviking | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by emacstheviking): * Attachment "BUG.TXT" added. Two concatted source files for reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 09:22:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 09:22:41 -0000 Subject: [GHC] #16081: Clean up family instance consistency checking Message-ID: <046.ab39957c16e30d7717f06115f123363e@haskell.org> #16081: Clean up family instance consistency checking -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a big mess concerning consistency checking for family instances. It's described in `Note [The type family instance consistency story]` in `FamInst`, which is reproduced below. Note in particular the "four subtle points that have not been addressed yet". The fourth one bit me today, and forced me to introduce a new hack into `loadIface`, described in `Note [Loading your own hi-boot file]` in `LoadIface`. Somehow we should be able to do better! {{{ {- Note [The type family instance consistency story] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To preserve type safety we must ensure that for any given module, all the type family instances used either in that module or in any module it directly or indirectly imports are consistent. For example, consider module F where type family F a module A where import F( F ) type instance F Int = Bool f :: F Int -> Bool f x = x module B where import F( F ) type instance F Int = Char g :: Char -> F Int g x = x module Bad where import A( f ) import B( g ) bad :: Char -> Int bad c = f (g c) Even though module Bad never mentions the type family F at all, by combining the functions f and g that were type checked in contradictory type family instance environments, the function bad is able to coerce from one type to another. So when we type check Bad we must verify that the type family instances defined in module A are consistent with those defined in module B. How do we ensure that we maintain the necessary consistency? * Call a module which defines at least one type family instance a "family instance module". This flag `mi_finsts` is recorded in the interface file. * For every module we calculate the set of all of its direct and indirect dependencies that are family instance modules. This list `dep_finsts` is also recorded in the interface file so we can compute this list for a module from the lists for its direct dependencies. * When type checking a module M we check consistency of all the type family instances that are either provided by its `dep_finsts` or defined in the module M itself. This is a pairwise check, i.e., for every pair of instances we must check that they are consistent. - For family instances coming from `dep_finsts`, this is checked in checkFamInstConsistency, called from tcRnImports. See Note [Checking family instance consistency] for details on this check (and in particular how we avoid having to do all these checks for every module we compile). - That leaves checking the family instances defined in M itself against instances defined in either M or its `dep_finsts`. This is checked in `tcExtendLocalFamInstEnv'. There are four subtle points in this scheme which have not been addressed yet. * We have checked consistency of the family instances *defined* by M or its imports, but this is not by definition the same thing as the family instances *used* by M or its imports. Specifically, we need to ensure when we use a type family instance while compiling M that this instance was really defined from either M or one of its imports, rather than being an instance that we happened to know about from reading an interface file in the course of compiling an unrelated module. Otherwise, we'll end up with no record of the fact that M depends on this family instance and type safety will be compromised. See #13102. * It can also happen that M uses a function defined in another module which is not transitively imported by M. Examples include the desugaring of various overloaded constructs, and references inserted by Template Haskell splices. If that function's definition makes use of type family instances which are not checked against those visible from M, type safety can again be compromised. See #13251. * When a module C imports a boot module B.hs-boot, we check that C's type family instances are compatible with those visible from B.hs-boot. However, C will eventually be linked against a different module B.hs, which might define additional type family instances which are inconsistent with C's. This can also lead to loss of type safety. See #9562. * The call to checkFamConsistency for imported functions occurs very early (in tcRnImports) and that causes problems if the imported instances use type declared in the module being compiled. See Note [Loading your own hi-boot file] in LoadIface. -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 09:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 09:39:48 -0000 Subject: [GHC] #16081: Clean up family instance consistency checking In-Reply-To: <046.ab39957c16e30d7717f06115f123363e@haskell.org> References: <046.ab39957c16e30d7717f06115f123363e@haskell.org> Message-ID: <061.11cb5e870e0c1a77735f323367d95b36@haskell.org> #16081: Clean up family instance consistency checking -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 10:16:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 10:16:20 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.873c0e5a353da700d451e16bdd43be96@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I think we want to leave stack squeezing as it is. How would you make it deterministic? Just saying "only squeeze if we're about to switch to a different thread" would just move the problem to concurrent programs. `+RTS -V0` is a solution that works for both single-threaded and concurrent programs, because it forces the context switches to happen at deterministic times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 10:18:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 10:18:14 -0000 Subject: [GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.223634da72fbf6fb0c830f572069cb29@haskell.org> #16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => closed * resolution: => invalid Comment: I agree. Let's fix nofib by doing `+RTS -V0` for all single-threaded benchmarks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 10:19:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 10:19:34 -0000 Subject: [GHC] #16065: Don't do stack squeezing during context switches in single-threaded programs to guarantee determinism in allocations (was: Stack squeezing during context switches makes for non-determinism in allocations) In-Reply-To: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> References: <044.c4c63c2ced12cdc51b8c0771c6c82c0c@haskell.org> Message-ID: <059.a8b95ffb377c3a116c545d513cfd8b67@haskell.org> #16065: Don't do stack squeezing during context switches in single-threaded programs to guarantee determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450, #8861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 11:37:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 11:37:10 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.5e085b76c509cfd9ce663be8a2b61d79@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"71e26a74da5e5e9a61163b87ab4d22de88a2d04a/ghc" 71e26a74/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71e26a74da5e5e9a61163b87ab4d22de88a2d04a" Make candidateQTvs contain tyvar with zonked kinds candidateQTyVars was failing to return fully-zonked tyvars, and that made things fall over chaotically when we try to sort them into a well-scoped telescope. Result: Trac #15795 So I made candidateQTvs guarantee to have fully-zonked tyvars (i.e. with zonked kinds). That's a bit annoying but not really difficult. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 11:43:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 11:43:49 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.681e32c8e6c9edbee89a3825488a3102@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/polykinds/T15795, T15795a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => tests/polykinds/T15795, T15795a Comment: Great test cases thank you. The cause was that `candidateQTyVars` was returning tyvars with unzonked kinds, and that meant we put the binders in the wrong dependency order. Once that happens, chaos results. The fix is easy, but a bit tiresome. Richard you might want to look. The key point it this (in `TcMType`). {{{ go_tv dv@(DV { dv_kvs = kvs, dv_tvs = tvs }) tv | tv `elemDVarSet` kvs = return dv -- We have met this tyvar aleady | not is_dep , tv `elemDVarSet` tvs = return dv -- We have met this tyvar aleady | otherwise = do { tv_kind <- zonkTcType (tyVarKind tv) -- This zonk is annoying, but it is necessary, both to -- ensure that the collected candidates have zonked kinds -- (Trac #15795) and to make the naughty check -- (which comes next) works correctly ; if intersectsVarSet bound (tyCoVarsOfType tv_kind) }}} Now from the two test cases we get the following results. From comment:5 (immortalised as `polykinds/T15795` we get {{{ TYPE CONSTRUCTORS type synonym KindOf{2} :: forall k. k -> * roles nominal phantom data type T{3} :: forall j (a :: j). KindOf @j a -> * roles nominal nominal phantom DATA CONSTRUCTORS MkT :: forall k (b :: k). T @k @(GHC.Types.Any @k) b }}} From comment:2 (immortalised as `polykinds/T15795a` we get {{{ TYPE CONSTRUCTORS data type F{3} :: forall ob1 (cat1 :: ob1). ob1 -> * roles nominal nominal phantom DATA CONSTRUCTORS Prod :: forall u (a :: u). F @u @(GHC.Types.Any @u) a }}} Note the use of `Any`, which I think is right. Richard/Ryan: just check? Then close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 11:46:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 11:46:47 -0000 Subject: [GHC] #16028: tyThingCoAxiom panics while building Agda In-Reply-To: <047.23f2ee5afbe868e490db42ef500482ef@haskell.org> References: <047.23f2ee5afbe868e490db42ef500482ef@haskell.org> Message-ID: <062.888ce5f0589cf0e95af6aaa2280024d9@haskell.org> #16028: tyThingCoAxiom panics while building Agda -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can anyone reproduce this? Does it happen in HEAD? Can anyone boil it down a bit? Failing that, what are the exact repro instructions. It's odd that it works with 8.4.3 but not 8.4.4. Are you sure you've started in a clean tree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 11:48:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 11:48:30 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.e757de0d1ce13b6a8e0ff0b9a5b5b767@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > My own vote is that we drop the saturation requirement only at top- level, calling the current implementation a bug. I'm fine with this. Ryan, might you execute on this? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 11:55:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 11:55:27 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.20ef33f46f8a00cc2ffbac965a294e15@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16014 | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Old description: > Currently (as I discovered in #15038), we get the following code for > `GHC.Exception.Base.patError`: > {{{ > lvl2_r3y3 :: [Char] > [GblId] > lvl2_r3y3 = unpackCString# lvl1_r3y2 > > -- RHS size: {terms: 7, types: 6, coercions: 2, joins: 0/0} > patError :: forall a. Addr# -> a > [GblId, Arity=1, Str=x, Unf=OtherCon []] > patError > = \ (@ a_a2kh) (s_a1Pi :: Addr#) -> > raise# > @ SomeException > @ 'LiftedRep > @ a_a2kh > (Control.Exception.Base.$fExceptionPatternMatchFail_$ctoException > ((untangle s_a1Pi lvl2_r3y3) > `cast` (Sym (Control.Exception.Base.N:PatternMatchFail[0]) > :: (String :: *) ~R# (PatternMatchFail :: *)))) > }}} > That stupid `lvl2_r3y3 :: String` is a CAF, and hence `patError` has CAF- > refs, and hence so does any function that calls `patError`, and any > function that calls them. > > That's bad! Lots more CAF entries in SRTs, lots more work traversing > those SRTs in the garbage collector. And for what? To share the work of > unpacking a C string! This is nuts. > > What to do? > > * Somehow refrain from floating `unpackCSTring# lit` to top level, even > if you could otherwise do so. But that seems very ad-hoc, and it make the > function bigger and less inlinable. > > * Treat a top level definition > {{{ > x :: [Char] > x = unpackCString# y > }}} > as NOT a CAF, and make it single-entry so that the thunk is not > updated. Then every use of `x` will unpack the string afresh, which is > probably a good idea anyhow. > > I like this more. It would be implemented somewhere in the code > generator. New description: Currently (as I discovered in #15038), we get the following code for `GHC.Exception.Base.patError`: {{{ lvl2_r3y3 :: [Char] [GblId] lvl2_r3y3 = unpackCString# lvl1_r3y2 -- RHS size: {terms: 7, types: 6, coercions: 2, joins: 0/0} patError :: forall a. Addr# -> a [GblId, Arity=1, Str=x, Unf=OtherCon []] patError = \ (@ a_a2kh) (s_a1Pi :: Addr#) -> raise# @ SomeException @ 'LiftedRep @ a_a2kh (Control.Exception.Base.$fExceptionPatternMatchFail_$ctoException ((untangle s_a1Pi lvl2_r3y3) `cast` (Sym (Control.Exception.Base.N:PatternMatchFail[0]) :: (String :: *) ~R# (PatternMatchFail :: *)))) }}} That stupid `lvl2_r3y3 :: String` is a CAF, and hence `patError` has CAF- refs, and hence so does any function that calls `patError`, and any function that calls them. That's bad! Lots more CAF entries in SRTs, lots more work traversing those SRTs in the garbage collector. And for what? To share the work of unpacking a C string! This is nuts. What to do? 1. Somehow refrain from floating `unpackCSTring# lit` to top level, even if you could otherwise do so. But that seems very ad-hoc, and it make the function bigger and less inlinable. 2. Treat a top level definition {{{ x :: [Char] x = unpackCString# y }}} as NOT a CAF, and make it single-entry so that the thunk is not updated. Then every use of `x` will unpack the string afresh, which is probably a good idea anyhow. I like this more. It would be implemented somewhere in the code generator. -- Comment (by simonpj): Looking at #16014, I like alternative (2) from the Description better and better. If we spot {{{ x = unpackCString# "blah"# }}} in the code generator, we could allocate a top-level closure with * Info-pointer: `rtsUnpackString_info` * One word of payload, a pointer to the literal string `"blah"#`. Now we can hand-write the single blob of code (plus info table) `rtsUnpackString_info` to unpack the string. Easy! And the overhead per string is only two words (for the closure) rather than all the stuff described in #16014. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 11:56:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 11:56:15 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.8b7efca08f30e3d19c2c85cb8fc75c07@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs, CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16014 | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: CAFs => CAFs, CodeGen Comment: Omer: would you like to try this when you are done with `CafInfo`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 13:12:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 13:12:02 -0000 Subject: [GHC] #15795: Core lint error with unused kind variable in data type return kind In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.ec8c11571acebe2c969701ec0a308baa@haskell.org> #15795: Core lint error with unused kind variable in data type return kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | tests/polykinds/T15795, T15795a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Checked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 13:23:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 13:23:06 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.c3752243161a3a8628ed5e88b5949d41@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Are we OK with pushing through a breaking change without an accompanying GHC proposal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 13:24:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 13:24:25 -0000 Subject: [GHC] #16003: Average and maximum residency numbers in nofib broken In-Reply-To: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> References: <044.a093d3f7df1bd68b82f2795b31c8f653@haskell.org> Message-ID: <059.fc22ed8cfe24e42c39fbde6f9b04f841@haskell.org> #16003: Average and maximum residency numbers in nofib broken -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Phab:D5418 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"f3521319e2c5390e8076fd379ddeeea9d3e7ce12/nofib" f352131/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="f3521319e2c5390e8076fd379ddeeea9d3e7ce12" Fix parsing of maximum residency in runstdtest Summary: `runstdtest` switched from `-S` to `-s` output a while ago. That broke parsing of maximum and average residency numbers. This commit makes sure that at least maximum residency is parsed correctly from `-s` output, while leaving the logic for `-S` output. Reviewers: simonmar, bgamari, simonpj, osa1, AndreasK, O26 nofib Reviewed By: bgamari GHC Trac Issues: #16003 Differential Revision: https://phabricator.haskell.org/D5418 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 13:42:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 13:42:40 -0000 Subject: [GHC] #15999: Stabilise nofib runtime measurements In-Reply-To: <044.a19ed52539721cf2881ee184b716feca@haskell.org> References: <044.a19ed52539721cf2881ee184b716feca@haskell.org> Message-ID: <059.5ea317da786cd6ada67cb3fdd1d64e94@haskell.org> #15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: 8.6.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D5438 #15333 #15357 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > With Phab:D4989 (cf. #15357) having hit `nofib` master, there are still > many benchmarks that are unstable. I identified three causes for > unstability in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38. > With system overhead mostly out of the equation, there are still two > related tasks left: > > 1. Identify benchmarks with GC wibbles. Plan: Look at counted > instructions while varying heap size with just one generation. A wibbling > benchmark should have quite diverse sampled maximum residency (as opposed > to a microbenchmark, which should have quite stable instruction count). > > Then fix these by iterating `main` 'often enough'. Maybe look at total > bytes allocated for that, we want this to be monotonically declining as > the initial heap size grows. > 2. Now, all benchmarks should have stable instruction count. If not, > maybe there's another class of benchmarks I didn't identify yet in #5793. > Of these benchmarks, there are a few, like `real/eff/CS`, that still have > highly unstable runtimes. Fix these 'microbenchmarks' by hiding them > behind a flag. New description: With Phab:D4989 (cf. #15357) having hit `nofib` master, there are still many benchmarks that are unstable in one way or another. I identified three causes for unstability in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38. With system overhead mostly out of the equation, there are still two related tasks left: 1. Identify benchmarks with GC wibbles. Plan: Look at how productivity rate changes while increasing gen 0 heap size. A GC-sensitive benchmark should have a non-monotonic or discontinuous productivity-rate-over- nursery-size curve. Then fix these by iterating `main` often enough for the curve to become smooth and monotone. 2. Now, all benchmarks should have monotonically decreasing instruction count for increasing nursery sizes. If not, maybe there's another class of benchmarks I didn't identify yet in #5793. Of these benchmarks, there are a few, like `real/eff/CS`, that still have highly code layout-sensitive runtimes. Fix these 'microbenchmarks' by hiding them behind a flag. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 13:53:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 13:53:14 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.bc61393b4bbbefa2dc4fc9dc2b4950f1@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Keeping this ticket open because while the main commit in comment:17 is done, there is still work to be done on the perf aspects. NB: re comment:27, I hope that `Note [The tcType invariant]` is going to go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 13:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 13:59:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.1bc8afaadf42536d6e99690695e1d199@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4450 #16065 | Differential Rev(s): Phab:D5470 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * differential: Phab:D5460 => Phab:D5470 * related: #4450 => #4450 #16065 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 15:07:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 15:07:09 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.bff78ec2d43c52831b7ff2979f93c76c@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes 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: > = Intro = > > Currently we always use the previous commit when running performance > tests. This works well in CI where we fully test each commit in sequence > (and hence always have test results for the previous commit). Remember, > test results are stored in git notes and are not by default shared > between repositories (i.e. your local repo will only have performance > results when they were run locally on your machine). This is by design: > we want to avoid comparing results form different machines. > > Unfortunately This is not so effective when testing locally. The > programmer may have only run a subset of performance tests on the > previous commit, and often have not run the tests at all (this is notably > true after performing a rebase: the previous commit has changed). We need > to rethink how we pick a baseline commit. > > = Goals = > > * In all cases, do something sensible. > * Giving a warning if conditions are not idea. Provide clear and simple > instructions on how to get to the ideal case. > * Give control over the baseline commit to the programmer via command > line options. > * Could make it a baseline branch where we still do git merge-base. > That would be useful if you are branching from a different branch than > master. > * Give control over the baseline of local or ci to the programmer via > command line options. > * In general, performance tests should just work! No extra knowledge > needed by the programmer. > * If tests pass without warning now, then they should pass without > warning later. > > = Proposed Solution 1 = > > * Per test use baseline of closest ancestor commit's metric (favour local > as opposed to CI metrics). aggregate expected changes, but skip tests > with both expected increase and decrease. > * If anything other than local metrics from previous commit were used, > show a warning suggesting running tests on previous commit. > * Stop search if a CI commit is found (these are assumed to be complete) > or if searched an arbitrary number of commits e.g. 100 (this is important > as we'll end up searching whole history if a new test was added). > > = Proposed Solution 2 = > > * When running performance tests, results will be compared to a baseline > commit that is the merge base with master (most recent commit from > master). If HEAD is already in master, then the previous commit is used > instead. > * If any locally generated performance results exist, they are used > exclusively for the baseline. > * Else if any CI generated performance results exist (and have been > fetched), they are used exclusively for the baseline. > * Else performance tests trivially pass, and a warning is given to the > user. > > To find the baseline commit: > {{{ > mergeBase = merge-base master HEAD > baselineCommit = if mergeBase == HEAD > then HEAD^ > else mergeBase > }}} > > == Reasoning == > > * We want each commit in master not to introduce a significant change in > performance: hence we compare commits in mater to the previous commit. > * If not on master (1 or more ahead and 0 or more commits behind master). > We assume that the intention is to create a patch where all new commits > will ultimately be squashed and placed on top of master as a single > commit. On the other hand we don't want to consider changes in master > from after we branched. Instead of using master HEAD as the baseline, we > use the commit from which we branched from master (i.e. the merge base). > In other words we are concerned only with the change in performance > introduced by the newly crated commits. > > = Handling Expected changes = > > TODO this is the complicated part. What happens when the programmer is > not planning on squashing commits and has many commits with expected > changes :-( > > See > [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges > expected performance changes]. > > If on master or an ancestor commit, the baseline is the previous commit > and we can simply allow performance changes as specified in the current > commit's message (this is already the behaviour of the test driver). > > If we have branched from master, then we may have multiple commits from > the baseline commit to HEAD, each of which may have, possibly > contradictory, expected performance changes. If any expected changes > exist, aggregate them. We introduce an explicit "Metric Unchanged" option > and aggregate per test where newer allowed changes overwrite older > allowed changes. "Metric Unchanged" is necessary in the case that a new > commit undoes a performance change such that a metric returns to the > baseline value. The aggregate version should be output so that the > programmer knows what to put in the commit message after squashing the > commits. A warning should be given if expected changes appear in any > commit inbetween HEAD and the baseline commit. In that warning Suggest > e.g. "--baseline HEAD^ if not planning on squashing this commit" > > == Reasoning == > > creating new commits with expected changes is an interactive process. The > programmer adds a 1 or more commits, runs the tests, then adds expected > performance changes to a commit message. It would be too inconvenient to > force the programmer to change old commit messages, and too > verbose/annoying to have them enter a full list of expected changes in > each commit. Hence we must aggregate the expected changes. > > This is of a bit risky as it is a context sensitive change in the > semantics of expected changes. If we e.g. intend not to squash the > commits, then all the sudden the expected changes mean something very > different (change to the previous commit, not some distant baseline > commit). Perhaps we just show a warning in this case. > > We must figure out what commit messages will be used in GitLab on merge. > Does the programmer have to remember to sort out expected changes before > merge some how? > > = Use cases = > > * We do not distinguish between full/partial performance results being > available for the baseline commit: that would require checking out the > baseline commit and extracting the full list of tests. > * > > || BaselinelocalResults || BaselineCIResults || Infos || Warnings || > > ||||||= Case =||||||= Behaviour =|| > ||= Platform =||= Baseline local Results? =||= Baseline CI Results? =||= > Baseline local/CI =||= Infos =||= Warnings =|| > || Local || Yes/Partial || - || Local || If HEAD tests is not subset or > eq to Baseline tests: "If relevant tests exist on baseline, checkout > baseline and running those tests OR fetch notes and use --baseline-ci || > || > || Local || No || Yes || CI || "Using CI numbers, suggest running locally > for more accurate results" || || > || Local || No || No || - || || "No baseline results, tests trivially > pass" + suggest fetch notes or locally run tests on baseline || > || CI |||| Yes || CI || || || > || CI |||| No || - || || "No results. CI is not yet finished, or CI has > failed for the baseline commit or CI hasn’t fetched" || > > = When to automatically fetch CI results? = > > Fetch if: > * Testing locally (not a ci run) AND > * Baseline commit doesn't have local nor CI results (before fetch) AND > * Baseline commit is an ancestor of master. > If fetching, suggest a command line option: --no-fetch. > This is most convenient for local testing avoids fetch on ci, but may > result in unwanted/wasted fetches New description: = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results when they were run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Proposed Solution = * Search for a baseline per test/test_env/metric/way * Start at HEAD^ and use local metrics. If none exist, use CI metrics. If none exist continue the search at the parent. * Stop after a constant number of commits (failing to find a baseline). * Stop the search if the child commit has expected changes for this test/metric/way (failing to find a baseline). * It's possible that there are multiple runs of the test (e.g if the test was run many times locally). In that case take the average. * If no baseline is found, show a warning and let the test pass. === Handling Expected changes === If there are expected changes between HEAD and a potential baseline commit, then that baseline cannot be used. We make no attempt to approximate a baseline. A warning will be issued telling the user to run the tests of the previous commit or try and fetch CI results. ==== Issues ==== * The programmer is responsible for the final commit message having the correct expected changes. This is particularly important when merged via gitlab with a squash (this can change the commit message). * We do not distinguish between full/partial performance results being available for the baseline commit: that would require checking out the baseline commit and extracting the full list of tests (This seems fragile and far too expensive). === When to automatically fetch CI results? === Do not fetch CI results. Allow the user to do this, but give the exact git command so they can just copy and paste. = Alternative Solution = Ultimately this was deemed too complicated. It assumes that commits will be squashed and merged into master (not always true). * When running performance tests, results will be compared to a baseline commit that is the merge base with master (most recent commit from master). If HEAD is already in master, then the previous commit is used instead. * If any locally generated performance results exist, they are used exclusively for the baseline. * Else if any CI generated performance results exist (and have been fetched), they are used exclusively for the baseline. * Else performance tests trivially pass, and a warning is given to the user. To find the baseline commit: {{{ mergeBase = merge-base master HEAD baselineCommit = if mergeBase == HEAD then HEAD^ else mergeBase }}} === Reasoning === * We want each commit in master not to introduce a significant change in performance: hence we compare commits in mater to the previous commit. * If not on master (1 or more ahead and 0 or more commits behind master). We assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master as a single commit. On the other hand we don't want to consider changes in master from after we branched. Instead of using master HEAD as the baseline, we use the commit from which we branched from master (i.e. the merge base). In other words we are concerned only with the change in performance introduced by the newly crated commits. -- Comment (by davide): I've added a MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/22. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 15:10:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 15:10:30 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.bc7faa34047161878dedb8df6a43d11f@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm OK with that. This is a bug, and this ticket proposes a fix. I don't think a proposal is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 15:17:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 15:17:05 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.b1b5342f4c73c781dff9d007f5c4b0cf@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T15704 Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Phab:D5206 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T15704 * resolution: => fixed Comment: I think this is done -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 15:27:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 15:27:38 -0000 Subject: [GHC] #16014: Avoid unnecessary code duplication from String Literals. In-Reply-To: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> References: <047.32f551addc77be5aaf81cb0b70731e22@haskell.org> Message-ID: <062.56fa207af4a365d57769844d29737522@haskell.org> #16014: Avoid unnecessary code duplication from String Literals. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15113 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 15:43:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 15:43:25 -0000 Subject: [GHC] #16082: Sort out treatment of underscores in types Message-ID: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> #16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can count 4 different meanings for underscores in Haskell programs: 1. A pattern for which we don't care to write a name. (This dates back to antiquity.) Example: {{{#!hs const x _ = x }}} 2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.) Example: {{{#!hs plus x y = x + _ }}} 3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.) Example: {{{#!hs plus :: forall a. Num a => a -> a -> _ plus x y = x + y }}} 4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.) Example: {{{#!hs x = const @_ @Bool 'x' -- the _ is inferred to mean Char }}} Problems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types). This is a mess, for at least three reasons: A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this. B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy. C. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad. This ticket is to track resolutions to these problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 15:52:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 15:52:28 -0000 Subject: [GHC] #16082: Sort out treatment of underscores in types In-Reply-To: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> References: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> Message-ID: <062.ccc1bcc367adfb53ae6ff713f24ec66c@haskell.org> #16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): One thought here: we could conceivably treat anonymous wildcards `_` and named wildcards `_w` differently. This would give users some control over the feature. Indeed, this is what will be merged with #12045, where we will warn about `Proxy @_k Int` telling the user that `_k` was unified with `Type` but be silent about `Proxy @_ Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 16:39:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 16:39:50 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.1e94d3f715825fabe80c38362a4a6b5f@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 goldfire): A call this week clarified a few things: A. The second commit in comment:3 exposed an underlying bug. That is, we sometimes call `typeKind` in the type checker. This calls `piResultTys`. But `piResultTys` calls `substTy`, when really we need `nakedSubstTy`. We ''could'' make `tc` equivalents for all these to fix the problem. But better is just to go ahead with the plan in this ticket, which also fixes the problem. B. I've expressed worry about `substTy` encountering a `TcTyVar`. But we realized what's really going on: every substitution (in the type-checker) morally has a `TcLevel`. Substituting variables ''at or above'' that level is highly bogus. But substituting variables ''below'' that level is fine -- they're effectively rigid anyway. In practice, this means that we can instantiate polytypes that still mention meta-type-variables, ''as long as the levels are below the level of the substitution''. Should we actually track and check this? Probably not. But it's good to understand what's going on. This should be put in a Note. C. It's unclear what the advantages/disadvantages are of removing the second return value from `tc_infer_hs_type`. In the last, fallthrough case of that function, it might be quite a lot easier to return the kind rather than reconstruct it. I conjecture that this is purely a performance issue, not at all a correctness issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 16:55:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 16:55:05 -0000 Subject: [GHC] #16081: Clean up family instance consistency checking In-Reply-To: <046.ab39957c16e30d7717f06115f123363e@haskell.org> References: <046.ab39957c16e30d7717f06115f123363e@haskell.org> Message-ID: <061.e1bcf008ef75264e188883bb4cded6fe@haskell.org> #16081: Clean up family instance consistency checking -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a57d5c4d3e39ab9ac2c31431b5e38818359fa5b5/ghc" a57d5c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a57d5c4d3e39ab9ac2c31431b5e38818359fa5b5" Fix treatment of hi-boot files and dfuns Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface was creating a binding, in the module being compiled, for $fxBlah = $fBlah but $fxBlah was a /GlobalId/. But all bindings should be for /LocalIds/ else dependency analysis goes down the tubes. * I added a CoreLint check that an occurrence of a GlobalId is not bound by an binding of a LocalId. (There is already a binding-site check that no binding binds a GlobalId.) * I refactored (and actually signficantly simplified) the tricky code for dfuns in checkHiBootIface to ensure that we get LocalIds for those boot-dfuns. Alas, I then got "duplicate instance" messages when compiling HsExpr. It turns out that this is a long-standing, but extremely delicate, bug: even before this patch, if you compile HsExpr with -ddump-tc-trace, you get "duplicate instance". Without -ddump-tc-trace, it's OK. What a mess! The reason for the duplicate-instance is now explained in Note [Loading your own hi-boot file] in LoadIface. I fixed it by a Gross Hack in LoadIface.loadInterface. This is at least no worse than before. But there should be a better way. I have opened #16081 for this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 16:55:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 16:55:05 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.1dfe298771c26b922700dd07f353488b@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 Simon Peyton Jones ): In [changeset:"a57d5c4d3e39ab9ac2c31431b5e38818359fa5b5/ghc" a57d5c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a57d5c4d3e39ab9ac2c31431b5e38818359fa5b5" Fix treatment of hi-boot files and dfuns Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface was creating a binding, in the module being compiled, for $fxBlah = $fBlah but $fxBlah was a /GlobalId/. But all bindings should be for /LocalIds/ else dependency analysis goes down the tubes. * I added a CoreLint check that an occurrence of a GlobalId is not bound by an binding of a LocalId. (There is already a binding-site check that no binding binds a GlobalId.) * I refactored (and actually signficantly simplified) the tricky code for dfuns in checkHiBootIface to ensure that we get LocalIds for those boot-dfuns. Alas, I then got "duplicate instance" messages when compiling HsExpr. It turns out that this is a long-standing, but extremely delicate, bug: even before this patch, if you compile HsExpr with -ddump-tc-trace, you get "duplicate instance". Without -ddump-tc-trace, it's OK. What a mess! The reason for the duplicate-instance is now explained in Note [Loading your own hi-boot file] in LoadIface. I fixed it by a Gross Hack in LoadIface.loadInterface. This is at least no worse than before. But there should be a better way. I have opened #16081 for this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 16:58:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 16:58:32 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.1f9b1a4731f5f9b27fba3b1c45336256@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 simonpj): Well that was harder than I expected! Done now, thought. Omer: could you add a test? I'll leave it open for that reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 17:51:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 17:51:19 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.dda888b8a20234843b8926a1e9929362@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T12509 Blocked By: | Blocking: Related Tickets: #13385, #14342 | Differential Rev(s): Gitlab Merge Wiki Page: | Request 21 -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => make test TEST=T12509 * status: new => patch * differential: => Gitlab Merge Request 21 * related: => #13385, #14342 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 17:57:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 17:57:57 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.9064ce23fb004bca2ca67f1fe416dd58@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 18:36:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 18:36:38 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.3f341371a0fb2732e169c1ceedd9cc88@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T12509 Blocked By: | Blocking: Related Tickets: #13385, #14342 | Differential Rev(s): Gitlab Merge Wiki Page: | Request 23 -------------------------------------+------------------------------------- Changes (by int-e): * differential: Gitlab Merge Request 21 => Gitlab Merge Request 23 Comment: cf. https://gitlab.haskell.org/ghc/ghc/merge_requests/23 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 19:11:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 19:11:11 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.1dbb24765fdf432692882f822715255a@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T12509 Blocked By: | Blocking: Related Tickets: #13385, #14342 | Differential Rev(s): Gitlab Merge Wiki Page: | Request 23 -------------------------------------+------------------------------------- Comment (by int-e): Following in RolandSenn's trail... `ghci` evaluates some code internally. One such piece of code comes from `ghc/GHCi/UI/Monad.hs`, `initInterpBuffering`, which evaluates `System.IO.hSetBuffering System.IO.stdin System.IO.NoBuffering` (and the same for `stdout` and `stderr`). This works fine without `-XSafe`, but with `-XSafe` there is a stricter check that requires `System.IO` to actually be imported: {{{ $ ghci GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Prelude> System.IO.hSetBuffering System.IO.stdin System.IO.NoBuffering Prelude> :set -XSafe Prelude> System.IO.hSetBuffering System.IO.stdin System.IO.NoBuffering :3:1: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :3:25: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. :3:41: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. Prelude> import System.IO Prelude System.IO> System.IO.hSetBuffering System.IO.stdin System.IO.NoBuffering Prelude System.IO> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 19:12:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 19:12:18 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.984efa6ff6084caf1f2124764e815cd1@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): @monoidal: > Fixing this will likely also fix #12509 Unfortunately not... #12509 does not enter `loadSrcInterface_maybe` because of `not (safeDirectImpsReq dflags)`. However, this ticket fails somewhere in a subfunction of `loadSrcInterface_maybe`. {{{ Code from compiler/rename/RnEnv.hs: lookupQualifiedNameGHCi :: RdrName -> RnM [Name] lookupQualifiedNameGHCi rdr_name = -- We want to behave as we would for a source file import here, -- and respect hiddenness of modules/packages, hence loadSrcInterface. do { dflags <- getDynFlags ; is_ghci <- getIsGHCi ; go_for_it dflags is_ghci } where go_for_it dflags is_ghci | Just (mod,occ) <- isQual_maybe rdr_name , is_ghci , gopt Opt_ImplicitImportQualified dflags -- Enables this GHCi behaviour , not (safeDirectImpsReq dflags) -- See Note [Safe Haskell and GHCi] = do { res <- loadSrcInterface_maybe doc mod False Nothing <...etc...> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 19:41:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 19:41:57 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.0f942a4606ea568bb4da1da60ccb3892@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: 13624 | Blocking: Related Tickets: #13540, #13624 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by carter): https://gitlab.haskell.org/ghc/ghc/merge_requests/24 is my first step towards making sse2 always true on x86/x86_64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 20:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 20:27:06 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.09e37646842cc8b9c77ebb972d3b29c1@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: 13624 | Blocking: Related Tickets: #13540, #13624 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by carter): https://gitlab.haskell.org/ghc/ghc/merge_requests/26 is the corrected one :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 21:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 21:56:24 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.53ea461b51e54bb2f62e27998a98947d@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4147df3a83e9dc8ad5015e8d5439de9269f6c20c/ghc" 4147df3a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4147df3a83e9dc8ad5015e8d5439de9269f6c20c" gitlab-ci: Allow Hadrian build on Windows to fail Due to #16073. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 23:27:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 23:27:44 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.4f71adb2259690d8a52f2ef38d37a738@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > One of those is if the fsks and fmvs were both left in place in both Givens and in Wanteds; no extra unflattening before invoking plugins. Great! That sounds in line with the proposal in comment:16. Would you like to socialise it with other plugin authors and check they are happy? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 21 23:34:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Dec 2018 23:34:34 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.017c9d8812ea761f787920e1d11e69e9@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins Operating System: 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 a related request: directly provide the list of all in-scope variables bound by the enclosing and current implications It's not quite readily available, because we simply recurse in the solver, without putting the skolems anywhere accessible. The right place would be in the `InertSet` (in `TcSMonad`). There is already a field for the flatten-skolems (fsks); you'd just need to add a field for the ordinary skolems. Not hard. The fmv are more like unification variables; you can easily find them from the RHS of `CFunEqCan` wanteds/deriveds. If you want to offer a patch, I'm sure Richard and I can offer guidance. I think we should concentrate on what GHC can ''easily'' do; we don't want to impose substantial overheads for the benefit of plugins that may not exist in the common case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 01:27:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 01:27:50 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.bc3d83688b326d070a6ed6180ba420c2@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bravit): * cc: bravit (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 02:05:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 02:05:03 -0000 Subject: [GHC] #9627: Type error with functional dependencies In-Reply-To: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> References: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> Message-ID: <062.6e1631e14ff0aad208894e85cd11eecb@haskell.org> #9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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 AntC): (This ticket is the main motivation for [https://people.cs.kuleuven.be/~tom.schrijvers/Research/papers/haskell2017a.pdf this paper].) Replying to [comment:1 simonpj]: > Indeed. Here is a more direct example: ... > From which we get ... What's frustrating in the example is that if we put an equation for `f` that gets the code to compile: {{{ f _ = undefined }}} GHC (8.0 and Hugs way back in 2006) infer `f :: Bool -> Bool`. > Remember that GHC elaborates the program into System FC, generating evidence. > * For functional dependencies I have no clue what evidence might look like. The short answer would be: whatever GHC is doing to improve to that signature, just make it evidence. Perhaps GHC is being cautious about selecting an instance for `C`: the wanted is `C Int b`; if it weren't for the FunDep, there could be other instances that match that; GHC is undependable in picking instances in presence of a dependency #15632. I tried with an instance more like the `FDs via CHRs` theory {{{ instance (b ~ Bool) => C Int b }}} That instance head is exactly the wanted, but GHC gives the same behaviour. > If someone can explain how to elaborate functional dependencies into well-typed evidence in System FC, that would be good. My inability to do so was one of the reasons we developed type families and System FC in the first place. > Aha! Does that "inability" date to before the `FDs via CHRs` 2006 paper? (The work on Assoc data types started 2005, that lead on to Type Families.) * One piece of evidence would be the improvement of the FunDep target arising from the constraint `(b ~ Bool)` on my recast instance. * One piece would be that that instance head exactly matches the wanted. * One piece would be that `~` constraint arises from the FunDep. A couple of complications: 1. There might be multiple FunDeps, say {{{ class C2 a b | a -> b, b -> a }}} Then looking for evidence would have to treat instances as if: {{{ instance C2 Int Bool instance (b ~ Bool) => C2 Int b | (a ~ Int) => C2 a Bool | C2 Int Bool }}} (That's ''not'' any sort of proposal for syntax. I'm trying to express there are pseudo-instances arising from the FunDeps.) Those pseudo-instances overlap, but they're consistent with the FunDeps, according to the `FDs via CHRs` rules. 2. Overlapping instances combined with FunDeps are already problematic. Again treating the target as a bare typevar with an `~` constraint, ''then'' considering overlaps in resulting substitution ordering seems to work ticket:15632#comment:2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 02:10:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 02:10:43 -0000 Subject: [GHC] #15632: Undependable Dependencies In-Reply-To: <043.01997ce1746c591111a0a2273155036b@haskell.org> References: <043.01997ce1746c591111a0a2273155036b@haskell.org> Message-ID: <058.366359583dc2c4e795833886392427b0@haskell.org> #15632: Undependable Dependencies -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | FunctionalDependencies, | OverlappingInstances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 9210, | Differential Rev(s): 8634, 15135, 15927, 9627, 16070 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by AntC): * related: 10675, 9210, 8634, 15135, 15927 => 10675, 9210, 8634, 15135, 15927, 9627, 16070 Comment: Adding a couple of related tickets. See also the paper linked from ticket:9627#comment:3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 02:11:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 02:11:40 -0000 Subject: [GHC] #15298: Support spliced function names in type signatures in TH declaration quotes In-Reply-To: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> References: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> Message-ID: <058.73ebfef32e990607165414bedd48ad0a@haskell.org> #15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mikelpr): I hit this too. I'm working with yesod+persistent, and I want to expose GET+PUT with JSON for some tables, and all they differ in are the function names and the datatypes they use for the key, and I can't generate these mainly same functions for the routes with [d| get$(funame)R put$(funame)R ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 02:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 02:26:09 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.0bfd60fc9325f40dc35f0bc6ef265434@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [ticket:16070 simonpj]: > ... quite a bit shorter. To be clear what's intended here: the "shorter" could be achieved by something akin to Common Subexpression Elimination. That is: * Common type (sub-)expressions appearing in constaints. * Replace by a bare unification tyvar. * Add a `~` constraint between the tyvar and the type expression. But wait, there's more: > After all, it does some similar abbreviation with type classes. Where we could > infer `(Ord a, Eq a)` we collapse out the `Eq a` and just infer the context `(Ord a)`. The `~` constraint generated for the common type expression `FieldType` is exactly the superclass constraint for `HasField`, just as `Eq a` is a superclass constraint for `(Ord a)`. Note also a later comment on that github discussion that the `FieldType` constraint holding implies there's a `HasField` instance -- because `FieldType` is an Associated Type. Using that implication seems harder: Assoc Types are trreated as sugar for top-level type families/not necessarily grounded in instances, which already gives trouble. > > There is nothing record-specific about this ticket. It's just about using inferred equality constraints to simplify the inferred signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 02:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 02:39:28 -0000 Subject: [GHC] #16013: :kind! accepts unsaturated type aliases In-Reply-To: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> References: <044.fca11e3b2d2fb2b5d2ceea097fcb4b01@haskell.org> Message-ID: <059.4d322b2c1713d3eee45861b345fbe927@haskell.org> #16013: :kind! accepts unsaturated type aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13962 | Differential Rev(s): Phab:D5471 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5471 Comment: Alright, then here's a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 07:22:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 07:22:19 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.dc975891eb19debf259ef30ef729fa77@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 Ömer Sinan Ağacan ): In [changeset:"8adef36cb16b244a81dfb54ead924e00069f33ae/ghc" 8adef36c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8adef36cb16b244a81dfb54ead924e00069f33ae" Add test for #16038 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 07:24:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 07:24:00 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.ad5c1492bcc5cce3ce33233e566d289a@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 osa1): Done. Do we want to milestone this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 11:05:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 11:05:32 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken In-Reply-To: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> References: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> Message-ID: <064.a4d28b4d68c64c7ca85c9b2a6d58f389@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.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): D5257 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"44fc21a315d0da2377aa8fae93c48ba0b961dd9a/nofib" 44fc21a/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="44fc21a315d0da2377aa8fae93c48ba0b961dd9a" Fix some broken links (#15733) Summary: For links in subpackages as well. https://phabricator.haskell.org/D5257 Test Plan: Manually verify links Reviewers: mpickering, bgamari, O26 nofib, osa1 Reviewed By: osa1 GHC Trac Issues: #15733 Differential Revision: https://phabricator.haskell.org/D5260 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 11:43:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 11:43:08 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.faad66e7dafd706b59dc5ea833ec1106@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:30 dfeuer]: > I think the choice to reuse `->` was a bit fishy from the start. The arrow was borrowed straight from database Functional Dependencies. (I guess it helped that `->` was already a recognised lexeme.) But note that Mark Jones' original proposal was that FunDeps should look like this {{{ class Foo a b c d | {a} -> {b, c}, {b, d} -> {a} where ... }}} IOW: the determinant and dependent are sets of parameters (order immaterial). That's exactly how they look in database theory. `b d` does indeed excite in my brain that is tyvar `b` applied to `d`. (The Haskell abbreviated form was also taken over into injective type families, where it gives a potential syntactic ambiguity.) So the fishiness arose from dropping the set notation braces with commalist. > I'd have no objection to using some symbol other than `::` if you'd prefer. Aside from how to bind naming for a FunDep, beware that a Type Familiy's parameters are positional whereas a FunDep's are not. IOW this is (supposed to be) an entirely equivalent class decl {{{ class Foo a b c d | d b -> a, a -> b c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 13:21:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 13:21:02 -0000 Subject: [GHC] #16078: Hide -Weverything warnings for GHCi internals In-Reply-To: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> References: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> Message-ID: <062.930f10ea389991f378313ec24c5b6f70@haskell.org> #16078: Hide -Weverything warnings for GHCi internals -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): The first two warning messages are related to GHCi internal processing, however not the third one! The third one can be avoided by mentioning ''Bar.hs'' on the command line. eg: `stack ghci Main.hs Bar.hs --ghc-options -Weverything` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 13:52:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 13:52:47 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. (was: GHC 8.6.3 hangs with Template Haskell on Windows 10) In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.54c80557a1cf841b48f0300f3508fa84@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #16071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * component: Template Haskell => Runtime System Comment: smallest example a `Main.hs`. {{{ main = return 1 }}} called with {{{ echo main | ghc --interactive -fforce-recomp -fobject-code Main.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 14:04:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 14:04:44 -0000 Subject: [GHC] #16078: Hide -Weverything warnings for GHCi internals In-Reply-To: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> References: <047.a80bcff9954b5fc9e875a3cf476dd4bf@haskell.org> Message-ID: <062.a3bc8fed1f6d1defaa159f9c9cf266b3@haskell.org> #16078: Hide -Weverything warnings for GHCi internals -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I question the utility of warning about missing-home-modules in GHCi, when this warning was originally introduced (#13129) to solve a Cabal problem. Does anyone actually load GHCi by listing all the modules, and what is gained by doing so? I frequently use GHCi with large projects where I'm definitely only going to list the top module on the command line. Perhaps this should be a GHC- only warning? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 15:01:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 15:01:34 -0000 Subject: [GHC] #16083: objcpp-hi test appears to be broken on Mojave builder Message-ID: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> #16083: objcpp-hi test appears to be broken on Mojave builder --------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: --------------------------------------+--------------------------------- It appears that something has changed in the Darwin toolchain such that `` is no longer found by default: {{{ cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001 Compile failed (exit code 1) errors were: warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found] objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found #import ^~~~~~~~~~ 1 warning and 1 error generated. `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for objcpp-hi(normal) }}} Marking as broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 15:03:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 15:03:21 -0000 Subject: [GHC] #16083: tests relying on in Objective C++ are broken on Mojave builder (was: objcpp-hi test appears to be broken on Mojave builder) In-Reply-To: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> References: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> Message-ID: <061.664015ab691d9a64b2c98d5ef762c479@haskell.org> #16083: tests relying on in Objective C++ are broken on Mojave builder ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: > It appears that something has changed in the Darwin toolchain such that > `` is no longer found by default: > {{{ > cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory > recomp001 > Compile failed (exit code 1) errors were: > warning: include path for stdlibc++ headers not found; pass '-std=libc++' > on the command line to use the libc++ standard library instead > [-Wstdlibcxx-not-found] > > objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found > #import > ^~~~~~~~~~ > 1 warning and 1 error generated. > `gcc' failed in phase `C Compiler'. (Exit code: 1) > > *** unexpected failure for objcpp-hi(normal) > }}} > > Marking as broken. New description: It appears that something has changed in the Darwin toolchain such that `` is no longer found by default: {{{ cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001 Compile failed (exit code 1) errors were: warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found] objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found #import ^~~~~~~~~~ 1 warning and 1 error generated. `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for objcpp-hi(normal) Compile failed (exit code 1) errors were: warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found] /var/folders/pb/c3dc08v12yzc536lnrnngvd40000gq/T/ghc56064_0/ghc_2.cpp:1:10: error: fatal error: 'iostream' file not found #include ^~~~~~~~~~ 1 warning and 1 error generated. `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for T13366(normal) }}} Marking as broken. -- Comment (by bgamari): `T13366` is also affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 15:06:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 15:06:01 -0000 Subject: [GHC] #16083: tests relying on are broken on Mojave builder (was: tests relying on in Objective C++ are broken on Mojave builder) In-Reply-To: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> References: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> Message-ID: <061.ceb403b91e5d3d213b11a525bbafe5c1@haskell.org> #16083: tests relying on are broken on Mojave builder ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): It looks like `T13366` is just standard C++, not Objective C++. Something appears to be very wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 15:56:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 15:56:41 -0000 Subject: [GHC] #15662: Line pragmas appear to be slightly broken with Clang's CPP In-Reply-To: <046.2a012973b0e74ae240426b655456015f@haskell.org> References: <046.2a012973b0e74ae240426b655456015f@haskell.org> Message-ID: <061.2c79694ce5df1e3cb9514dafa29b86c4@haskell.org> #15662: Line pragmas appear to be slightly broken with Clang's CPP -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 Ben Gamari ): In [changeset:"7e1d214fce064c42df70ae121cedf27ebea853f8/ghc" 7e1d214/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e1d214fce064c42df70ae121cedf27ebea853f8" testsuite: Remove expect_broken on readFail032 and readFail048 As noted in #15662, these used to be broken on Darwin due to a Clang toolchain bug. However, this bug appears to be fixed in the Clang shipped with macOS Mojave. Unfortunately, we don't really have any way to only mark it as broken on certain operation system releases so I am just removing the expect_broken entirely. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 15:56:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 15:56:41 -0000 Subject: [GHC] #16083: tests relying on are broken on Mojave builder In-Reply-To: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> References: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> Message-ID: <061.6daaaacaa6b5e5d379be1f03b0eebe63@haskell.org> #16083: tests relying on are broken on Mojave builder ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"1c0c5e844226f3d77af31d97b21ffb8b14b55740/ghc" 1c0c5e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c0c5e844226f3d77af31d97b21ffb8b14b55740" testsuite: Mark objcpp-hi and T13366 as broken on Darwin due to #16083 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 15:57:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 15:57:03 -0000 Subject: [GHC] #16083: tests relying on are broken on Mojave builder In-Reply-To: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> References: <046.f4bc5eda9c7a94ce38d24f0163ba76cd@haskell.org> Message-ID: <061.d3fc6b8a3f91ec83bd5003bd01719747@haskell.org> #16083: tests relying on are broken on Mojave builder ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 carter): Hey Ben: have you tried running the tests explicitly with cc set to clang ? They’ve generally passed for me with clang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 16:27:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 16:27:21 -0000 Subject: [GHC] #16084: Improve link times on Windows Message-ID: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the Windows CI builds are typically lasting over 3 hours. The primary cause of this appears to be poor performance in `ld.bfd`, especially when linking testsuite tests. One option to fix this is to try using LLD for linking. Unfortunately the msys2 `gcc` does not support `-fuse-ld=lld`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 16:27:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 16:27:51 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.328d8906dc16ecbdb27e6bf319909066@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have opened an `msys2` [[https://github.com/Alexpux/MSYS2-packages/issues/1531|ticket]] requesting that `gcc` ship with support for `-fuse-ld=lld`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 16:28:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 16:28:03 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.3a2e19f5a5fecbba7045ff79cd84f59b@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | 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): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 16:28:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 16:28:12 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.3f7597d60d65598e307806394abc4585@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 16:41:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 16:41:07 -0000 Subject: [GHC] #12913: Port SplitSections to Windows In-Reply-To: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> References: <045.2681dcaf240f2f84bd76ab07ca222e34@haskell.org> Message-ID: <060.c1ec0498d93638d6a077e7da0c861280@haskell.org> #12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 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 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #16084 to track the issue of link speed on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 17:55:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 17:55:25 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised Message-ID: <046.08016c835b725498a58c6f31e9385947@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!patch --- /dev/null 2018-12-22 16:25:47.047680317 +0000 +++ ffi/should_run/ffi018_ghci.run/ffi018_ghci.run.stderr.normalised 2018-12-22 17:31:34.178826693 +0000 @@ -0,0 +1,4 @@ + +ffi018_ghci:6:30: + Not in scope: ‘Main.main’ + No module named ‘Main’ is imported. }}} I suspect the testsuite driver is hiding the interesting part of the failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 18:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 18:07:21 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.aa49e4f44651927597e3c4d8a72b6d5a@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by Ben Gamari ): In [changeset:"8fd3f9a67f9c7b447a5bfcb3aefd8986794918ce/ghc" 8fd3f9a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fd3f9a67f9c7b447a5bfcb3aefd8986794918ce" testsuite: Mark heapprof001 as broken in prof_hc_hb way on i386 As documented in #15382, this is known to fail in prof_hc_hb on i386. Concerningly, I have also seen this test non-deterministically fail in prof_hc_hb on amd64. We should really investigate this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 18:41:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 18:41:28 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.e43230c06f2eb75236b6733b3b6725ad@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * architecture: x86 => Unknown/Multiple * related: #16071 => #16071 #13617 Comment: Like all good and bad things in life, this comes down to alignment. The change in ed86e3b531322f74d2c2d00d7ff8662b08fabde6 triggers a missing feature in the 8.6 branch. The `-Wa,-mbig-obj` changes the object code format, causing the COFF header to grow by 2 bytes. These two bytes push everything down, and causes the symbols which just happened to be aligned to the required section alignment to be misaligned. The `.text` section requires 16 byte alignment, and the ByteCode interpeter makes use of this to store tag bits in the lower bits. So a couple of things go wrong here. The new misaligned sections require the linker to actually do section alignment. Before: {{{ addSymbol 000000000c6900f0 `Main_main_info' addSymbol 000000000c6901e0 `Main_main_closure' addSymbol 000000000c690158 `ZCMain_main_info' addSymbol 000000000c690220 `ZCMain_main_closure' addSymbol 000000000c690260 `Main_zdtrModule_closure }}} Everything happened to be aligned in most cases. Now everything is unaligned: {{{ addSymbol 000000000c690114 `Main_main_info addSymbol 000000000c690204 `Main_main_closure' addSymbol 000000000c69017c `ZCMain_main_info' addSymbol 000000000c690244 `ZCMain_main_closure' addSymbol 000000000c690284 `Main_zdtrModule_closure' }}} The byte code interpreter then gets the unaligned address and thinks it's a tagged object and strips the bottom bits off {{{ bcoSize = 3 Sp = 00000000061f0be0 pc = 0 PUSH_G 000000000d8801b4 Sp = 00000000061f0bd8 pc = 2 ENTER --------------------------------------------------------------- Evaluating: Object 000000000d8801b0 = }}} And segfaults as the address is now nonsense. The change works on HEAD as I added alignment support to the linker in head for GHC 8.8. Now the question is how to proceed. There are two options 1) Revert this patch for the 8.6 branches and lose profiling support for a while till GHC 8.8 2) I can produce a much simpler alignment fix patch, but it'll consume more memory then the bigger linker overhaul in HEAD currently, but.. it won't have had as much testing as the version in HEAD has.. so will need to be able to reason about it's correctness instead. I suppose most people would favor no# 2 so I'll get started on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 18:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 18:46:21 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.89365606edd22665eb58e1c260da6d09@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:6 AntC]: > Note also a later comment on that github discussion that the `FieldType` constraint holding implies there's a `HasField` instance -- because `FieldType` is an Associated Type. Using that implication seems harder: Assoc Types are treated as sugar for top-level type families/not necessarily grounded in instances, which already gives trouble. I was also concerned about this, in particular what happens if we have a `type instance` for an associated type at the top-level? But it turns out that GHC does not allow that, all instances of associated types must be defined in the context of a class instance. So I think using the `FieldType => HasField` implication could work nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 19:16:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 19:16:39 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.b799afd3d93e583d8bc1f8371732aea4@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | 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): Tamar has done a bit of working optimising `ld.bfd`: https://github.com/Mistuke/binutils-gdb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 19:19:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 19:19:47 -0000 Subject: [GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set Message-ID: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 19:26:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 19:26:12 -0000 Subject: [GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set In-Reply-To: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> References: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> Message-ID: <063.2743071f3204a9c2046bdd669ea380e1@haskell.org> #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: ethercrow Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ethercrow): * owner: (none) => ethercrow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 19:26:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 19:26:34 -0000 Subject: [GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set In-Reply-To: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> References: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> Message-ID: <063.e1c2c1d6d001903f08ff12670b3a4a96@haskell.org> #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: ethercrow Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ethercrow): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 22 20:53:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Dec 2018 20:53:58 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.71ecdf178ab5a47a47018d7dfd59cbb3@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Replying to [ticket:16084 bgamari]: > One option to fix this is to try using LLD for linking. Unfortunately the msys2 `gcc` does not support `-fuse-ld=lld`. LLD won't magically help here. Latest improvements by Martin Storsjö (mstorsjo) have made LLD able to link some mingw **gcc**-generated code, but, alas, when assembling **GHC**-generated assembly, mingw **gas** produces (I believe this is a sort of "optimisation") non-standard relocations, which LLD is unable to deal with (honestly, I haven't checked if this is still the case, but it was definitely so a year or two ago). For quite a bit of time I have a GHC port which works flawlessly against native Windows SDK and uses clang in MSVC mode and MS or LLD linker. After recent LLD improvements by mstorsjo I've decided to try a less intrusive approach — use clang in mingw mode and LLD linker. That required quite a bit of work and I finally managed to produce stage2 GHC executable, which appeared to be severely broken — it is unable to do anything. TL;DR the current state of affairs is that `lld` **can't** serve as a drop-in replacement for `ld` not only when GNU binutils toolchain is used, but even when `clang` is used as an assembler. Perhaps, the latter might work against mingw SDK built using LLVM tools (e.g. https://github.com/mstorsjo/llvm-mingw), but I never tried this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 00:00:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 00:00:46 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.7ac39159b7f699eebe834b14cfd468d8@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 00:32:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 00:32:30 -0000 Subject: [GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set In-Reply-To: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> References: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> Message-ID: <063.9bd2b5e1c9e82a562b451af177920473@haskell.org> #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: ethercrow Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * cc: AndreasK (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 00:45:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 00:45:11 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.405d8ec25c2e39803b4c9aa8a1c16dc9@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): I have been able to reproduce this issue under `rr`. The backtrace looks like, {{{ LDV_recordDead (c=c at entry=0x42000a60c8, size=4, size at entry=6) at rts/ProfHeap.c:205 205 ctr->c.ldv.void_total += size; >>> bt #0 LDV_recordDead (c=c at entry=0x42000a60c8, size=4, size at entry=6) at rts/ProfHeap.c:205 #1 0x0000000000a790f4 in processHeapClosureForDead (c=0x42000a60c8) at rts/LdvProfile.c:124 #2 processNurseryForDead () at rts/LdvProfile.c:192 #3 LdvCensusForDead (N=1) at rts/LdvProfile.c:236 #4 0x0000000000a8174b in GarbageCollect (collect_gen=collect_gen at entry=1, do_heap_census=do_heap_census at entry=false, gc_type=gc_type at entry=0, cap=cap at entry=0x12afd80 , idle_cap=idle_cap at entry=0x0) at rts/sm/GC.c:461 #5 0x0000000000a6ff55 in scheduleDoGC (pcap=pcap at entry=0x7ffc87622758, force_major=force_major at entry=true, task=0x1e0d660) at rts/Schedule.c:1806 #6 0x0000000000a71110 in exitScheduler (wait_foreign=wait_foreign at entry=false) at rts/Schedule.c:2663 #7 0x0000000000a7cb12 in hs_exit_ (wait_foreign=false) at rts/RtsStartup.c:392 #8 0x0000000000a7cfc5 in shutdownHaskellAndExit (n=0, fastExit=fastExit at entry=0) at rts/RtsStartup.c:553 #9 0x0000000000a6dde1 in hs_main (argc=, argv=, main_closure=, rts_config=...) at rts/RtsMain.c:99 #10 0x0000000000410fd3 in main () }}} `ctr` is `NULL` (which there happens to be an `ASSERT` to check for, but the testcase isn't compiled against the debug RTS). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 01:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 01:26:59 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.a11e739b22163949d7633f4ce3e25f90@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by bgamari): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 06:35:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 06:35:27 -0000 Subject: [GHC] #15915: Add CI for integer-simple In-Reply-To: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> References: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> Message-ID: <061.5238236fbf39266f5d60f753abae1552@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.6.2 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16043 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #16043 Comment: Note that the `integer-simple` build is still fairly far from being green. See #16043. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 06:36:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 06:36:24 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.47b1e670349f536bdb6566f50d631924@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"e59439af3222d151918ad1ad2a03942ce9e6a1ff/ghc" e59439af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e59439af3222d151918ad1ad2a03942ce9e6a1ff" testsuite: Fix broken_without_gmp The lack of types made the previous failure silent, sadly. Improves situation of #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 07:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 07:12:33 -0000 Subject: [GHC] #15274: Numerous validation failures when building GHC with LLVM In-Reply-To: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> References: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> Message-ID: <061.974b920126e3633848fe26b1a11d7efd@haskell.org> #15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.4.3 Resolution: | Keywords: ci-breakage Operating System: 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://gitlab.haskell.org/ghc/ghc/-/jobs/4764|Here]] is a more recent test run via GitLab. In this case we have only 40 failures, all in the `th/` directory and run in the `ext-interp` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 07:21:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 07:21:46 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM Message-ID: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a continuation of #15274. Currently the testsuite fails with around 40 test failures, all in `th/` in the `ext-interp` way when building GHC with `BUILD_FLAVOUR=perf-llvm`: {{{ Unexpected results from: TEST="ClosedFam1TH T10620 T10828 T11721_TH T11797 T12478_1 T12646 T13642 T14060 T15502 T15738 T15792 T15845 T1835 T3920 T4135 T4188 T5037 T5362 T7477 T8761 T8884 T8953 T9262 T9692 T9738 TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_implicitParams TH_reifyDecl1 TH_reifyExplicitForAllFams TH_reifyInstances TH_reifyMkName TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples" SUMMARY for test run started at Sun Dec 23 06:01:39 2018 UTC 0:10:09 spent to go through 6745 total tests, which gave rise to 26266 test cases, of which 19055 were skipped 42 had missing libraries 7040 expected passes 89 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 40 unexpected failures 0 unexpected stat failures Unexpected failures: th/TH_repE2.run TH_repE2 [exit code non-0] (ext- interp) th/TH_repPrim.run TH_repPrim [exit code non-0] (ext- interp) th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext- interp) th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp) th/TH_repGuard.run TH_repGuard [exit code non-0] (ext- interp) th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp) th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp) th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp) th/TH_reifyExplicitForAllFams.run TH_reifyExplicitForAllFams [exit code non-0] (ext-interp) th/T3920.run T3920 [exit code non-0] (ext-interp) th/T4188.run T4188 [exit code non-0] (ext-interp) th/T1835.run T1835 [exit code non-0] (ext-interp) th/T5037.run T5037 [exit code non-0] (ext-interp) th/T5362.run T5362 [exit code non-0] (ext-interp) th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext- interp) th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp) th/T4135.run T4135 [exit code non-0] (ext-interp) th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp) th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext- interp) th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext- interp) th/T7477.run T7477 [exit code non-0] (ext-interp) th/T8884.run T8884 [exit code non-0] (ext-interp) th/T9262.run T9262 [exit code non-0] (ext-interp) th/T9692.run T9692 [exit code non-0] (ext-interp) th/T8953.run T8953 [exit code non-0] (ext-interp) th/T9738.run T9738 [exit code non-0] (ext-interp) th/T10620.run T10620 [exit code non-0] (ext- interp) th/T10828.run T10828 [exit code non-0] (ext- interp) th/T11721_TH.run T11721_TH [exit code non-0] (ext- interp) th/T11797.run T11797 [exit code non-0] (ext- interp) th/T8761.run T8761 [exit code non-0] (ext-interp) th/T12478_1.run T12478_1 [exit code non-0] (ext- interp) th/T12646.run T12646 [exit code non-0] (ext- interp) th/T13642.run T13642 [exit code non-0] (ext- interp) th/T14060.run T14060 [exit code non-0] (ext- interp) th/T15502.run T15502 [exit code non-0] (ext- interp) th/TH_implicitParams.run TH_implicitParams [exit code non-0] (ext-interp) th/T15738.run T15738 [exit code non-0] (ext- interp) th/T15792.run T15792 [exit code non-0] (ext- interp) th/T15845.run T15845 [exit code non-0] (ext- interp) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 07:23:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 07:23:00 -0000 Subject: [GHC] #15274: Numerous validation failures when building GHC with LLVM In-Reply-To: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> References: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> Message-ID: <061.61246ab7b2e3d68464372fcfe83d655e@haskell.org> #15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.4.3 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16087 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * related: => #16087 Comment: Given that the problem seems to be a bit more limited now I have opened a new ticket, #16087, to track the remaining issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 09:37:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 09:37:13 -0000 Subject: [GHC] #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. Message-ID: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. -------------------------------------+------------------------------------- Reporter: hanrai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: getCurrentDirectory | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this message when I type 'getCurrentDirectory' in repl in spacemacs. ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-mingw32): nameModule system $dShow_adyn Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\basicTypes\Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 10:31:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 10:31:17 -0000 Subject: [GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions In-Reply-To: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> References: <049.ca0801ebfc48110f683d3f2c0dfa26ca@haskell.org> Message-ID: <064.610fc19596f9bec3da8e390eff915d7e@haskell.org> #16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: CPRAnalysis 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 sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 10:38:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 10:38:21 -0000 Subject: [GHC] #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code In-Reply-To: <049.c5d88a821daeb893ad451522924a9efa@haskell.org> References: <049.c5d88a821daeb893ad451522924a9efa@haskell.org> Message-ID: <064.7f9ade14e59b744771c583a673396eaa@haskell.org> #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code -------------------------------------+------------------------------------- Reporter: _recursion | Owner: _recursion Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: Resolution: | Keywords: CodeGen, | Performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #16040, #14791, | Differential Rev(s): #8326, #12231, #1498 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 10:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 10:40:07 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.988f34f997e66164a20ee5414f434a94@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: bgamari (added) Comment: hmm having looked at the linker status in 8.6 it's non-trivial to add alignment support there, and changing the linker in the stable branch this much seems like not a good idea.. I think the best option would be to revert ed86e3b531322f74d2c2d00d7ff8662b08fabde6 in the 8.6 branch, we were able to build before without it and nothing changed in the interim between 8.6.2 and 8.6.3 should have increased the amount of symbols. The fix is required in HEAD and works as intended there. Thoughts @bgamari? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 12:19:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 12:19:18 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected Message-ID: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Keywords: seq sprint | Operating System: Linux strictness | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was playing around with strictness and performed following test: {{{#!hs Prelude> x = [True, False] Prelude> :sprint x x = _ Prelude> x `seq` True True Prelude> :sprint x x = _ }}} I completely don't understand why `x = _` at this moment. `seq` must evaluate one level of `x` achieving `x = True : _` to ensure that it is not `undefined`, so why is this information lost? I am testing it on GHCi version 8.6.3, but it is not reproducible on other versions (checked on 8.4.4, 8.2.2 and 7._._). I have asked about it on SO, so if this behavior is intended I kindly ask for explaination here [https://stackoverflow.com/questions/53898220 /sprint-and-seq-together-missing-evaluation] to let others know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 12:52:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 12:52:17 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.9255a89aa2cc742706c485587e5d15c8@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I can't reproduce this: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> let x = [True, False] λ:2> :sprint x x = [True,False] }}} With 8.4.4: {{{ GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> let x = [True, False] λ:2> :sprint x x = [True,False] }}} With 8.2.2: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> let x = [True, False] λ:2> :sprint x x = [True,False] }}} However if I use a list that is not completely static then I can see that `:sprint` doesn't print the evaluated constructor: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> let x = [1..] λ:2> :sprint x x = _ λ:3> x `seq` () () λ:4> :sprint x x = _ }}} Even `:print` doesn't work as expected (I'd expect it to print something like `x : y`): {{{ λ:5> :print x x = (_t1::(Num a, Enum a) => [a]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 13:53:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 13:53:40 -0000 Subject: [GHC] #16090: Typeset Big-O complexities with TeX-style notation in libraries/base Message-ID: <048.f205445a0f55dca5f6d3ebcf0362fce0@haskell.org> #16090: Typeset Big-O complexities with TeX-style notation in libraries/base -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.6.3 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 the code review of #15003, @hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting. See 2 for an example. **Task:** Replace all italic Big-Os in libraries/base with TeX-style notation. 1. - https://github.com/ghc/ghc/pull/239#discussion_r242167454 1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs /Data-TextSet-Unboxed.html#v:size -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 14:00:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 14:00:38 -0000 Subject: [GHC] #16090: Typeset Big-O complexities with TeX-style notation in libraries/base In-Reply-To: <048.f205445a0f55dca5f6d3ebcf0362fce0@haskell.org> References: <048.f205445a0f55dca5f6d3ebcf0362fce0@haskell.org> Message-ID: <063.22aef9db8d9773f0bfb93d9435904977@haskell.org> #16090: Typeset Big-O complexities with TeX-style notation in libraries/base -------------------------------------+------------------------------------- Reporter: supersven | Owner: supersven Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by supersven): * owner: (none) => supersven Old description: > In the code review of #15003, @hvr proposed to typeset Big-Os in TeX- > style instead of using italic (1). This will lead to a more idiomatic > typesetting. > > See 2 for an example. > > **Task:** Replace all italic Big-Os in libraries/base with TeX-style > notation. > > 1. - https://github.com/ghc/ghc/pull/239#discussion_r242167454 > 1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs > /Data-TextSet-Unboxed.html#v:size New description: In the code review of #15003, @hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting. See 2 for an example. **Task:** Replace all italic Big-Os in libraries/base with TeX-style notation. 1. - https://github.com/ghc/ghc/pull/239#discussion_r242167454 1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs /Data-TextSet-Unboxed.html#v:size Please Note: I'm creating this ticket in trac, because the GitLab migration doesn't seem to be finished, yet. If this leads to any troubles: Please don't care about this ticket - When I see that this ticket isn't migrated, I'll simply re-create it in GitLab. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 14:44:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 14:44:41 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.0957031da6caea279ee6cb577cf15948@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by radrow): Replying to [comment:1 osa1]: > I can't reproduce this: > > {{{ > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/omer/rcbackup/.ghci > λ:1> let x = [True, False] > λ:2> :sprint x > x = [True,False] > }}} > > With 8.4.4: > > {{{ > GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/omer/rcbackup/.ghci > λ:1> let x = [True, False] > λ:2> :sprint x > x = [True,False] > }}} > > With 8.2.2: > > {{{ > GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/omer/rcbackup/.ghci > λ:1> let x = [True, False] > λ:2> :sprint x > x = [True,False] > }}} > > However if I use a list that is not completely static then I can see that `:sprint` doesn't print the evaluated constructor: > > {{{ > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/omer/rcbackup/.ghci > λ:1> let x = [1..] > λ:2> :sprint x > x = _ > λ:3> x `seq` () > () > λ:4> :sprint x > x = _ > }}} > > Even `:print` doesn't work as expected (I'd expect it to print something like `x : y`): > > {{{ > λ:5> :print x > x = (_t1::(Num a, Enum a) => [a]) > }}} Note that I am declaring `x` without `let` keyword. {{{ x = [True, False] }}} not {{{ let x = [True, False] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 17:13:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 17:13:45 -0000 Subject: [GHC] #16091: arith011 broken with integer-simple Message-ID: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> #16091: arith011 broken with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `arith011` test fails unexpected when using `integer-simple`. The test output is [[https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw|quite long]] but here is the end: {{{ # negate 0 = 0 # testReal toRational 0 = 0 % 1 toRational 1 = 1 % 1 toRational 2 = 2 % 1 toRational 3 = 3 % 1 # testIntegral Stderr ( arith011 ): arith011: divide by zero *** unexpected failure for arith011(normal) }}} This is concerning since it suggests a behavioral difference between `integer-simple` and `integer-gmp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 17:15:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 17:15:07 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.edc5a9421e5b467ab1aba1803eea620c@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #16091 Comment: I have found that `arith011` fails under `integer-simple` in a way that suggests a behavioral difference between `integer-simple` and `integer- gmp`. I've opened #16091 to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 17:32:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 17:32:31 -0000 Subject: [GHC] #16092: Bug when trying to combine two lists Message-ID: <046.c690ffcd5e903e27c6ba41e1ef0aeb27@haskell.org> #16092: Bug when trying to combine two lists -------------------------------------+------------------------------------- Reporter: sutbult | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- I want to write a function that takes two lists and returns a list that includes every possible combination of elements from the two given lists, using a given function. I thought that this code would work: {{{#!hs combine :: (a -> b -> c) [a] -> [b] -> [c] combine fn alist blist = [fn a b | a <- alist, b <- blist] }}} However, when compiling, this message arises from GHC: Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d/package.cache Using binary package database: /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d/package.cache package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 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.1 wired-in package dph-seq not found. wired-in package dph-par not found. package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 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.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Combine.hs !!! Chasing dependencies: finished in 0.69 milliseconds, allocated 0.222 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2018-12-23 17:18:05.830132761 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Combine.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( Combine.hs, Combine.o ) *** Parser [Main]: !!! Parser [Main]: finished in 1.05 milliseconds, allocated 0.171 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys a_anL[sk:1] b_anM[sk:1] -> c_anN[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 18:49:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 18:49:50 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.a3eb34a7187474f40ea59f83fa66d62a@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I can verify that `let` actually makes a difference here. Curiouser and curiouser! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 18:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 18:50:09 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.519ca8352a35fe7dc08e6c9b28b3dff3@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 18:56:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 18:56:50 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.facf009ec8d756099454fd477cf4c443@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I also observed there is some difference between `let x = 1` and `x = 1` whilst using `ghc-heap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 18:57:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 18:57:50 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.c00f80b6a7c19d124778d5542b9ee943@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Hi, Tamar, which command-line options should I use to get such an output > {{{ > bcoSize = 3 > Sp = 00000000061f0be0 pc = 0 PUSH_G 000000000d8801b4 > Sp = 00000000061f0bd8 pc = 2 ENTER > > --------------------------------------------------------------- > Evaluating: Object 000000000d8801b0 = > }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 19:07:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 19:07:12 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.f3370b95ea05423c3f26875a7af79e49@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Replying to [comment:13 awson]: > Hi, Tamar, which command-line options should I use to get such an output > > {{{ > > bcoSize = 3 > > Sp = 00000000061f0be0 pc = 0 PUSH_G 000000000d8801b4 > > Sp = 00000000061f0bd8 pc = 2 ENTER > > > > --------------------------------------------------------------- > > Evaluating: Object 000000000d8801b0 = > > }}} > ? Hi Awson, with a debug rts linked `+RTS -Di`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 19:33:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 19:33:17 -0000 Subject: [GHC] #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol In-Reply-To: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> References: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> Message-ID: <061.4cbef0c553bec9eed755eb83fd22f6ea@haskell.org> #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.2 Resolution: | Keywords: clang Operating System: OpenBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5461 Wiki Page: | -------------------------------------+------------------------------------- Comment (by klomeli): Thanks, @slyfox! Your patch works for me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 19:35:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 19:35:47 -0000 Subject: [GHC] #16048: Show Instance for IOException discards error code In-Reply-To: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> References: <049.e9faf86a4b0e886dc0e65576193bcde2@haskell.org> Message-ID: <064.f494119bf095c2a65344fed6107e6c82@haskell.org> #16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 20:18:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 20:18:45 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.329abf1c33b40f35299b3d9e8cdde113@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by radrow): `const True $! x` works as expected -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 22:30:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 22:30:00 -0000 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@haskell.org> Message-ID: <059.90e76dbfa0c8d8fc3952fe09bc678bf3@haskell.org> #3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Hey, Ben, I missed the second part of your last post, unfortunately (read the email notification where it only shows the first version). I think there is an interesting design task here. You see, `Data.Binary` deals solely with serialization while GHC's Binary has serialization to the particular type of storage (`BinHandle` structure). As the first step, I think, we could factorize `GHC.Binary` to just use `Data.Binary` instead of trying to completely remove the former at once. For that, something like {{{#!haskell instance Data.Binary a => GHC.Binary a where ... }}} could work? My impression is that most of the instances of `GHC.Binary` are really boring, and all clever business is done directly with `BinHandle`s inside `Iface`-related modules. Discalaimer: I'm not totally sure what this `BinHandle`-related business is about. I read some Notes in the sources but didn't get much. The `IORef BinArray` part makes sense, but the rest… For now, I'm stuck with the error I listed above. Strangely enough, when doing `make test` on my brunch with `Data.Binary`-derived instance of `GHC.Binary ArgFlag`, I randomly get either that one error I mentioned above, or 518 errors (including the one above), all are with "bad stderr" or "bad stdout". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 23:04:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 23:04:12 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found Message-ID: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been trying to track down another plugin issue when I ran into this one. I have the following `TestPlugin.hs` file: {{{#!hs module TestPlugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" return }}} And the following `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} They are both in the same directory. With ghc 8.4.2, I have: {{{ $ ghci-8.4.2 -package ghc Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, two modules loaded. }}} But with ghc 8.6.3, I get: {{{ $ ghci-8.6.3 -package ghc Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin ./TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} My original problem was different actually, so if you can suggest at least a workaround for this without actually fixing it I can proceed to replicate the other one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 23:07:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 23:07:25 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.59668f508eb7dfcad306e679f12b156d@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > I've been trying to track down another plugin issue when I ran into this > one. > > I have the following `TestPlugin.hs` file: > > {{{#!hs > module TestPlugin (plugin) where > > import GhcPlugins > > plugin :: Plugin > plugin = defaultPlugin {installCoreToDos = install} > where install _ todos = return (test : todos) > > test = CoreDoPluginPass "Test" return > }}} > > And the following `Test.hs` file: > > {{{#!hs > {-# OPTIONS_GHC -fplugin TestPlugin #-} > > main :: IO () > main = return () > }}} > > They are both in the same directory. With ghc 8.4.2, I have: > > {{{ > $ ghci-8.4.2 -package ghc Test.hs > GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > Ok, two modules loaded. > }}} > > But with ghc 8.6.3, I get: > > {{{ > $ ghci-8.6.3 -package ghc Test.hs > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-apple-darwin): > mkPluginUsage: file not found > TestPlugin ./TestPlugin.o > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in > ghc:DsUsage > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > My original problem was different actually, so if you can suggest at > least a workaround for this without actually fixing it I can proceed to > replicate the other one. New description: I've been trying to track down another plugin issue when I ran into this one. I have the following `TestPlugin.hs` file: {{{#!hs module TestPlugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" return }}} And the following `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} They are both in the same directory. With ghc 8.4.2, I have: {{{ $ ghci-8.4.2 -package ghc Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, two modules loaded. }}} But with ghc 8.6.3, I get: {{{ $ ghci-8.6.3 -package ghc Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin ./TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem goes away if I first compile `TestPlugin.hs` and create a `.o` file; but nonetheless this seems to be an issue. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 23:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 23:08:34 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.3cd339a2642b6d1d5cfd85bfc04d568f@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > I've been trying to track down another plugin issue when I ran into this > one. > > I have the following `TestPlugin.hs` file: > > {{{#!hs > module TestPlugin (plugin) where > > import GhcPlugins > > plugin :: Plugin > plugin = defaultPlugin {installCoreToDos = install} > where install _ todos = return (test : todos) > > test = CoreDoPluginPass "Test" return > }}} > > And the following `Test.hs` file: > > {{{#!hs > {-# OPTIONS_GHC -fplugin TestPlugin #-} > > main :: IO () > main = return () > }}} > > They are both in the same directory. With ghc 8.4.2, I have: > > {{{ > $ ghci-8.4.2 -package ghc Test.hs > GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > Ok, two modules loaded. > }}} > > But with ghc 8.6.3, I get: > > {{{ > $ ghci-8.6.3 -package ghc Test.hs > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-apple-darwin): > mkPluginUsage: file not found > TestPlugin ./TestPlugin.o > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in > ghc:DsUsage > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > The problem goes away if I first compile `TestPlugin.hs` and create a > `.o` file; but nonetheless this seems to be an issue. New description: I've been trying to track down another plugin issue when I ran into this one. I have the following `TestPlugin.hs` file: {{{#!hs module TestPlugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" return }}} And the following `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} They are both in the same directory. With ghc 8.4.2, I have: {{{ $ ghci-8.4.2 -package ghc Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, two modules loaded. }}} But with ghc 8.6.3, I get: {{{ $ ghci-8.6.3 -package ghc Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin ./TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem goes away if I first compile `TestPlugin.hs` and create a `.o` file; but nonetheless this seems to be at least "unexpected" by ghci. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 23:13:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 23:13:47 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.9dbfb0b1af24120049547225050aebe0@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > I've been trying to track down another plugin issue when I ran into this > one. > > I have the following `TestPlugin.hs` file: > > {{{#!hs > module TestPlugin (plugin) where > > import GhcPlugins > > plugin :: Plugin > plugin = defaultPlugin {installCoreToDos = install} > where install _ todos = return (test : todos) > > test = CoreDoPluginPass "Test" return > }}} > > And the following `Test.hs` file: > > {{{#!hs > {-# OPTIONS_GHC -fplugin TestPlugin #-} > > main :: IO () > main = return () > }}} > > They are both in the same directory. With ghc 8.4.2, I have: > > {{{ > $ ghci-8.4.2 -package ghc Test.hs > GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > Ok, two modules loaded. > }}} > > But with ghc 8.6.3, I get: > > {{{ > $ ghci-8.6.3 -package ghc Test.hs > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-apple-darwin): > mkPluginUsage: file not found > TestPlugin ./TestPlugin.o > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in > ghc:DsUsage > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > The problem goes away if I first compile `TestPlugin.hs` and create a > `.o` file; but nonetheless this seems to be at least "unexpected" by > ghci. New description: I have the following `TestPlugin.hs` file: {{{#!hs module TestPlugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" return }}} And the following `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} They are both in the same directory. With ghc 8.4.2, I have: {{{ $ ghci-8.4.2 -package ghc Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, two modules loaded. }}} But with ghc 8.6.3, I get: {{{ $ ghci-8.6.3 -package ghc Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin ./TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem goes away if I first compile `TestPlugin.hs` and create a `.o` file; but nonetheless this seems to be at least "unexpected" by ghci. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 23 23:14:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Dec 2018 23:14:35 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.d459ca1d0f4ee4aa4570f92c5d601e82@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > I have the following `TestPlugin.hs` file: > > {{{#!hs > module TestPlugin (plugin) where > > import GhcPlugins > > plugin :: Plugin > plugin = defaultPlugin {installCoreToDos = install} > where install _ todos = return (test : todos) > > test = CoreDoPluginPass "Test" return > }}} > > And the following `Test.hs` file: > > {{{#!hs > {-# OPTIONS_GHC -fplugin TestPlugin #-} > > main :: IO () > main = return () > }}} > > They are both in the same directory. With ghc 8.4.2, I have: > > {{{ > $ ghci-8.4.2 -package ghc Test.hs > GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > Ok, two modules loaded. > }}} > > But with ghc 8.6.3, I get: > > {{{ > $ ghci-8.6.3 -package ghc Test.hs > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) > [2 of 2] Compiling Main ( Test.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-apple-darwin): > mkPluginUsage: file not found > TestPlugin ./TestPlugin.o > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in > ghc:DsUsage > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > The problem goes away if I first compile `TestPlugin.hs` and create a > `.o` file; but nonetheless this seems to be at least "unexpected" by > ghci. New description: I have the following `TestPlugin.hs` file: {{{#!hs module TestPlugin (plugin) where import GhcPlugins plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" return }}} And the following `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} They are both in the same directory. With ghc 8.4.2, I have: {{{ $ ghci-8.4.2 -package ghc Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, two modules loaded. }}} But with ghc 8.6.3, I get: {{{ $ ghci-8.6.3 -package ghc Test.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling TestPlugin ( TestPlugin.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin ./TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem goes away if I first compile `TestPlugin.hs` and create a `.o` file; but nonetheless this seems to be a regression from 8.4.2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 01:09:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 01:09:18 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.6ddd4c107ba680c87e1a41e7273552c4@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:12 Phyx-]: > hmm having looked at the linker status in 8.6 it's non-trivial to add alignment support there, and changing the linker in the stable branch this much seems like not a good idea.. > > I think the best option would be to revert ed86e3b531322f74d2c2d00d7ff8662b08fabde6 in the 8.6 branch, we were able to build before without it and nothing changed in the interim between 8.6.2 and 8.6.3 should have increased the amount of symbols. > > The fix is required in HEAD and works as intended there. Thoughts @bgamari? Yes, I can't think of any reasonable alternatives to reverting. Let's do that and cut a yet another release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 03:25:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 03:25:33 -0000 Subject: [GHC] #16092: Bug when trying to combine two lists In-Reply-To: <046.c690ffcd5e903e27c6ba41e1ef0aeb27@haskell.org> References: <046.c690ffcd5e903e27c6ba41e1ef0aeb27@haskell.org> Message-ID: <061.28e275ea741678bd82d528f7d0541b07@haskell.org> #16092: Bug when trying to combine two lists -------------------------------------+------------------------------------- Reporter: sutbult | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13819 Comment: Thanks for the bug report. This is a duplicate of #13819, which has been fixed in GHC 8.4 and later. Note that the type signature that you probably meant to write was `(a -> b -> c) -> [a] -> [b] -> [c]`, not `(a -> b -> c) [a] -> [b] -> [c]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 05:24:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 05:24:18 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM In-Reply-To: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> References: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> Message-ID: <061.8a0a2bb08332ded110f515be20b16409@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.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 Ben Gamari ): In [changeset:"5499f12f32a8deaa2a30c13359473b1178236341/ghc" 5499f12/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5499f12f32a8deaa2a30c13359473b1178236341" testsuite: Mark th tests as broken in ext-interp way in LLVM build flavours This is due to the failures documented in #16087. The condition here could be improved as it matches on `BUILD_FLAVOUR` instead of looking at the compiler flags. However, it's better than nothing and I hope we will be able to fix these issues before long. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 06:33:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 06:33:52 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.80bbc7eca28e35ce0770f0171074519a@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Ah, I tried this, but apparently also with too much verbosity enabled (like `-v4` or so), so these were buried somewhere deep inside. Thanks! > Replying to [comment:13 awson]: > > Hi, Tamar, which command-line options should I use to get such an output > > > {{{ > > > bcoSize = 3 > > > Sp = 00000000061f0be0 pc = 0 PUSH_G 000000000d8801b4 > > > Sp = 00000000061f0bd8 pc = 2 ENTER > > > > > > --------------------------------------------------------------- > > > Evaluating: Object 000000000d8801b0 = > > > }}} > > ? > > Hi Awson, > > with a debug rts linked `+RTS -Di`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 07:57:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 07:57:54 -0000 Subject: [GHC] #9627: Type error with functional dependencies In-Reply-To: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> References: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> Message-ID: <062.f663e4e2c0d3f9f98f7bc1befa29e5a9@haskell.org> #9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Does that "inability" date to before the FDs via CHRs 2006 paper? I think that [https://people.cs.kuleuven.be/~tom.schrijvers/portfolio/haskell2017a.html Elaboration on functional dependencies] (Karachalias and Schrijvers, 2017) does he job nicely. Indeed they use the above example in their motivation section. It describes how to translate fundeps into type families -- so the intermediate language is exactly System FC, as today. I never implemented this, but if someone did then fundeps would acquire the same expressive power as type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 08:13:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 08:13:06 -0000 Subject: [GHC] #15298: Support spliced function names in type signatures in TH declaration quotes In-Reply-To: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> References: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> Message-ID: <058.775f16c9c6ca971c3cd026c8eb7017a5@haskell.org> #15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think this would be too hard to fix. What you want is the ability to splice into a ''binding'' position, a place where a `Name` occurs. We already have the ability to splice into a ''pattern'', and indeed you can say {{{ fDecl1 :: DecsQ fDecl1 = [d| $(varP fName) = $fBody |] }}} where we are splicing a pattern on the LHS of a declaration ` = `. But that won't work for type signatures where you want a `Name`. If we had {{{ fName :: Q Name fName = ... }}} then we jolly well ought to be able to splice it in in place of a name, even in (say) data type declarations {{{ fDecl1 :: DecsQ fDecl1 = [d| data $fName = A | B |] }}} Nothing truly tricky there. But it'd be some work to implement: * A number of places in `HsSyn` that currently have a `Name`, or more precisely `(IdP pass)`, would need an extra constructor for a splice. Specifically: * The `tcdLName` field of a `TyClDecl` * The `fun_id` field of a `HsBindLR` * The second field of a `TypeSig` in the `Sig` type -- and perhaps other constructors too. * The renamer would have to run those splices. * We can't do dependency analysis until we'd run those splices, because we don't know what's being bound. (That is already the case with pattern bindings that have a splice.) But maybe that doesn't matter, because the renamer will run those splices, maybe the dependency analysis occurs after that. I'm not quite sure. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 08:40:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 08:40:00 -0000 Subject: [GHC] #16070: Better inferred signatures In-Reply-To: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> References: <046.67080eabf9dd5abaee5f700cfb5e42d5@haskell.org> Message-ID: <061.5064b2ba23a814622e576b7e5d00e0c9@haskell.org> #16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I was thinking of the following algorithm. The algorithm is used when inferring the type of a function (and only on that occasion). Specifically, it is an enhancement to the existing function `TcType.mkMinimalBySCs`. Suppose `C` is declared thus, with a type variable on the left of a superclass equality: {{{ class (b ~ ty, ...) => C a b c }}} `mkMinimalBySCs` is given a list of predicates, `preds`, such as `(Ord a, Eq a)`, or `(HasField "foo" r (FieldType "foo" r))`. It's business is to abbreviate it to an equivalent one. * For each predicate `(C t1 t2 t3)`, where `t2` = `ty[t1/a,t3/c]`, then replace all occurrences of `t2` in `preds` with `x` where is a fresh skolem variable. So if {{{ preds = [ HasField "bar" r (FieldType "bar" r) , HasField "foo" r (FieldType "bar" r) ] }}} we'll spot the condition on the first predicate, and replace `(FieldType "bar" r)` with `x` throughout: {{{ preds = [ HasField "bar" r x , HasField "foo" r x ] }}} Now we need to * Quantify over `x` as well as whatever else we were quantifying over before * Apply that same substitution to the type we are quantifying over (to catch the case of `g` in the `Description`. So it's more than just modifyign `mkMinimalBySCs`. There's something a bit unsatisfying about this: during flattening we have all these common sub-expressions neatly identified. It seems a pity to un- flatten them away only to then have to rediscover them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 08:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 08:47:30 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.918b3970e03c7e7972bd2b204f9fcd0c@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 simonpj): Well, it's in the tree before 8.8 forks, so I suppose it'll automatically be in 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 08:48:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 08:48:54 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.1fed17bc67ad3cf3e3bd5c28218484a6@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 osa1): I thought we're going to have another 8.6 release to fix #16057, if that happens maybe we should include this too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 09:14:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 09:14:16 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.b8b1aa0ac936b19b23dd75e047ce97fe@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): All very curious. The GHCi debugger, which is responsible for `:sprint` and friends, needs a love and attention, if anyone feels able to offer it. Its's tricky stuff, because it uses special primitives to interrogate the heap and decomposes heap objects, which never usually happens in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 09:20:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 09:20:59 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.b8ee58521c7b5d83ff9ee342668cf80d@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.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 simonpj): > I thought we're going to have another 8.6 release to fix #16057, if that happens maybe we should include this too? Maybe. I don't think it'd destablise anything. But nor does it fix any bugs that anyone has reported. Do you think we could generate bogus code if this is not fixed? If so, is a test case easy to construct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 12:41:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 12:41:48 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.a45269bed6fc07ec8f580531377db282@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Gitlab Merge #14551 | Request 34 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Phab:D5444 => Gitlab Merge Request 34 Comment: Moved patch from Phabricator to Gitlab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 12:55:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 12:55:34 -0000 Subject: [GHC] #13322: Pattern synonyms in hs-boot files In-Reply-To: <045.6b7aa07fdcb8793a715c6f96fb599d5e@haskell.org> References: <045.6b7aa07fdcb8793a715c6f96fb599d5e@haskell.org> Message-ID: <060.61d71f4ccce92446ccda219626742c9c@haskell.org> #13322: Pattern synonyms in hs-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: | 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 monoidal): * cc: monoidal (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 13:22:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 13:22:55 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.224759129a988dfcb7af3335bb0e7238@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Gitlab Merge #14551 | Request 35 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Gitlab Merge Request 34 => Gitlab Merge Request 35 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 14:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 14:10:11 -0000 Subject: [GHC] #9627: Type error with functional dependencies In-Reply-To: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> References: <047.4796ed7275cf4f912175b5a495799bce@haskell.org> Message-ID: <062.4538d6dd03bd3346ffccb3840da7de6c@haskell.org> #9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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 AntC): Replying to [comment:4 simonpj]: > > I think that [https://people.cs.kuleuven.be/~tom.schrijvers/portfolio/haskell2017a.html Elaboration on functional dependencies] (Karachalias and Schrijvers, 2017) does he job nicely. Respectfully (to both the authors of the paper and to Simon): I disagree. The paper doesn't consider overlapping instances. (Neither did the `FDs via CHRs` paper.) > Indeed they use the above example in their motivation section. It describes how to translate fundeps into type families -- so the intermediate language is exactly System FC, as today. > (Yes I linked to the paper in comment:3.) Then how does System FC handle overlaps? Does it cope only with Closed Type Families? Then using System FC won't work for separate compilation of overlapping instances or instances that have the potential for overlap but are non-confluent (ref the Users Guide). Let me be careful to say that GHC's current implementation of these 'features' is more by accident than design. They can be used very powerfully; they can also very easily lead to incoherence and confusion. That's why I ref'd #15632. > I never implemented this, but if someone did then fundeps would acquire the same expressive power as type families. Hmm. There's different interpretations of "expressive power" in play here. Thanks to overlaps, I say FunDeps are ''more'' expressive than TFs: then I don't want FunDeps to be hobbled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 18:03:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 18:03:09 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.eb3febd08dbee19ee38a80e63dcd9649@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thank you for tracking this down, Tamar! We would be truly lost without you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 21:59:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 21:59:33 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] Message-ID: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On current HEAD ghc fails build on powerpc32: {{{ $ ./configure --target=powerpc-unknown-linux-gnu $ make ... "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181223 for powerpc-unknown-linux): getRegister(ppc) I64[I32[BaseReg + 812] + 64] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/nativeGen/PPC/CodeGen.hs:693:24 in ghc:PPC.CodeGen }}} {{{ $ inplace/bin/ghc-stage1 --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","powerpc-unknown-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","powerpc-unknown-linux-gnu-gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","powerpc-unknown-linux-gnu-ld.gold") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","powerpc-unknown-linux-gnu-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","powerpc-unknown-linux-gnu-ranlib") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","YES") ,("target os","OSLinux") ,("target arch","ArchPPC") ,("target word size","4") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.7.20181223") ,("Project Git commit id","bd8a6bde2ee73e599800137b9428a401bc105985") ,("Booter version","8.4.4") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","powerpc-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p debug_p") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/slyfox/dev/git/ghc-ppc/inplace/lib") ,("Global Package DB","/home/slyfox/dev/git/ghc- ppc/inplace/lib/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 24 22:19:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Dec 2018 22:19:27 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.4e9d7060c01aa10ab453cbcb0bae8dec@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: trommler (added) Comment: I think it happens in '''stg_gc_noregs''' function on '''StgTSO_alloc_limit(CurrentTSO) `lt` (0::I64)''' expression. CCing Peter in case it's an obvious omission in CMM or NCG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 03:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 03:28:58 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.b2cea1829893477c5ececdf293ab4f92@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6d9d6f9ab545eb11b4a1b72ea903a0f804109f16/ghc" 6d9d6f9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d9d6f9ab545eb11b4a1b72ea903a0f804109f16" testsuite: Enable T11627a on Darwin The retainer profiler no longer uses the C stack for its mark stack (#14758). Consequently even the small C stack provided on Darwin should be sufficient to run this test. See #11627 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 03:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 03:28:58 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.657bb78a58f764a06ac927e2a0eaedcb@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Phab:D5351 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6d9d6f9ab545eb11b4a1b72ea903a0f804109f16/ghc" 6d9d6f9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d9d6f9ab545eb11b4a1b72ea903a0f804109f16" testsuite: Enable T11627a on Darwin The retainer profiler no longer uses the C stack for its mark stack (#14758). Consequently even the small C stack provided on Darwin should be sufficient to run this test. See #11627 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 03:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 03:28:58 -0000 Subject: [GHC] #16043: Lots of testsuite output breaks with integer-simple In-Reply-To: <046.cea639b79d893836083fb857e93f8b61@haskell.org> References: <046.cea639b79d893836083fb857e93f8b61@haskell.org> Message-ID: <061.50cf9ab6b5b07912cbe9373422f4a93b@haskell.org> #16043: Lots of testsuite output breaks with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"993782073c0b380908e9541c40c6c5849dbacfec/ghc" 9937820/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="993782073c0b380908e9541c40c6c5849dbacfec" testsuite: Fix a variety of issues when building with integer-simple * Mark arith011 as broken with integer-simple As noted in #16091, arith011 fails when run against integer-simple with a "divide by zero" exception. This suggests that integer-gmp and integer- simple are handling division by zero differently. * This also fixes broken_without_gmp; the lack of types made the previous failure silent, sadly. Improves situation of #16043. * Mark several tests implicitly depending upon integer-gmp as broken with integer-simple. These expect to see Core coming from integer-gmp, which breaks with integer-simple. * Increase runtime timeout multiplier of T11627a with integer-simple I previously saw that T11627a timed out in all profiling ways when run against integer-simple. I suspect this is due to integer-simple's rather verbose heap representation. Let's see whether increasing the runtime timeout helps. Fixes test for #11627. This is all in service of fixing #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 03:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 03:28:58 -0000 Subject: [GHC] #16091: arith011 broken with integer-simple In-Reply-To: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> References: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> Message-ID: <061.318968983bf239b5685a083497eca96f@haskell.org> #16091: arith011 broken with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"993782073c0b380908e9541c40c6c5849dbacfec/ghc" 9937820/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="993782073c0b380908e9541c40c6c5849dbacfec" testsuite: Fix a variety of issues when building with integer-simple * Mark arith011 as broken with integer-simple As noted in #16091, arith011 fails when run against integer-simple with a "divide by zero" exception. This suggests that integer-gmp and integer- simple are handling division by zero differently. * This also fixes broken_without_gmp; the lack of types made the previous failure silent, sadly. Improves situation of #16043. * Mark several tests implicitly depending upon integer-gmp as broken with integer-simple. These expect to see Core coming from integer-gmp, which breaks with integer-simple. * Increase runtime timeout multiplier of T11627a with integer-simple I previously saw that T11627a timed out in all profiling ways when run against integer-simple. I suspect this is due to integer-simple's rather verbose heap representation. Let's see whether increasing the runtime timeout helps. Fixes test for #11627. This is all in service of fixing #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 03:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 03:28:58 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.a84e5dd2619c426ab8d2a047bf2b9bbc@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"993782073c0b380908e9541c40c6c5849dbacfec/ghc" 9937820/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="993782073c0b380908e9541c40c6c5849dbacfec" testsuite: Fix a variety of issues when building with integer-simple * Mark arith011 as broken with integer-simple As noted in #16091, arith011 fails when run against integer-simple with a "divide by zero" exception. This suggests that integer-gmp and integer- simple are handling division by zero differently. * This also fixes broken_without_gmp; the lack of types made the previous failure silent, sadly. Improves situation of #16043. * Mark several tests implicitly depending upon integer-gmp as broken with integer-simple. These expect to see Core coming from integer-gmp, which breaks with integer-simple. * Increase runtime timeout multiplier of T11627a with integer-simple I previously saw that T11627a timed out in all profiling ways when run against integer-simple. I suspect this is due to integer-simple's rather verbose heap representation. Let's see whether increasing the runtime timeout helps. Fixes test for #11627. This is all in service of fixing #16043. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 04:00:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 04:00:51 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.b39c4960f884df29d72469b0c86782bb@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | 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): > LLD won't magically help here. Latest improvements by Martin Storsjö (mstorsjo) have made LLD able to link some mingw gcc-generated code, but, alas, when assembling GHC-generated assembly, mingw gas produces (I believe this is a sort of "optimisation") non-standard relocations. Frankly I wonder how difficult it would be to add support for these relocations. Given that LLVM code is generally pretty approachable I suspect that would be the easiest path forward. In the meantime I have been pursuing testing Tamar's binutils patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 05:23:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 05:23:36 -0000 Subject: [GHC] #16038: Simplifier incorrectly breaks recursive groups In-Reply-To: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> References: <043.1cfb6edca2e1be1d2d9a998afc27f47a@haskell.org> Message-ID: <058.cd8ac4feab3d7cb806a076c544cc7194@haskell.org> #16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: Fair enough, let's close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 06:12:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 06:12:45 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.ed3b8f066ce045131785c99376e9e7b1@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I think it's easy, but (as I've already mentioned) the other problems exist. Mingw binutils introduce a lot of non-standard things, which `LLD` didn't support at all until recently, now some support have appeared, but AFAIUI, things go best when mingw sdk is built by LLVM toolsuite, not by mingw gcc/binutils. And a general problem is that wrong linkage bugs are *very* hard to debug, this is why I haven't ever tried to continue my mingw clang/lld experiment — it might consume an unpredictable amount of time to understand what is wrong with the generated ghc executable — all the symptoms are that the image file is invalid, since the OS can't even load it properly. Replying to [comment:7 bgamari]: > Frankly I wonder how difficult it would be to add support for these relocations. Given that LLVM code is generally pretty approachable I suspect that would be the easiest path forward. > > In the meantime I have been pursuing testing Tamar's binutils patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 10:01:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 10:01:53 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.b502906ea6fd4ab8b826cbbaa566201e@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.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 bgamari): Strangely this appears to be nondeterministic: some testsuite runs pass while others fail. I've actually been unable to even reproduce the failure locally. Given it's so fragile we can't even mark the test as broken; we will merely need to skip it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 13:45:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 13:45:04 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.82b560bb5a708fc073aed40dd371ceec@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I think there's another bug here which is that `let x = ...` and `x = ...` are supposed to be the same thing in GHCi, but they're currently not. I vaguely remember the ticket that requested supporting `x = ...` syntax in GHCi (without the `let`), but I don't remember how it was implemented. I guess there's a bug there and perhaps we should track it in another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 16:17:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 16:17:53 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.9a81c0a97323c3106844b882b1d11c8d@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"7bfc1e81377d1e37069cf52bd090530124dcd871/ghc" 7bfc1e81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7bfc1e81377d1e37069cf52bd090530124dcd871" testsuite: Skip ffi018_ghci when unregisterised As noted in #16085 this test is fragile in unregisterised compilers. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 16:19:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 16:19:36 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.f53af9bf54303d069c62db8e63371c87@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by Ben Gamari ): In [changeset:"9b65ae69fbeddcb9df7c70b71c9cf62be1e03dbd/ghc" 9b65ae69/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b65ae69fbeddcb9df7c70b71c9cf62be1e03dbd" rts: Turn ASSERT in LDV_recordDead into a normal if As reported in #15382 the `ASSERT(ctr != NULL)` is currently getting routinely hit during testsuite runs. While this is certainly a bug I would far prefer getting a proper error message than a segmentation fault. Consequently I'm turning the `ASSERT` into a proper `if` so we get a proper error in non- debug builds. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 17:43:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 17:43:47 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.5584ed3c21eef409f1198db5318fe1f8@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I've been trying to move `mkRational`, but it doesn't seem to make any sense to put it into base itself... (ie `GHC.Real`). If we put it into there, won't it expose it to base? It seems like a strange thing to do, to me. The reason it needs to be exposed *somewhere* is that it's looked up globally by id, here: https://github.com/JulianLeviston/ghc/pull/1/files #diff-116aa33edfc74c0dc68e471f30ac63d5R101 but perhaps we don't actually need to look it up there? I'm pretty lost. Here's the code... it's the bottom of the `dsLit` function in `compiler/deSugar/Matchlit.hs`: {{{ HsRat _ fl _ -> case fl of FL { fl_signi = fl_signi, fl_exp = fl_exp } -> do mkRational <- dsLookupGlobalId mkRationalName litI <- mkIntegerExpr fl_signi litE <- mkIntegerExpr fl_exp return ((Var mkRational) `App` litI `App` litE) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 18:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 18:01:47 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.d0c62fb0215b55d9755c29fe7bbc7bf9@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #7253 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 18:22:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 18:22:24 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.a5a307a175cd22fe16ab8d2e90e9481f@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): As discussed on IRC, try to get it compiling for now and then we can worry about where to put the functions. [https://github.com/JulianLeviston/ghc/pull/1/files#diff- 199051a796530164d94214a54aadd294R1216 In this line] you specify `mkRational`s module as `GHC.Real` so that's where it should be. When you do that your `dsLookupGlobalId` call should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 21:12:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 21:12:54 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.bcb4c3cc23a428537ed80f8b930076ad@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari no worries :) Happy holidays! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 21:57:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 21:57:44 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.618826c97b2f6aa345c065f646bbbd67@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.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 bgamari): Hmm, I have also seen this same issue in the `foreignInterruptible` and `T7040_ghci` tests, also non-deterministically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 21:58:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 21:58:53 -0000 Subject: [GHC] #15915: Add CI for integer-simple In-Reply-To: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> References: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> Message-ID: <061.fd7ad1244102a5bb3387eda97249d726@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.6.2 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16043 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5569eefff5aabaa53b7e7e50b9ea4b177559deb1/ghc" 5569eef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5569eefff5aabaa53b7e7e50b9ea4b177559deb1" gitlab-ci: Require that integer-simple configuration passes The last step of #15915. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 25 21:58:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Dec 2018 21:58:53 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.6dc29a3d4d0d30b2402eba8499a7b962@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bb06c6b12c4a24c049fa8fbc9c470f12d625ca18/ghc" bb06c6b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb06c6b12c4a24c049fa8fbc9c470f12d625ca18" gitlab-ci: Allow Windows to fail for now While we sort out #16084. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 02:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 02:27:45 -0000 Subject: [GHC] #16095: Infinite loop during error reporting (unkillable, OOM) Message-ID: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> #16095: Infinite loop during error reporting (unkillable, OOM) -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the repro snippet produces the following incomplete output and hangs GHC: {{{ $ ghc repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) repro.hs:16:22: error: }}} The GHC process then ignores Ctrl-C -- so it must be killed with SIGKILL. This minimal snippet depends on `generics-sop` (tested with version `0.4.0.0`). Sadly I didn't find a constraint in `base` to cause this behavior.. {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Generics.SOP (HasDatatypeInfo) data family TF i a :: * data instance TF i a = R class C i a where method :: TF i a instance C i () where instance HasDatatypeInfo a => C i a where method = undefined function function :: C i a => TF i a function = method main = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 02:30:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 02:30:27 -0000 Subject: [GHC] #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) (was: Infinite loop during error reporting (unkillable, OOM)) In-Reply-To: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> References: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> Message-ID: <063.bb9bd463f50c1ee5c34b690fda6eb658@haskell.org> #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by _deepfire: Old description: > Compiling the repro snippet produces the following incomplete output and > hangs GHC: > {{{ > $ ghc repro.hs > [1 of 1] Compiling Main ( repro.hs, repro.o ) > > repro.hs:16:22: error: > }}} > > The GHC process then ignores Ctrl-C -- so it must be killed with SIGKILL. > > This minimal snippet depends on `generics-sop` (tested with version > `0.4.0.0`). > Sadly I didn't find a constraint in `base` to cause this behavior.. > > {{{#!hs > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies #-} > > import Generics.SOP (HasDatatypeInfo) > > data family TF i a :: * > data instance TF i a = R > > class C i a where > method :: TF i a > > instance C i () where > > instance HasDatatypeInfo a => C i a where > method = undefined function > > function :: C i a => TF i a > function = method > > main = undefined > }}} New description: Compiling the repro snippet produces the following incomplete output and hangs GHC: {{{ $ ghc repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) repro.hs:16:22: error: }}} The GHC process ignores SIGINT -- so it must be killed with SIGKILL. The memory usage grows, until it consumes all memory (~30G RAM + swap) and is terminated by the OOM killer. This minimal snippet depends on `generics-sop` (tested with version `0.4.0.0`). Sadly I didn't find a constraint in `base` to cause this behavior.. {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Generics.SOP (HasDatatypeInfo) data family TF i a :: * data instance TF i a = R class C i a where method :: TF i a instance C i () where instance HasDatatypeInfo a => C i a where method = undefined function function :: C i a => TF i a function = method main = undefined }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 02:31:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 02:31:10 -0000 Subject: [GHC] #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) In-Reply-To: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> References: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> Message-ID: <063.37b4362fd1e7207b422681f8801a1c0f@haskell.org> #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by _deepfire: Old description: > Compiling the repro snippet produces the following incomplete output and > hangs GHC: > {{{ > $ ghc repro.hs > [1 of 1] Compiling Main ( repro.hs, repro.o ) > > repro.hs:16:22: error: > }}} > > The GHC process ignores SIGINT -- so it must be killed with SIGKILL. > The memory usage grows, until it consumes all memory (~30G RAM + swap) > and is terminated by the OOM killer. > > This minimal snippet depends on `generics-sop` (tested with version > `0.4.0.0`). > Sadly I didn't find a constraint in `base` to cause this behavior.. > > {{{#!hs > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies #-} > > import Generics.SOP (HasDatatypeInfo) > > data family TF i a :: * > data instance TF i a = R > > class C i a where > method :: TF i a > > instance C i () where > > instance HasDatatypeInfo a => C i a where > method = undefined function > > function :: C i a => TF i a > function = method > > main = undefined > }}} New description: Compiling the repro snippet produces the following incomplete output and hangs GHC: {{{ $ ghc repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) repro.hs:16:22: error: }}} The GHC process ignores SIGINT -- so it must be killed with SIGKILL. The memory usage grows, until it consumes all memory (~30G RAM + swap) and is terminated by the OOM killer. This minimal snippet depends on `generics-sop` (tested with version `0.4.0.0`). Sadly I didn't find a constraint in `base` to cause this behavior.. {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Generics.SOP (HasDatatypeInfo) data family TF i a :: * data instance TF i a = R class C i a where method :: TF i a instance C i () where instance HasDatatypeInfo a => C i a where method = undefined function function :: C i a => TF i a function = method main = undefined }}} Affects 8.4.3 and 8.6.1. Not tested on 8.6.2 & 8.6.3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 02:42:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 02:42:01 -0000 Subject: [GHC] #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) In-Reply-To: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> References: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> Message-ID: <063.1bedc97b8a89239922453a558c068000@haskell.org> #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): When the `HasDatatypeInfo` constraint is removed, the error in the code can be printed: {{{ Overlapping instances for C i0 a0 arising from a use of ‘function’ Matching instances: instance C i a -- Defined at doc/ghc-repro-16095.hs:15:10 instance C i () -- Defined at doc/ghc-repro-16095.hs:13:10 (The choice depends on the instantiation of ‘i0, a0’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) In the first argument of ‘undefined’, namely ‘function’ In the expression: undefined function In an equation for ‘method’: method = undefined function }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 02:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 02:58:37 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.55accd23e8cf96f0763e427c15009c4b@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"942b501972139ed95b49b75cb8c0523b460f6d10/ghc" 942b5019/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="942b501972139ed95b49b75cb8c0523b460f6d10" gitlab-ci: Try only building Windows in the quick flavour It seems no matter how many machines I throw at Windows it's constantly behind. Perhaps the quick build flavour will be fast enough to allow us to keep until while we sort out our toolchain issues (#16084). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 03:48:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 03:48:46 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.40f8e41ec1c89223d084ce51155b3980@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 Fuuzetsu): * cc: Fuuzetsu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 04:25:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 04:25:05 -0000 Subject: [GHC] #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. In-Reply-To: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> References: <048.a67e42a88cff919de9303172d1975ebe@haskell.org> Message-ID: <063.f08601442a124567182b8ccf6d590640@haskell.org> #16057: GHC 8.6.3 byte-code interpreter segfaults on any object. -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.4 Component: Runtime System | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16071 #13617 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * milestone: => 8.6.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 04:34:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 04:34:17 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi Message-ID: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer: {{{ ~ $ ghci -ddump-bcos GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help ... λ:1> let x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_s1vF = ... in ... bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 PUSH_L 0 PUSH_G GHC.Types.True PACK : 2 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_L 0 PUSH_APPLY_P PUSH_G GHC.Base.returnIO SLIDE 3 3 ENTER λ:2> x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO x1_r1wJ#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool) bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 ENTER ProtoBCO Ghci2.x#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ bitmap: 0 [] PUSH_G x1_r1wJ PUSH_G GHC.Types.True PACK : 2 ENTER ... }}} Expected behavior: these two should generate the same byte code, and should be subject to same checks (e.g. for shadowing). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 04:34:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 04:34:53 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.1adf22457400750cbf7e90d96296f1f4@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I did a little bit of digging. The only difference between `:sprint` and `:print` is that `:sprint` doesn't bind "suspensions". So sometimes you see a `_` with `:sprint`, but `:print` gives you a variable instead (see last two code snippets in comment:1). What is a "suspension"? `RtClosureInspect` has a simplistic view of Haskell runtime objects, and it treats these as "suspensions": - `BLACKHOLE`s that point to `TSO` or `BLOCKING_QUEUE`s (as expected, becuase these are thunks that are not evaluated yet) - Anything other than `MUT_VAR` and `CONSTR`s. When we do `:print x` what `RtClosureInspect` uses `ghc-heap` to inspect the value of `x` and sees an `AP` that looks like this: {{{ APClosure { info = StgInfoTable { entry = Nothing , ptrs = 0 , nptrs = 0 , tipe = AP , srtlen = 0 , code = Nothing } , arity = 709704 , n_args = 0 , fun = () <-- this is actually a `ForeignRef HValue`, but shown as () because we cna't show `ForeignRef`s , payload = [] } }}} which is probably a bug in `ghc-heap` because even if `x` is really an `AP` the `arity` field makes no sense (it should be 0). For reference, the BCOs generated for `x = [True,False]`: {{{ ProtoBCO x1_r1zt#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool) bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 ENTER ProtoBCO Ghci1.x#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1zt bitmap: 0 [] PUSH_G x1_r1zt PUSH_G GHC.Types.True PACK : 2 ENTER }}} BCO generated for `let x = [True,False]`: {{{ ProtoBCO ExprTopLevel_E0#0 []: let sat_s1yG = ... in ... bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 PUSH_L 0 PUSH_G GHC.Types.True PACK : 2 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_L 0 PUSH_APPLY_P PUSH_G GHC.Base.returnIO SLIDE 3 3 ENTER }}} These should really be identical. For this I filed #16096. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 04:36:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 04:36:07 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.a3e7f062449a9168ca56a9a66cfbf5a9@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #16096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #7253 => #7253, #16096 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 04:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 04:40:38 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.b89985f9fdb72cfce1ecdece4c279d46@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > With #7253 we implemented support for `x = ...` in GHCi which is supposed > to do the same thing as `let x = ...`, but they're currently different, > as observed in #16089, #15721, and probably in other tickets. Here's a > reproducer: > > {{{ > ~ $ ghci -ddump-bcos > GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > > ... > > λ:1> let x = [True,False] > > ==================== Proto-BCOs ==================== > ProtoBCO ExprTopLevel_E0#0 []: > let sat_s1vF = ... in ... > bitmap: 0 [] > PUSH_G GHC.Types.[] > PUSH_G GHC.Types.False > PACK : 2 > PUSH_L 0 > PUSH_G GHC.Types.True > PACK : 2 > PUSH_G GHC.Types.[] > PUSH_L 1 > PACK : 2 > PUSH_L 0 > PUSH_APPLY_P > PUSH_G GHC.Base.returnIO > SLIDE 3 3 > ENTER > > λ:2> x = [True,False] > > ==================== Proto-BCOs ==================== > ProtoBCO x1_r1wJ#0 []: > GHC.Types.: > @ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool) > bitmap: 0 [] > PUSH_G GHC.Types.[] > PUSH_G GHC.Types.False > PACK : 2 > ENTER > > ProtoBCO Ghci2.x#0 []: > GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ > bitmap: 0 [] > PUSH_G x1_r1wJ > PUSH_G GHC.Types.True > PACK : 2 > ENTER > > ... > }}} > > Expected behavior: these two should generate the same byte code, and > should be subject to same checks (e.g. for shadowing). New description: With #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer: {{{ ~ $ ghci -ddump-bcos GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help ... λ:1> let x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_s1vF = ... in ... bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 PUSH_L 0 PUSH_G GHC.Types.True PACK : 2 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_L 0 PUSH_APPLY_P PUSH_G GHC.Base.returnIO SLIDE 3 3 ENTER λ:2> x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO x1_r1wJ#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool) bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 ENTER ProtoBCO Ghci2.x#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ bitmap: 0 [] PUSH_G x1_r1wJ PUSH_G GHC.Types.True PACK : 2 ENTER ... }}} Expected behavior: these two should generate the same byte code, and should be subject to same checks (e.g. for shadowing). (Example above uses 8.4.4, but this can be reproduced with GHC HEAD too) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 05:16:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 05:16:18 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.49c391006958a5f9c9b4f745ce8458f9@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.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 osa1): The problem is this: in `GHCi.UI.runStmt` we use GHC's `parseStmt` to parse the statements. If the parser fails then we assume it's a declaration. For statements we do `run_stmt`, for decls we do `run_decl`. So effectively we compile `x = 1` as a top-level binding (a declaration) but `let x = 1` is compiled as if it's a `do` statement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 06:23:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 06:23:38 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.4d570d0367d9ad86264db5539b8a5410@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => osa1 Comment: I have a fix, will submit a diff soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 07:54:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 07:54:36 -0000 Subject: [GHC] #12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer In-Reply-To: <045.f36b0b7706a40f3b8c84a5fcb4001df6@haskell.org> References: <045.f36b0b7706a40f3b8c84a5fcb4001df6@haskell.org> Message-ID: <060.8557070b7c859046f594ee6a8d68902e@haskell.org> #12034: Template Haskell + hs-boot = Not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 8.0.1-rc2 Resolution: | Keywords: backpack hs- | boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): I have a situation with a {{{makeClassy}} classy lens class cycle that I cannot break (modulo manually expanding the TH). I'd like something like an ''intra''-module hs-boot file to fix this. I gather from this issue that I shouldn't waste time breaking up my module, as .hs-boot as it currently stands won't save me. Replying to [comment:3 ezyang]: > Here is a restriction for hs-boot files and TH which might solve this problem.... Ezyang's proposal would also not help because the splice defines the Has* class. I believe the staging restriction as it currently stands ought just to apply to code executed as part of a TH splice. Quoted variable resolution should be fine: if and only the user uses one of the APIs to learn more about a defintion, they should only hit a Nothing/exception because a staging restriction. intra-module hs-boot would then be a way to assert that some further-down splice defines some names, enough for names, including quoted names, to resolve. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 10:26:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 10:26:51 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.67153b1fc2015da49b26974fb4dbbd24@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] ----------------------------------------+-------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 trommler): * owner: (none) => trommler * failure: None/Unknown => Building GHC failed * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => powerpc Comment: I think the panic is caused by a lack of 64-bit comparison operations on 32-bit PowerPC. The change in `stg_gc_noregs` is in changeset:d70b19bfb5ed79b22c2ac31e22f46782fc47a117. This commit has an implementation for X86 but not for PowerPC. I can provide a patch but I will need help with testing. There is no support for PowerPC 32-bit in openSUSE anymore :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 10:28:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 10:28:39 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.d1cf73827aa0bcc9ac50f318324b68cf@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] ----------------------------------------+-------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 trommler): * cc: hvr (added) Comment: I am copying @hvr for the AIX port, which is also 32-bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 13:14:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 13:14:04 -0000 Subject: [GHC] #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) In-Reply-To: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> References: <048.b75cee7cbcc59d8d5879c5da1654997f@haskell.org> Message-ID: <063.0288940a67977d1514a010c3c2b9e17b@haskell.org> #16095: Infinite loop during error reporting (ignores SIGINT/SIGTERM, then OOMs) -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): Another, different repro for what seems to be a related problem: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeOperators #-} module Repro where import Generics.SOP recover :: forall a xs. (Code a ~ '[xs], HasDatatypeInfo a) => a recover = case datatypeInfo (Proxy @a) :: DatatypeInfo '[xs] of Newtype _ _ _ -> let sop :: NP [] xs = (undefined :: forall c xs . All c xs => NP [] xs) in undefined }}} ..once again, dependent on `generics-sop`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 13:49:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 13:49:40 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.e2af365c6cc5cedeaa0c386274b321d5@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.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): Two things to keep in mind when fixing this: * #11606 is also caused by this discrepancy, so it would be worth checking to see if this is fixed. * I had to implement a hack in my fix for #12091 (ddb870bf7055ccc8ff8b86c161f31aad81d01add) to account for this discrepancy, so if this is fixed, we might be able to remove this hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 14:22:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 14:22:22 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.16660beaf62530bd434d5a7ce0adfa7b@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/42 Comment: The patch in [[https://gitlab.haskell.org/ghc/ghc/merge_requests/42| merge request 42]] has passed validate on powerpc64le Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 14:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 14:27:45 -0000 Subject: [GHC] #16031: Show instance for Data.Fixed does not show parentheses for negatives In-Reply-To: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> References: <047.ddd3380a5392d84c7de236b9a8a79b7b@haskell.org> Message-ID: <062.eb094b1f0c65e672fde83777ef138231@haskell.org> #16031: Show instance for Data.Fixed does not show parentheses for negatives -------------------------------------+------------------------------------- Reporter: skeuchel | Owner: supersven Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.7 Resolution: | Keywords: Data.Fixed, | Show, newcomer 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 supersven): * status: new => patch Comment: Hey, I created a merge request: https://gitlab.haskell.org/ghc/ghc/merge_requests/41 Best regards, Sven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 14:31:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 14:31:15 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.c4679c404258e35c00f25077a0ca3d91@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.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:D5473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D5473 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 16:20:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 16:20:55 -0000 Subject: [GHC] #15842: Exponentiation needs PrelRules In-Reply-To: <045.f0a505ab673e73f37cabafaa2874c4da@haskell.org> References: <045.f0a505ab673e73f37cabafaa2874c4da@haskell.org> Message-ID: <060.bc54f0b0a98e8e360f49dfb877a4ef76@haskell.org> #15842: Exponentiation needs PrelRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: 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 supersven): * owner: (none) => supersven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 16:39:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 16:39:11 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.9f6e545975f0e4865a496cc9c6645b83@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 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:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.10.1 => 8.8.1 Comment: This is in the 8.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 26 22:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Dec 2018 22:41:32 -0000 Subject: [GHC] #16097: Bad error message for a misaligned case block in a do-let expression Message-ID: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> #16097: Bad error message for a misaligned case block in a do-let expression -------------------------------------+------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs main = do code <- getCode let value = case code of 1 -> 2 3 -> 4 _ -> 5 print value }}} This is a parse error, as the indent of the case statements is under the indent introduced by let. However, the error message on 8.6 onwards is very misleading: {{{ /home/dkr/example/Bad.hs:2:8: error: Unexpected do block in function application: do code <- getCode let value = ... You could write it with parentheses Or perhaps you meant to enable BlockArguments? | 2 | main = do | ^^... }}} Compare this with 8.4, which is a bit less bad: {{{ /home/dkr/example/Bad.hs:5:6: error: parse error on input ‘1’ | 5 | 1 -> 2 | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 05:59:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 05:59:16 -0000 Subject: [GHC] #16097: Bad error message for a misaligned case block in a do-let expression In-Reply-To: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> References: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> Message-ID: <060.9bcdcdb9b13acb7a863847ae52b8d1bc@haskell.org> #16097: Bad error message for a misaligned case block in a do-let expression -------------------------------------+------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I suspect (but haven't verified) that this is caused by the block arguments patch: be84823b956f0aa09c58d94d1901f2dff13546b4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 06:16:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 06:16:33 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.22699d9eb6c7b9aa749d0949dbd41965@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: ​Phab:D4110, Phab:D4189 => ​Phab:D4110 Comment: This ticket is really confusing so I talked to Ben on this. Here's the current status: - #14346 is fixed but the `touch#` primop is essentially still broken. The suggestion of ticket:14346#comment:18 suggested implementing some hacks in simplifier to avoid removing unreachable continuation if the continuation calls `touch#`, but that's not implemented and as far as I can see there are no plans on implementing it (with no explicit reason to not to). Instead we want to use `with#` whenever possible. To fix the problem with #14346 we introduced some `NOINLINE`s to functions that use `touch#`, so simplifier now can't see that the `touch#` is unreacable and remove it. - This ticket has two ideas: 1. A new primop `with#`. This is being implemented in Phab:D4110. 2. A more efficient implementation plan for primops that take continuations. This is being implemented in Phab:D4647, although it seems to be dormant now (last update from the author is in Jun). To keep things more manageble (and avoid the communication problems we had with e.g. #15696) let's track the progress for (2) in another ticket and only worry about (1) here. If we really want (2) before (1) then we can consider the ticket for (1) as a blocker, and move on to this ticket after (2). (I'm removing Phab:D4189 from the diffs list) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 06:44:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 06:44:36 -0000 Subject: [GHC] #16098: More efficient implementation plan for primops with continuation arguments Message-ID: <043.9b6fc76ba3b47c46a0f7088887e493fe@haskell.org> #16098: More efficient implementation plan for primops with continuation arguments -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Original idea from #14375: in some of the primops that take continuation arguments we currently have to allocate the continuations but sometimes we immediately enter one of these continuations. One example is {{{ maskAsyncExceptions# :: (State# RealWorld -> (# State# RealWorld, a #)) -> (State# RealWorld -> (# State# RealWorld, a #)) }}} which is implemented as {{{ stg_maskAsyncExceptionszh /* explicit stack */ { /* Args: R1 :: IO a */ STK_CHK_P_LL (WDS(1)/* worst case */, stg_maskAsyncExceptionszh, R1); if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_BLOCKEX) == 0) { /* avoid growing the stack unnecessarily */ if (Sp(0) == stg_maskAsyncExceptionszh_ret_info) { Sp_adj(1); } else { Sp_adj(-1); Sp(0) = stg_unmaskAsyncExceptionszh_ret_info; } } else { if ((TO_W_(StgTSO_flags(CurrentTSO)) & TSO_INTERRUPTIBLE) == 0) { Sp_adj(-1); Sp(0) = stg_maskUninterruptiblezh_ret_info; } } StgTSO_flags(CurrentTSO) = %lobits32( TO_W_(StgTSO_flags(CurrentTSO)) | TSO_BLOCKEX | TSO_INTERRUPTIBLE); TICK_UNKNOWN_CALL(); TICK_SLOW_CALL_fast_v(); jump stg_ap_v_fast [R1]; } }}} Here we want to have better compilation for `maskAsyncExceptions# c` where we don't allocate for `c`. There are some ideas in ticket:14375#comment:1, but the idea was later superseded by ticket:14375#comment:7, which suggests - Making continuation arguments explicit in STG so that an `maskAsyncExceptions#` would now look like this in STG: `maskAsyncExceptions# (\s. e)`. - Then in the code gen generating stack frame push (plus `StgTSO` updates) and then emitting code for `e` directly. (I don't understand if `bind s:=s2` part in the comment is necessary?) Some primops take more than one callback, e.g. {{{ catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -> State# RealWorld -> (# State# RealWorld, a #) }}} Which is implemented as {{{ stg_catchzh ( P_ io, /* :: IO a */ P_ handler /* :: Exception -> IO a */ ) { W_ exceptions_blocked; STK_CHK_GEN(); exceptions_blocked = TO_W_(StgTSO_flags(CurrentTSO)) & (TSO_BLOCKEX | TSO_INTERRUPTIBLE); TICK_CATCHF_PUSHED(); /* Apply R1 to the realworld token */ TICK_UNKNOWN_CALL(); TICK_SLOW_CALL_fast_v(); jump stg_ap_v_fast (CATCH_FRAME_FIELDS(,,stg_catch_frame_info, CCCS, 0, exceptions_blocked, handler)) (io); } }}} For this example ticket:14375#comment:7 suggest using join points for the `handler` argument (and using the non-allocating callback scheme for the `io` argument), but I suggest we focus on more efficient implementation of callbacks that are immediately entered, and worry about the join point stuff in another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 06:45:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 06:45:09 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.8dbc954c683c2965117b479e20712cd6@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346, #16098 | Differential Rev(s): ​Phab:D4110 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #14346 => #14346, #16098 Comment: I filed #16098 for (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 07:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 07:39:27 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.076550c191c14b287b66c5b9ecacc6f6@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346, #16098 | Differential Rev(s): ​Phab:D4110 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I just saw the [https://phabricator.haskell.org/D4110#148654 last comment] in Phab:D4110 which implements the new `with#` primop without (2). Do we want to focus on #16098 first? Pinging simonpj, simonmar, bgamari. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 08:29:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 08:29:05 -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.6b9876c555707788b96f4dc971757fe5@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) 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: #16096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: rwbarton => (none) * related: => #16096 Comment: My fix for #16096 (Phab:D5473) which treats `x = y` as `let x = y` fixes this: {{{ ~ $ ghc-stage2 --interactive -Wall GHCi, version 8.7.20181226: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> x = 1 λ:2> x = 1 :2:1: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding defined at :1:1 λ:3> let x = 1 :3:5: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding defined at :2:1 λ:4> x <- return () :4:1: warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding defined at :3:5 }}} If we merge it we should add a test and close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 08:31:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 08:31:43 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.4bd501506c632522d79a5a89958a2f3a@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11606 | Differential Rev(s): Phab:D5473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #11606 Comment: Confirmed that Phab:5473 fixes #11606 as well. I suspect we can also remove the hack for #12091 because with this we treat `x = y` as `let x = y`, which doesn't have the problem mentioned in #12091, but I haven't verified this yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 09:31:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 09:31:57 -0000 Subject: [GHC] #16096: let x = ... and x = ... are not the same in GHCi In-Reply-To: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> References: <043.20233fac0da203df8f1330a78fdf8b83@haskell.org> Message-ID: <058.ff7c0e0a4cdeadbf4026590c3e59074b@haskell.org> #16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11606 | Differential Rev(s): Phab:D5473 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Actually Phab:D5473 even fixes #16089, but in an unexpected way. I'll update #16089. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 09:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 09:39:27 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.ffcb2cc934cbf918365f7deefdb0959b@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #16096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): My fix for #16096 (Phab:D5473) fixes the original reproducer: {{{ ~ $ ghc-stage2 --interactive GHCi, version 8.7.20181227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> x = [True, False] λ:2> :sprint x x = [True,False] λ:3> :print x x = [True,False] }}} Here's a slightly more complex example: {{{ ~ $ ghc-stage2 --interactive GHCi, version 8.7.20181227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> x = [ 1.. ] :: [Integer] λ:2> :sprint x x = _ λ:3> x `seq` () () λ:4> :sprint x x = 1 : _ }}} However if I omit the type annotation in the first line it doesn't work as expected: {{{ ~ $ ghc-stage2 --interactive GHCi, version 8.7.20181227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> x = [ 1.. ] λ:2> x `seq` () () λ:3> :sprint x x = _ }}} I'd expect to see the same output `x = 1 : _` here. We should use this one as the reproducer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 10:39:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 10:39:21 -0000 Subject: [GHC] #16079: runTestTT from ghci caused a panic. In-Reply-To: <053.5b1aa7be67942a6a4b55cc830af13cd6@haskell.org> References: <053.5b1aa7be67942a6a4b55cc830af13cd6@haskell.org> Message-ID: <068.a156e7b044a4c366120c57d18352550b@haskell.org> #16079: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: emacstheviking | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #16080 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate * related: => #16080 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 11:11:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 11:11:41 -0000 Subject: [GHC] #16034: Quadratic GC slowdown using RTS debug In-Reply-To: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> References: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> Message-ID: <059.abfed60a648602ce6c9ad8ea3415e9e7@haskell.org> #16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 osa1): I don't think this is a bug. As you already found out we do `countBlock()` a lot in debug runtime for sanity checking (`perf` shows that your example spends 72% of the time in `countBlocks()`), which traverses linked lists of blocks. This takes more time as residency increases. Out of curiosity, why do you want debug runtime to be faster? Debug runtime is supposed to make debugging easier, and for that we do lots of sanity checking. It'd be strange to optimise debug runtime for runtime performance instead of ease of debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 11:15:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 11:15:00 -0000 Subject: [GHC] #16012: set/getAllocationCounter is broken in GHCi In-Reply-To: <047.47e6ba0d4a10a32bc08881d654fc48c5@haskell.org> References: <047.47e6ba0d4a10a32bc08881d654fc48c5@haskell.org> Message-ID: <062.7dab7fe40ff23ee241679915e2922467@haskell.org> #16012: set/getAllocationCounter is broken in GHCi -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.7 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 11:19:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 11:19:41 -0000 Subject: [GHC] #15939: StgLint fails because Stg bindings are not dependency-ordered In-Reply-To: <043.2c303ed169474c399bb1733aa9ca13da@haskell.org> References: <043.2c303ed169474c399bb1733aa9ca13da@haskell.org> Message-ID: <058.2ddba6b76cd955a4bec9bb11e44e33a5@haskell.org> #15939: StgLint fails because Stg bindings are not dependency-ordered -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: 04caa935ac22bd2bd1a254f26df9dca4ee6abdd1 implemented (1) and StgLint is now enabled by default in the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 11:26:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 11:26:53 -0000 Subject: [GHC] #15921: Data.List.maximumBy uses counter-intuitive ordering In-Reply-To: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> References: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> Message-ID: <058.9411c8c3112fa6599c364237f37b43b2@haskell.org> #15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This should be discussed at libraries at haskell.org first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 12:46:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 12:46:39 -0000 Subject: [GHC] #16097: Bad error message for a misaligned case block in a do-let expression In-Reply-To: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> References: <045.376b00785ddd8d1da74970b5d48a8f5d@haskell.org> Message-ID: <060.11d57524b9fcc165319e9d873d74d118@haskell.org> #16097: Bad error message for a misaligned case block in a do-let expression -------------------------------------+------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:1 osa1]: > I suspect (but haven't verified) that this is caused by the block arguments patch: be84823b956f0aa09c58d94d1901f2dff13546b4 Well, confusion is the price you have to pay when you try to give more or less every sequence of characters a meaning... Introducing tons of conflicts into the parser should have been a clear warning sign that BlockArguments and quite a few of the recent "improvements" to the syntax are a bad idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 13:13:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 13:13:46 -0000 Subject: [GHC] #15911: internal error: evacuate(static): strange closure type -127533247 In-Reply-To: <047.7efb34f89faa44ffb4bc7ba48c4f60d0@haskell.org> References: <047.7efb34f89faa44ffb4bc7ba48c4f60d0@haskell.org> Message-ID: <062.c410ca224e1c43c3c576cdea0dabed83@haskell.org> #15911: internal error: evacuate(static): strange closure type -127533247 -------------------------------------+------------------------------------- Reporter: bfraikin | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 13:42:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 13:42:19 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.92a1a152f2528f2db1e95c960189b50c@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #16096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): No, the current behavior is fine when there's no type signature. GHCi turns off the monomorphism restriction by default, so `x :: Num a => [a]`. It's a function, not an updateable thunk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 13:48:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 13:48:03 -0000 Subject: [GHC] #16089: seq is not cooperating with :sprint in GHCi as expected In-Reply-To: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> References: <045.e9abc5cfe7030883678e7ab06d500876@haskell.org> Message-ID: <060.46069834d3cb43ef2bea17a9b3b923e3@haskell.org> #16089: seq is not cooperating with :sprint in GHCi as expected -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: seq sprint | strictness Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7253, #16096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Ah, that makes sense. Indeed I can see that my last example works if I do `:set -XMonomorphismRestriction`, so perhaps Phab:D5473 closes this ticket too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 15:30:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 15:30:48 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.964b67c872972b8f355e2fe0bb1ce777@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.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 bgamari): `ghcilink005` is also affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 16:34:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 16:34:07 -0000 Subject: [GHC] #15921: Data.List.maximumBy uses counter-intuitive ordering In-Reply-To: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> References: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> Message-ID: <058.9dafae9f42d90c725d9f8b5827e00cf4@haskell.org> #15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Documentation already says "the (comparison) function is assumed to define a total ordering". The function `comparing snd` does not. It defines a relation that is total, transitive, reflexive, but not antisymmetric. Then all bets are off, at least officially. There are local `minBy/maxBy` functions in the implementation {{{ min' x y = case cmp x y of GT -> y _ -> x max' x y = case cmp x y of GT -> x _ -> y }}} that treat the `EQ` case differently. That does not feel consistent with the "laws for `Ord` that are expected to hold" (where `EQ` would always select the first argument) {{{ max x y == if x >= y then x else y = True min x y == if x <= y then x else y = True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 16:58:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 16:58:24 -0000 Subject: [GHC] #16046: -fno-stack-protector still necessary? In-Reply-To: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> References: <046.e78ea70adece6475c48a19504bb9ec99@haskell.org> Message-ID: <061.ac09f05d92b61c6da3c2058dc226b35e@haskell.org> #16046: -fno-stack-protector still necessary? -------------------------------------+------------------------------------- Reporter: clumens | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.4.3 (make) | 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:D5465 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"29ecb52033b951e09b6141aeb92460db2f4c3183/ghc" 29ecb520/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29ecb52033b951e09b6141aeb92460db2f4c3183" aclocal.m4: drop obsolete -fno-stack-protector Summary: Initially -fno-stack-protector was added for openbsd specifically for ghc-6.5: changeset:f638fdfe1d9de1307355c8074fbff9c28342c0ef (2006) and later it was extended to cover osx: changeset:c2cd83e7d85c11e6a33e1cde263eb2312566d535 (2009) None of the reports hint at exact breakage. I guess both happened in -fvia-C mode where GHC's Evil Mangler had a chance to mangle stack canaries generated by fstack-protector. ghc has no evil mangler anymore and the change is not needed at least for C codegen. validated the patch on OpenBSD-6.4. No new failures compared to clean master branch. Signed-off-by: Sergei Trofimovich Test Plan: validated on OpenBSD Reviewers: bgamari Subscribers: rwbarton, erikd, carter GHC Trac Issues: #16046 Differential Revision: https://phabricator.haskell.org/D5465 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 17:36:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 17:36:24 -0000 Subject: [GHC] #16099: expose st_blksize field from fstat syscall Message-ID: <046.ba8909ded536fab7b2461cbbfac0f384@haskell.org> #16099: expose st_blksize field from fstat syscall ----------------------------------------+--------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: libraries/unix | Version: 8.6.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The libc manual talks about buffer sizes. https://www.gnu.org/software/libc/manual/html_node/Controlling- Buffering.html They advise: Actually, you can get an even better value to use for the buffer size by means of the fstat system call: it is found in the st_blksize field of the file attributes. See Attribute Meanings. It's just that the st_blksize field it stepped over in the haskell definition of it: https://github.com/haskell/unix/blob/8d188ed8067af17dfcc2cd6cbbfda7294ba17e17/System/Posix/Files/Common.hsc#L280-L283 Which goes directly from filesize to accesstime See also https://linux.die.net/man/2/fstat Would be nice to expose the additional fields as well -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 18:45:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 18:45:41 -0000 Subject: [GHC] #16091: arith011 broken with integer-simple In-Reply-To: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> References: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> Message-ID: <061.32aa32fba0af3e10f984eeaaaf5d9fea@haskell.org> #16091: arith011 broken with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/36 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/36 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 19:49:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 19:49:22 -0000 Subject: [GHC] #15921: Data.List.maximumBy uses counter-intuitive ordering In-Reply-To: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> References: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> Message-ID: <058.01ddc53af0e1a8f882f1bf1ec8f54c3b@haskell.org> #15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by qqwy): > There are local minBy/maxBy functions in the implementation that treat the EQ case differently. That does not feel consistent with the "laws for Ord that are expected to hold" (where EQ would always select the first argument) This is what the problem distills do, and what I feel should be changed (instead making the implementations of the `min'` and `max'` local to `minBy/maxBy` align with the behaviour of the public `min` and `max`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 27 23:08:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Dec 2018 23:08:16 -0000 Subject: [GHC] #16100: T11627a fails sometimes on CI Message-ID: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> #16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See this build - https://gitlab.haskell.org/mpickering/ghc/-/jobs/6459 Causes this panic {{{ 81384 cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hd -RTS +RTS -i0 -RTS 81385 Wrong exit code for T11627a(prof_hc_hb)(expected 0 , actual 134 ) 81386 Stdout ( T11627a ): 81387 456574 81388 Stderr ( T11627a ): 81389 T11627a: internal error: LDV_recordDead: Failed to find counter for closure 0x42000bf558 81390 (GHC version 8.7.20181227 for x86_64_unknown_linux) 81391 Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 00:43:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 00:43:31 -0000 Subject: [GHC] #15613: GHCi command, tracing steps of instance resolution for Constraint or expression In-Reply-To: <051.315b513efc5cd955ece666611620c1e9@haskell.org> References: <051.315b513efc5cd955ece666611620c1e9@haskell.org> Message-ID: <066.3dfba33134b51217f95a2697444ce9ba@haskell.org> #15613: GHCi command, tracing steps of instance resolution for Constraint or expression -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15610 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Another GHCi command (#15610), `:elab ` traces instance > resolution for ``. This is already something people do by > hand (ticket:10318#comment:6) and would be a great tool for explorers of > Haskell > > {{{ > >> :elab Monoid (a -> b -> ([c], Sum Int)) > Monoid (a -> b -> ([c], Sum Int)) > ==> Monoid (b -> ([c], Sum Int)) > ==> Monoid ([c], Sum Int) > ==> Monoid [c] > ==> Monoid (Sum Int) > ==> Num Int > }}} > > If resolving the type class fails, it can pinpoint what caused it to fail > > {{{ > >> data A > >> :elab Show (A, Int -> Int) > Show (A, Int -> Int) > <~bRZsz NO instance~> > > ==> Show A > > ==> Show (Int -> Int) > > }}} > > A verbose version can explain each step > > {{{ > >> :elab +v Monoid (a -> b -> ([c], Sum Int) > Monoid (a -> b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) > (‘GHC.Base’) > ==> Monoid (b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) > (‘GHC.Base’) > ==> Monoid ([c], Sum Int) -- Monoid b => Monoid (a -> b) > (‘GHC.Base’) > ==> Monoid [c] -- Monoid [a] > (‘GHC.Base’) > ==> Monoid (Sum Int) -- Num a => Monoid (Sum a) > (‘Data.Monoid’) > ==> Num Int -- Num Int > (‘GHC.Num’) > }}} > > {{{ > >> :elab +v Num (Int, Float, Rational) > Num (Int, Float, Rational) -- (Num a, Num b, Num c) => Num (a, b, c) > (‘Data.NumInstances.Tuple’) > ==> Num Int -- Num Int > (‘GHC.Num’) > ==> Num Float -- Num Float > (‘GHC.Float’) > ==> Num Rational -- type Rational = Ratio Integer > (‘GHC.Real’) > = Num (Ration Integer) -- Integral a => Num (Ratio a) > (‘GHC.Real’) > ==> Integral Integer -- Integral Integer > (‘GHC.Real’) > }}} > > ---- > > Not the same idea but similar. Listing instance resolution that takes > place in an expression > > {{{ > >> :elab (+) @Int > from: (+) @Int > Num Int > }}} > {{{ > >> :elab2 comparing (length @[]) <> compare > from: length @[] > Foldable [] > > from: comparing (length @[]) > Ord Int > > from: comparing (length @[]) <> compare > Monoid ([a] -> [a] -> Ordering) > ==> Monoid ([a] -> Ordering) > ==> Monoid Ordering > }}} > {{{ > >> :elab2 ask 'a' > from: ask 'a' > MonadReader Char ((->) m) > ==> MonadReader Char ((->) Char) > }}} > > not sure about that last one, or how to visualize them but I think it > gives the right idea. New description: Another GHCi command (#15610), `:elab ` traces instance resolution for ``. This is already something people do by hand (ticket:10318#comment:6) and would be a great tool for explorers of Haskell {{{ >> :elab Monoid (a -> b -> ([c], Sum Int)) Monoid (a -> b -> ([c], Sum Int)) ==> Monoid (b -> ([c], Sum Int)) ==> Monoid ([c], Sum Int) ==> Monoid [c] ==> Monoid (Sum Int) ==> Num Int }}} If resolving the type class fails, it can pinpoint what caused it to fail {{{ >> data A >> :elab Show (A, Int -> Int) Show (A, Int -> Int) <~bRZsz NO instance~> ==> Show A ==> Show (Int -> Int) }}} A verbose version can explain each step {{{ >> :elab +v Monoid (a -> b -> ([c], Sum Int) Monoid (a -> b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid (b -> ([c], Sum Int)) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid ([c], Sum Int) -- Monoid b => Monoid (a -> b) (‘GHC.Base’) ==> Monoid [c] -- Monoid [a] (‘GHC.Base’) ==> Monoid (Sum Int) -- Num a => Monoid (Sum a) (‘Data.Monoid’) ==> Num Int -- Num Int (‘GHC.Num’) }}} {{{ >> :elab +v Num (Int, Float, Rational) Num (Int, Float, Rational) -- (Num a, Num b, Num c) => Num (a, b, c) (‘Data.NumInstances.Tuple’) ==> Num Int -- Num Int (‘GHC.Num’) ==> Num Float -- Num Float (‘GHC.Float’) ==> Num Rational -- type Rational = Ratio Integer (‘GHC.Real’) = Num (Ration Integer) -- Integral a => Num (Ratio a) (‘GHC.Real’) ==> Integral Integer -- Integral Integer (‘GHC.Real’) }}} ---- Not the same idea but similar. Listing instance resolution that takes place in an expression {{{ >> :elab (+) @Int from: (+) @Int Num Int }}} {{{ >> :elab2 comparing (length @[]) <> compare from: length @[] Foldable [] from: comparing (length @[]) Ord Int from: comparing (length @[]) <> compare Monoid ([a] -> [a] -> Ordering) ==> Monoid ([a] -> Ordering) ==> Monoid Ordering }}} {{{ >> :elab2 ask 'a' from: ask 'a' MonadReader Char ((->) m) ==> MonadReader Char ((->) Char) }}} not sure about that last one, or how to visualize them but I think it gives the right idea. Make sure to test it on https://jpaykin.github.io/papers/paykin_dissertation_2018.pdf {{{#!hs lam :: (HasLolli exp, KnownNat n, Div_ (Remove n ctx') (Remove n ctx') ~ '[], Fresh (Remove n ctx') ~ n, MergeF (Remove n ctx') '[] ~ Remove n ctx', MergeF ctx' '[] ~ ctx', Lookup ctx' n ~ 'Just a, AddF n a (Remove n ctx') ~ ctx', Div_ ctx' ctx' ~ '[]) => (Var exp n a -> exp ctx' b) -> exp (Remove n ctx') (a -· b) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 01:31:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 01:31:47 -0000 Subject: [GHC] #16101: Write a nix expression to enter a shell with specified build artifact Message-ID: <049.4fe1634b22bf6d60c068c0561bb19b09@haskell.org> #16101: Write a nix expression to enter a shell with specified build artifact -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It should be quite straightforward to write a nix expression which is parameterised by a CI job which downloads the artifact and enters into a nix shell which provisions that version of GHC. To be precise, consider the recent job: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427. It built these artifacts: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427/artifacts/browse We should download the bindist and patch it suitably so it works like a normal GHC release. Some inspiration can probably be drawn from the scripts that Ben wrote for the head.hackage repo: https://github.com/hvr/head.hackage/blob/master/default.nix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 03:44:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 03:44:27 -0000 Subject: [GHC] #16091: arith011 broken with integer-simple In-Reply-To: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> References: <046.4a450f488ea1f89cd63bc51bb569eaec@haskell.org> Message-ID: <061.9e0f9fc84792f39afbbcad07e9ec4c75@haskell.org> #16091: arith011 broken with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/36 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bbea972149882b4f5f6b0a1691488a519ba6aaf9/ghc" bbea9721/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbea972149882b4f5f6b0a1691488a519ba6aaf9" Division fails fast for `divMod` \w integer-simple We want to match the behaviour of `Integer` as well as `Integer`/`Natural` from `integer-gmp`, namely to have divMod x 0 = _|_ not divMod x 0 = (_|_, _|_) See #16091 for an example of where this matters. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 05:36:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 05:36:02 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.94b68526559492aaa68689f9a2869634@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: patch Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15219 | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: osa1 => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 05:39:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 05:39:15 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.10fb337db061d22cf348433f38226263@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: ⊥ Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.8.1 => ⊥ Comment: Unfortunately we won't be able to get back to this for 8.8.1, and I don't know if this is doable in its current form so I'm removing the milestone. We should focus on finding a smaller reproducer as the current reproducer is taking forever to build and have dozens (if not hundreds) of dependencies (although the change we need to do is not in a dependency, it may still related with code generated for dependencies. In any case less dependencies is always better when debugging). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 05:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 05:39:26 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.610451420d16d8714ea51a6a1139c73c@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: ⊥ Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: osa1 => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 05:59:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 05:59:33 -0000 Subject: [GHC] #8316: GHCi debugger panics when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.4882b8e7aefd46ba98de6868c30c8353@haskell.org> #8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: GHCi | Version: 7.6.3 Resolution: | Keywords: debugger, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4535, Wiki Page: | Phab:D5179 -------------------------------------+------------------------------------- Changes (by osa1): * keywords: debugger => debugger, newcomer * priority: high => normal * milestone: 8.8.1 => ⊥ Comment: The panic has been fixed, rest of comment:19 still need to be implemented, but they're not as urgent. Removing the milestone and marking the ticket as 'newcomer'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:03:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:03:02 -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.822efbe6c67c0143f55c5f6ca528b0a9@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.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): Phab:D3758, Wiki Page: | Phab:D5059 -------------------------------------+------------------------------------- Comment (by osa1): What needs to be done here? An updated summary would be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:18:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:18:54 -0000 Subject: [GHC] Batch modify: #14123, #14251, #14873, #14899, #15519, #15768, ... In-Reply-To: <182.57edb30a71a05e1b65de42a13ee89c6e@haskell.org> References: <182.57edb30a71a05e1b65de42a13ee89c6e@haskell.org> Message-ID: <197.486d11b7c62716edf08f2beeb39793bf@haskell.org> Batch modification to #14123, #14251, #14873, #14899, #15519, #15768, #4012, #7411, #8228, #9370, #10946, #12178, #13233, #13426, #13576, #13624, #13763, #14013, #14226, #14270, #14980, #15267, #15418, #15455, #15488 by osa1: milestone to 8.10.1 Comment: Bumping milestones of some high and highest priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:32:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:32:38 -0000 Subject: [GHC] Batch modify: #16087, #16059, #16049, #16039, #16009, #15979, ... In-Reply-To: <294.6074c898fdb9442d731ce22dab684225@haskell.org> References: <294.6074c898fdb9442d731ce22dab684225@haskell.org> Message-ID: <309.476c053f01d58835ab22eb69f9083024@haskell.org> Batch modification to #16087, #16059, #16049, #16039, #16009, #15979, #15969, #15908, #15899, #15890, #15842, #15831, #15821, #15819, #15774, #15753, #15731, #15719, #15717, #15690, #15681, #15678, #15677, #15662, #15654, #15653, #15652, #15651, #15644, #15642, #15621, #15596, #15560, #15549, #15536, #15534, #15510, #15483, #15477, #15474, #15471, #15470, #15468 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:33:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:33:28 -0000 Subject: [GHC] Batch modify: #15465, #15464, #15462, #15461, #15459, #15454, ... In-Reply-To: <294.c8c1fe34e858e17a31852f038b0ab1d4@haskell.org> References: <294.c8c1fe34e858e17a31852f038b0ab1d4@haskell.org> Message-ID: <309.f6162460bb542b7d920fc70b7d26e6dc@haskell.org> Batch modification to #15465, #15464, #15462, #15461, #15459, #15454, #15452, #15449, #15448, #15437, #15435, #15434, #15433, #15429, #15427, #15425, #15424, #15420, #15416, #15414, #15411, #15409, #15403, #15402, #15395, #15394, #15392, #15391, #15389, #15388, #15384, #15382, #15381, #15378, #15377, #15376, #15375, #15364, #15362, #15358, #15356, #15354, #15345 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:34:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:34:16 -0000 Subject: [GHC] Batch modify: #15344, #15340, #15338, #15337, #15336, #15328, ... In-Reply-To: <252.2b7b60596d1696468456f5dae345489e@haskell.org> References: <252.2b7b60596d1696468456f5dae345489e@haskell.org> Message-ID: <267.f21faf59fefae3df10d0cd4cb734096d@haskell.org> Batch modification to #15344, #15340, #15338, #15337, #15336, #15328, #15327, #15326, #15322, #15320, #15313, #15312, #15309, #15298, #15297, #15295, #15291, #15288, #15283, #15277, #15272, #15270, #15258, #15257, #15253, #15252, #15251, #15250, #15249, #15248, #15247, #15241, #15227, #15220, #15219, #15211 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:35:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:35:57 -0000 Subject: [GHC] Batch modify: #11295, #11261, #11243, #11222, #11204, #11197, ... In-Reply-To: <245.b39b2324e0b53a8fd2cceb327b250cd5@haskell.org> References: <245.b39b2324e0b53a8fd2cceb327b250cd5@haskell.org> Message-ID: <260.b32af00098a17d68f955b72ba900b898@haskell.org> Batch modification to #11295, #11261, #11243, #11222, #11204, #11197, #11149, #11092, #10972, #10962, #10892, #10878, #10853, #10789, #10770, #10599, #10542, #10445, #10431, #10352, #10056, #9248, #9244, #9221, #8634, #7593, #7398, #7353, #6132, #6087, #5797, #5620, #4471, #2725, #2408, #2189, #806, #605 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:36:25 -0000 Subject: [GHC] Batch modify: #13981, #13944, #13906, #13905, #13904, #13898, ... In-Reply-To: <636.1baa558e8908e5972dca523d8dc6d3e9@haskell.org> References: <636.1baa558e8908e5972dca523d8dc6d3e9@haskell.org> Message-ID: <651.4b036ba93ee8d01d94eb486c9486afbf@haskell.org> Batch modification to #13981, #13944, #13906, #13905, #13904, #13898, #13753, #13724, #13723, #13717, #13693, #13692, #13686, #13647, #13629, #13564, #13554, #13515, #13513, #13511, #13507, #13465, #13448, #13423, #13408, #13406, #13390, #13363, #13360, #13357, #13346, #13331, #13309, #13280, #13243, #13226, #13225, #13189, #13176, #13154, #13153, #13152, #13104, #13093, #13092, #13091, #13090, #13080, #13078, #13072, #13069, #13065, #13003, #13002, #12949, #12941, #12940, #12937, #12934, #12932, #12926, #12913, #12891, #12875, #12808, #12798, #12774, #12765, #12665, #12652, #12636, #12619, #12599, #12581, #12482, #12428, #12389, #12388, #12193, #12090, #12021, #11958, #11955, #11953, #11836, #11749, #11686, #11634, #11594, #11587, #11526, #11503, #11457, #11409, #11394, #11384, #11369, #11359, #11323, #11307 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:36:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:36:59 -0000 Subject: [GHC] Batch modify: #15210, #15208, #15205, #15203, #15201, #15200, ... In-Reply-To: <336.97a1414db8609885c01d4cad39806742@haskell.org> References: <336.97a1414db8609885c01d4cad39806742@haskell.org> Message-ID: <351.b2624c536f52fde9e4ab79d53c8f5147@haskell.org> Batch modification to #15210, #15208, #15205, #15203, #15201, #15200, #15194, #15193, #15191, #15190, #15184, #15183, #15182, #15177, #15175, #15167, #15159, #15156, #15155, #15153, #15148, #15147, #15135, #15130, #15129, #15127, #15126, #15124, #15106, #15100, #15096, #15092, #15091, #15090, #15089, #15081, #15080, #15078, #15077, #15075, #15072, #15070, #15069, #15056, #15054, #15048, #15044, #15043, #15034, #15029 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:38:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:38:02 -0000 Subject: [GHC] Batch modify: #14530, #14512, #14509, #14502, #14469, #14412, ... In-Reply-To: <186.e84e536bdba67ca3a51d378ab315e6d3@haskell.org> References: <186.e84e536bdba67ca3a51d378ab315e6d3@haskell.org> Message-ID: <201.cffd8c41afde449ba254a90f5eab541f@haskell.org> Batch modification to #14530, #14512, #14509, #14502, #14469, #14412, #14405, #14401, #14400, #14337, #14331, #14319, #14283, #14261, #14252, #14242, #14214, #14165, #14164, #14155, #14111, #14040, #14030, #14023, #14003 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:38:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:38:23 -0000 Subject: [GHC] Batch modify: #15028, #15020, #15011, #15010, #14911, #14909, ... In-Reply-To: <108.b0fbda2c8c997c3a0ad00ec52bd46d36@haskell.org> References: <108.b0fbda2c8c997c3a0ad00ec52bd46d36@haskell.org> Message-ID: <123.7ab06af04750d2c9270cc3a7d7b88140@haskell.org> Batch modification to #15028, #15020, #15011, #15010, #14911, #14909, #14870, #14839, #14838, #14823, #14816, #14806 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:39:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:39:10 -0000 Subject: [GHC] Batch modify: #14765, #14729, #14727, #14684, #14673 In-Reply-To: <066.aa15d933a43bfe92ea69ed8b065fca25@haskell.org> References: <066.aa15d933a43bfe92ea69ed8b065fca25@haskell.org> Message-ID: <081.fc682cc933fcac7cee75780ff875fa2a@haskell.org> Batch modification to #14765, #14729, #14727, #14684, #14673 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:39:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:39:24 -0000 Subject: [GHC] Batch modify: #14765, #14729, #14727, #14684, #14673 In-Reply-To: <066.aa15d933a43bfe92ea69ed8b065fca25@haskell.org> References: <066.aa15d933a43bfe92ea69ed8b065fca25@haskell.org> Message-ID: <081.0a401971d0fc6092c420829af69e3c73@haskell.org> Batch modification to #14765, #14729, #14727, #14684, #14673 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:39:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:39:59 -0000 Subject: [GHC] Batch modify: #14617, #14610, #14604, #14602, #14579 In-Reply-To: <066.0976f7688105247c62035de026478c94@haskell.org> References: <066.0976f7688105247c62035de026478c94@haskell.org> Message-ID: <081.7e2686a95197147f68a4e6d7c3daab09@haskell.org> Batch modification to #14617, #14610, #14604, #14602, #14579 by osa1: milestone to 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:40:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:40:40 -0000 Subject: [GHC] #14670: -XRebindableSyntax needs return? In-Reply-To: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> References: <048.c96b42d6aefe76220126edbb094e21e4@haskell.org> Message-ID: <063.9e13fb6d892c057caf6216393fcd2b95@haskell.org> #14670: -XRebindableSyntax needs return? -------------------------------------+------------------------------------- Reporter: jackkelly | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | RebindableSyntax,ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rebindable/T14670 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.8.1 => 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 06:41:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 06:41:00 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.a901c37ca38a8d4ff0a596c7756af86c@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #849 #15124 | Differential Rev(s): Phab:D4316 #8326 | Phab:D4324 Phab:D4327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * milestone: 8.8.1 => 8.10.1 Comment: Bumping milestones of low-priority tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 08:04:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 08:04:53 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.9201291cc9de63a8acd0ded5f671ab69@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): As discussed on IRC, I encountered an issue where moving the code into `GHC.Real` doesn't help because Stage 1 is not using *that* `GHC.Real`, it's using the module from the GHC being used to compile the target GHC rather than the target GHC itself. So, what I'm going to do is spend a little bit of time to summarize my understanding of exactly what my attempt is currently and how to understand the code I've written so that we're all on the same page and others can help me more easily. Stay tuned :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 10:56:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 10:56:54 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.f319017eebeab3ed5c264320bb1c2a7e@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch Comment: Fix at https://gitlab.haskell.org/ghc/ghc/merge_requests/51 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 10:57:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 10:57:45 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.fbdeda1840f7f2a6156b1f4bbab99f73@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Here is the current summary of what I've been intending to do: Problem is excessive duration of typechecking large fractionals. Initial issue was renamer and desugarer were consructing the rational before typechecking. The plan that has been implemented is to adjust FractionalLit to store the significand and the exponent, as well as the FractionalExponentBase (because the fractional *may* be hex or dec) instead of just a rational, and to parse the source as an application of a new library functions `mkFractionalLit` and `mkTHFractionalLit`. In the process we also added a new core expression `mkRationalExpr` Template haskell still uses a rational to represent its fractional lits, so we have *two* constructors in the FractionalLit type: FL and THFL (one for regular literals and one for Template Haskell literals). We also had to adjust the lexer in the parser to deal with parsing the values into the new forms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 11:13:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 11:13:48 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.3c61ed9432c1d435d709b40512f9caa0@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): The current problems are: ##Problem 1## As we need to store an application of `mkRational` upon desugaring, we need to have it exist in some library. Unfortunately, for Stage 1 compilation, the library functions we have access to seem to be only those that exist in the *GHC that is compiling* rather than the *GHC that is being compiled*. This means the reference to `mkRationalName` that I've added to `PrelNames.hs` doesn't work, because we can't refer to any module that has the `mkRational` function in it; none exist. Of course, there is every chance we're not aware of a way to inject the bootstrapped code in — how does one refer to new library functions? Note: initially, and in the current fork as I've written it, I refer to it via `gHC_REAL` but that obviously doesn't work. ##Problem 2## Typechecking is still slow (less slow, granted, but only a little). I think this makes sense, as I haven't actually adjusted any typechecker code yet. I've been looking into `TcExpr.hs` which has the `tcExpr` function, but I need to figure through that code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 12:35:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 12:35:17 -0000 Subject: [GHC] #16034: Quadratic GC slowdown using RTS debug In-Reply-To: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> References: <044.0214cd9df23fe8a9202aa4dcb5c909e4@haskell.org> Message-ID: <059.8752be4b6d1f7d29be5246ad12f5b7ff@haskell.org> #16034: Quadratic GC slowdown using RTS debug -------------------------------------+------------------------------------- Reporter: remyo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 remyo): The original intent was not to explicitly use debugging runtime but ticky profiling (which implies debugging runtime). It is of course natural to expect some slowdown (2x, 3x, 10x or even more). But in the real world example I was testing, the program was still not finished after more than 10 hours, where the regular compiled binary finished in 4 minutes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 13:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 13:03:03 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.804a2e5757b39632015cdc9e8e979ae1@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ah, after reporting those problems, I thought to myself... "let's try re- running `./boot` and `./configure` after moving the definitions of `mkRational`, `mkRationalWithExponentBase`, `FractionalExponentBase` and `rationalFromFractionalLit` to `GHC.Real` again to see if it actually bootstraps the files like I thought it might, and it seems it did (I obviously still have a lot to learn ;-)). Still, got many other compiler errors, but it at least it seems to be doing the right thing. I'm still fairly unsure about how exactly I can extract all the pieces I need to to put these functions into `GHC.Real` (or somewhere available)... Here are the errors (which make sense): {{{ libraries/base/GHC/Real.hs:832:13: error: Not in scope: type constructor or class ‘Data’ | 832 | deriving (Data, Show) | ^^^^ libraries/base/GHC/Real.hs:841:30: error: Not in scope: type constructor or class ‘FractionalLit’ Perhaps you meant ‘Fractional’ (line 194) | 841 | rationalFromFractionalLit :: FractionalLit -> Rational | ^^^^^^^^^^^^^ libraries/base/GHC/Real.hs:842:28: error: Not in scope: data constructor ‘FL’ Perhaps you meant ‘F#’ (imported from GHC.Base) | 842 | rationalFromFractionalLit (FL _ _ i e expBase) = | ^^ libraries/base/GHC/Real.hs:844:28: error: Not in scope: data constructor ‘THFL’ | 844 | rationalFromFractionalLit (THFL _ _ r) = r | ^^^^ make[1]: *** [libraries/base/dist-install/build/GHC/Real.o] Error 1 make: *** [all] Error 2 }}} So, I'll keep pottering along and see if I can't make it compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 13:07:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 13:07:42 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.1e07e59e44d9ff5e227420c0d135a34c@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Comment (by LeanderK): just for motivation: I am still very much looking forward to this feature :) But I understand that there might be other priorities. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 13:13:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 13:13:59 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.37dc35a396a08ecade6ea5e4aa264b28@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Hm. Actually, not. Disregard the last update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 13:20:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 13:20:40 -0000 Subject: [GHC] #15921: Data.List.maximumBy uses counter-intuitive ordering In-Reply-To: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> References: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> Message-ID: <058.95d5482e5a57ea6ddca52a22c2fe0239@haskell.org> #15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Replying to [comment:3 osa1]: > This should be discussed at libraries at haskell.org first. I just posted https://mail.haskell.org/pipermail/libraries/2018-December/029299.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 14:00:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 14:00:40 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.869e8c2775a45eaf05a71f9bc15b397f@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This feature is nearly complete, but it has to wait for 8.10 since the 8.8 branch has already been cut. At this point, I'm just fixing little problems and documenting the implementation better. I'm looking forward to having this as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 15:27:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 15:27:44 -0000 Subject: [GHC] #16098: More efficient implementation plan for primops with continuation arguments In-Reply-To: <043.9b6fc76ba3b47c46a0f7088887e493fe@haskell.org> References: <043.9b6fc76ba3b47c46a0f7088887e493fe@haskell.org> Message-ID: <058.b1b8a96c80209f6deae07cd44831b92f@haskell.org> #16098: More efficient implementation plan for primops with continuation arguments -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14375 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 15:35:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 15:35:56 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.60e853680061f872ea03fe1e45a260df@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 15:42:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 15:42:44 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.1554ea4a71d2e4143a8709ce5e64ba1b@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: ⊥ Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 16:44:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 16:44:55 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the forked process Message-ID: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> #16102: forkProcess causes weird GC summary in the forked process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 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: -------------------------------------+------------------------------------- The existing test `forkprocess01` actually exhibits this behavior, but we just don't have the necessary assertions in place to catch it. One of the assertions I added in https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. Here's the output with GHC 8.4: {{{ $ ghc forkprocess01.hs -debug -rtsopts [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) Linking forkprocess01 ... $ ./forkprocess01 +RTS -s 44,144 bytes allocated in the heap 4,824 bytes copied during GC 37,696 bytes maximum residency (1 sample(s)) 19,648 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s 0.0006s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( 0.001s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.000s ( 0.002s elapsed) %GC time 61200000.0% (32.3% elapsed) Alloc rate 0 bytes per MUT second Productivity -100999900.0% of total user, 47.2% of total elapsed Just (Exited (ExitFailure 72)) 54,160 bytes allocated in the heap 3,480 bytes copied during GC 44,576 bytes maximum residency (1 sample(s)) 25,056 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s 0.0005s INIT time 0.000s ( 0.000s elapsed) MUT time 0.001s ( 0.003s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.002s ( 0.004s elapsed) %GC time 32.0% (14.5% elapsed) Alloc rate 87,073,954 bytes per MUT second Productivity 43.3% of total user, 74.6% of total elapsed }}} Notice the `-100999900.0%` productivity in the first summary, which is printed by the child process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 16:48:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 16:48:56 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process (was: forkProcess causes weird GC summary in the forked process) In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.2031f2fa7707278e287870025b1a0b55@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 16:56:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 16:56:11 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.b7b62f95c39f5ee18f91d56d106b4655@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > The existing test `forkprocess01` actually exhibits this behavior, but we > just don't have the necessary assertions in place to catch it. One of the > assertions I added in > https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. > > Here's the output with GHC 8.4: > > {{{ > $ ghc forkprocess01.hs -debug -rtsopts > [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) > Linking forkprocess01 ... > > $ ./forkprocess01 +RTS -s > 44,144 bytes allocated in the heap > 4,824 bytes copied during GC > 37,696 bytes maximum residency (1 sample(s)) > 19,648 bytes maximum slop > 2 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s > 0.0000s > Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s > 0.0006s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.000s ( 0.001s elapsed) > GC time 0.001s ( 0.001s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 0.000s ( 0.002s elapsed) > > %GC time 61200000.0% (32.3% elapsed) > > Alloc rate 0 bytes per MUT second > > Productivity -100999900.0% of total user, 47.2% of total elapsed > > Just (Exited (ExitFailure 72)) > 54,160 bytes allocated in the heap > 3,480 bytes copied during GC > 44,576 bytes maximum residency (1 sample(s)) > 25,056 bytes maximum slop > 2 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s > 0.0000s > Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s > 0.0005s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.001s ( 0.003s elapsed) > GC time 0.001s ( 0.001s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 0.002s ( 0.004s elapsed) > > %GC time 32.0% (14.5% elapsed) > > Alloc rate 87,073,954 bytes per MUT second > > Productivity 43.3% of total user, 74.6% of total elapsed > }}} > > Notice the `-100999900.0%` productivity in the first summary, which is > printed by the child process. New description: The existing test `forkprocess01` actually exhibits this behavior, but we just don't have the necessary assertions in place to catch it. One of the assertions I added in https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. Here's the output with GHC 8.4: {{{ $ ghc forkprocess01.hs -debug -rtsopts [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) Linking forkprocess01 ... $ ./forkprocess01 +RTS -s 44,144 bytes allocated in the heap 4,824 bytes copied during GC 37,696 bytes maximum residency (1 sample(s)) 19,648 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s 0.0006s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( 0.001s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.000s ( 0.002s elapsed) %GC time 61200000.0% (32.3% elapsed) Alloc rate 0 bytes per MUT second Productivity -100999900.0% of total user, 47.2% of total elapsed Just (Exited (ExitFailure 72)) 54,160 bytes allocated in the heap 3,480 bytes copied during GC 44,576 bytes maximum residency (1 sample(s)) 25,056 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s 0.0005s INIT time 0.000s ( 0.000s elapsed) MUT time 0.001s ( 0.003s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.002s ( 0.004s elapsed) %GC time 32.0% (14.5% elapsed) Alloc rate 87,073,954 bytes per MUT second Productivity 43.3% of total user, 74.6% of total elapsed }}} Notice the `-100999900.0%` productivity in the first summary, which is printed by the child process. Can also reproduce with 8.6. Note that you sometimes need to run this a few times to reproduce. Every once in a while I get normal results (where productivity is not negative). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 16:56:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 16:56:29 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.ee658abd474c2db4830596c2732d72e6@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > The existing test `forkprocess01` actually exhibits this behavior, but we > just don't have the necessary assertions in place to catch it. One of the > assertions I added in > https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. > > Here's the output with GHC 8.4: > > {{{ > $ ghc forkprocess01.hs -debug -rtsopts > [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) > Linking forkprocess01 ... > > $ ./forkprocess01 +RTS -s > 44,144 bytes allocated in the heap > 4,824 bytes copied during GC > 37,696 bytes maximum residency (1 sample(s)) > 19,648 bytes maximum slop > 2 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s > 0.0000s > Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s > 0.0006s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.000s ( 0.001s elapsed) > GC time 0.001s ( 0.001s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 0.000s ( 0.002s elapsed) > > %GC time 61200000.0% (32.3% elapsed) > > Alloc rate 0 bytes per MUT second > > Productivity -100999900.0% of total user, 47.2% of total elapsed > > Just (Exited (ExitFailure 72)) > 54,160 bytes allocated in the heap > 3,480 bytes copied during GC > 44,576 bytes maximum residency (1 sample(s)) > 25,056 bytes maximum slop > 2 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s > 0.0000s > Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s > 0.0005s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.001s ( 0.003s elapsed) > GC time 0.001s ( 0.001s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 0.002s ( 0.004s elapsed) > > %GC time 32.0% (14.5% elapsed) > > Alloc rate 87,073,954 bytes per MUT second > > Productivity 43.3% of total user, 74.6% of total elapsed > }}} > > Notice the `-100999900.0%` productivity in the first summary, which is > printed by the child process. > > Can also reproduce with 8.6. > > Note that you sometimes need to run this a few times to reproduce. Every > once in a while I get normal results (where productivity is not > negative). New description: The existing test `forkprocess01` actually exhibits this behavior, but we just don't have the necessary assertions in place to catch it. One of the assertions I added in https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. Here's the output with GHC 8.4: {{{ $ ghc forkprocess01.hs -debug -rtsopts [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) Linking forkprocess01 ... $ ./forkprocess01 +RTS -s 44,144 bytes allocated in the heap 4,824 bytes copied during GC 37,696 bytes maximum residency (1 sample(s)) 19,648 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s 0.0006s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( 0.001s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.000s ( 0.002s elapsed) %GC time 61200000.0% (32.3% elapsed) Alloc rate 0 bytes per MUT second Productivity -100999900.0% of total user, 47.2% of total elapsed Just (Exited (ExitFailure 72)) 54,160 bytes allocated in the heap 3,480 bytes copied during GC 44,576 bytes maximum residency (1 sample(s)) 25,056 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s 0.0005s INIT time 0.000s ( 0.000s elapsed) MUT time 0.001s ( 0.003s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.002s ( 0.004s elapsed) %GC time 32.0% (14.5% elapsed) Alloc rate 87,073,954 bytes per MUT second Productivity 43.3% of total user, 74.6% of total elapsed }}} Notice the `-100999900.0%` productivity in the first summary, which is printed by the child process. Can also reproduce with 8.6.3. Note that you sometimes need to run this a few times to reproduce. Every once in a while I get normal results (where productivity is not negative). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 17:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 17:27:45 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.6cb76f1fa8641b46b7b220d4f1b113f1@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > The existing test `forkprocess01` actually exhibits this behavior, but we > just don't have the necessary assertions in place to catch it. One of the > assertions I added in > https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. > > Here's the output with GHC 8.4: > > {{{ > $ ghc forkprocess01.hs -debug -rtsopts > [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) > Linking forkprocess01 ... > > $ ./forkprocess01 +RTS -s > 44,144 bytes allocated in the heap > 4,824 bytes copied during GC > 37,696 bytes maximum residency (1 sample(s)) > 19,648 bytes maximum slop > 2 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s > 0.0000s > Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s > 0.0006s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.000s ( 0.001s elapsed) > GC time 0.001s ( 0.001s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 0.000s ( 0.002s elapsed) > > %GC time 61200000.0% (32.3% elapsed) > > Alloc rate 0 bytes per MUT second > > Productivity -100999900.0% of total user, 47.2% of total elapsed > > Just (Exited (ExitFailure 72)) > 54,160 bytes allocated in the heap > 3,480 bytes copied during GC > 44,576 bytes maximum residency (1 sample(s)) > 25,056 bytes maximum slop > 2 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s > 0.0000s > Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s > 0.0005s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.001s ( 0.003s elapsed) > GC time 0.001s ( 0.001s elapsed) > EXIT time 0.000s ( 0.000s elapsed) > Total time 0.002s ( 0.004s elapsed) > > %GC time 32.0% (14.5% elapsed) > > Alloc rate 87,073,954 bytes per MUT second > > Productivity 43.3% of total user, 74.6% of total elapsed > }}} > > Notice the `-100999900.0%` productivity in the first summary, which is > printed by the child process. > > Can also reproduce with 8.6.3. > > Note that you sometimes need to run this a few times to reproduce. Every > once in a while I get normal results (where productivity is not > negative). New description: The existing test `forkprocess01` actually exhibits this behavior, but we just don't have the necessary assertions in place to catch it. One of the assertions I added in https://gitlab.haskell.org/ghc/ghc/merge_requests/51 catches this bug. Here's the output with GHC 8.4: {{{ $ ghc forkprocess01.hs -debug -rtsopts [1 of 1] Compiling Main ( forkprocess01.hs, forkprocess01.o ) Linking forkprocess01 ... $ ./forkprocess01 +RTS -s 44,144 bytes allocated in the heap 4,824 bytes copied during GC 37,696 bytes maximum residency (1 sample(s)) 19,648 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0006s 0.0006s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( 0.001s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.000s ( 0.002s elapsed) %GC time 61200000.0% (32.3% elapsed) Alloc rate 0 bytes per MUT second Productivity -100999900.0% of total user, 47.2% of total elapsed Just (Exited (ExitFailure 72)) 54,160 bytes allocated in the heap 3,480 bytes copied during GC 44,576 bytes maximum residency (1 sample(s)) 25,056 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.001s 0.001s 0.0005s 0.0005s INIT time 0.000s ( 0.000s elapsed) MUT time 0.001s ( 0.003s elapsed) GC time 0.001s ( 0.001s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.002s ( 0.004s elapsed) %GC time 32.0% (14.5% elapsed) Alloc rate 87,073,954 bytes per MUT second Productivity 43.3% of total user, 74.6% of total elapsed }}} Notice the `-100999900.0%` productivity in the first summary, which is printed by the child process. Can also reproduce with 8.6.3 and GHC HEAD. Note that you sometimes need to run this a few times to reproduce. Every once in a while I get normal results (where productivity is not negative). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 17:44:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 17:44:09 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.f9b43f60e0ec19897d7a2c1aae50d18a@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: simonmar, bgamari (added) Comment: The problem is this: when we fork, in the child process CPU time starts from 0 (or at least from a lower value than the value in parent process), but we don't reset `start_init_cpu`, we use the value from the parent process. So `start_init_cpu` becomes larger than `getProcessCPUTime()` in the child process when it starts running. If we immediately then we can observe this state. Here's an example in gdb: (shortly after a `forkProcess()`, in child process): {{{ >>> call getProcessCPUTime() $6 = 238056 >>> print start_init_cpu $7 = 3994827 }}} Not sure how to fix this, but some ideas: - Make the child process inherit the CPU time. (I'm not sure if this is possible though, or if it's possible in all platforms we want to support) - Reset all counters (start_init_cpu, gc times etc.) in the child process. Simon, Ben, any ideas on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 19:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 19:09:25 -0000 Subject: [GHC] #16103: docs-haddock Hadrian target doesn't work reliably Message-ID: <050.924a903dce685538d1f289c25038f6ec@haskell.org> #16103: docs-haddock Hadrian target doesn't work reliably -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- Starting with a clean build, the following doesn't work: {{{ $ ./hadrian/build.sh -c docs-haddock }}} However, it does work if you've already run `./hadrian/build.sh -c`. Here's a sample `--verbose` log (this was produced with `./hadrian/build.sh -c --build-root=_qkst-integer-simple --flavour=quickest docs-haddock --integer-simple --verbose`, but the problem exhibits even without all the extra options): {{{ Up to date Up to date | ContextData oracle: resolving data for 'haddock' (Stage2, v)... | Configure package 'haddock' Configuring haddock-2.22.0... creating /Users/atheriault/Code/ghc/_qkst-integer-simple/stage2/utils/haddock/build /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --numeric- version /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc is version 8.7.20181227 /Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg --version /Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg is version 8.7.20181227 /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --supported-languages /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --info Reading installed packages... /Users/atheriault/Code/ghc/_qkst-integer-simple/stage0/bin/ghc-pkg dump --global -v0 '--global-package-db=/Users/atheriault/Code/ghc/_qkst- integer-simple/stage1/lib/package.conf.d' /Users/atheriault/Code/ghc/_qkst-integer-simple/stage1/bin/ghc --print- libdir '-ghcversion-file=/Users/atheriault/Code/ghc/_qkst-integer- simple/generated/ghcversion.h' CallStack (from HasCallStack): die', called at ./Distribution/Simple/Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at ./Distribution/Simple/Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at ./Distribution/Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at ./Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at ./Distribution/Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at ./Distribution/Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src/Hadrian/Haskell/Cabal/Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian: Encountered missing dependencies: xhtml ==3000.2.* shakeArgsWith 0.000s 0% Function shake 0.010s 0% Database read 0.317s 12% === With database 0.018s 0% Running rules 2.166s 86% ========================= Total 2.511s 99% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: docs-haddock at src/Rules/Documentation.hs:79:9-48: * Depends on: _qkst-integer-simple/docs/html/libraries/index.html at src/Rules/Documentation.hs:136:9-24: * Depends on: _qkst-integer-simple/docs/html/libraries/ghc-prim/ghc- prim.haddock at src/Hadrian/Builder.hs:70:5-23: * Depends on: _qkst-integer-simple/stage2/bin/haddock at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage2, package = Package {pkgType = Program, pkgName = "haddock", pkgPath = "utils/haddock"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _qkst-integer-simple/stage2/utils/haddock/setup-config * Raised the exception: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 20:32:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 20:32:56 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.73a51251cbd75738582d1035282185b7@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * cc: watashi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 20:47:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 20:47:22 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series Message-ID: <045.39ad726a4f99f2525b5422855351a024@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I boiled it down to the following example and would like some guidance on how to make this work: I have the following in file `TestPlugin.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TestPlugin (plugin) where import GhcPlugins import Data.Bits plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" check check :: ModGuts -> CoreM ModGuts check m = do mbN <- thNameToGhcName 'complement case mbN of Just _ -> liftIO $ putStrLn "Found complement!" Nothing -> error "Failed to locate complement" return m }}} And I have a very simple `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} With GHC-8.4.2, I have: {{{ $ ghc-8.4.2 --make -package ghc -c TestPlugin.hs [1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) $ ghc-8.4.2 -package ghc -c Test.hs Found complement! }}} But with GHC 8.6.3, I get: {{{ $ ghc-8.6.3 --make -package ghc -c TestPlugin.hs [1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) $ ghc-8.6.3 -package ghc -c Test.hs ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): Failed to locate complement }}} The problem goes away if I change `Test.hs` to: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} import Data.Bits -- Should not be required in the client code! main :: IO () main = return () }}} That is, if I explicitly import `Data.Bits`. But this is quite undesirable, since `Test.hs` is client code and the users of the plugin have no reason to import all bunch of modules the plugin might need for its own purposes. (In practice, this would require clients to import a whole bunch of irrelevant modules; quite unworkable and not maintainable.) Should I be coding my plugin differently? Or is this a GHC regression? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 21:42:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 21:42:15 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.9f255fc97cc041600cb0603c02dc99c8@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 mpickering): One work around might be to define the plugin in a package, install it in the package database and then use it. This standalone support for plugins has caused a number of issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 22:47:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 22:47:38 -0000 Subject: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian Message-ID: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> #16105: Haddock's resource directory isn't properly handled by Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm still investigating, but several things look off about how Hadrian handles Haddock's resources (which are in `utils/haddock/haddock- api/resource`). * only the `html` folder is being copied, which means that there is no way `haddock --latex` will work * the resources (both `html` and `latex`) should probably be specified as `runtimeDependencies` of the `Haddock` builder instead of woven into the doc rules * the Haddock wrapper in the `BinaryDist` rules specifies the wrong `--lib` dir (we currently put Haddock's resources in the `doc` folder, not the `lib` folder as we do for the Make system) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 22:47:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 22:47:49 -0000 Subject: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian In-Reply-To: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> References: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> Message-ID: <065.847512ce55a32d342b0882839e823be3@haskell.org> #16105: Haddock's resource directory isn't properly handled by Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * owner: (none) => harpocrates -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 28 22:48:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Dec 2018 22:48:10 -0000 Subject: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian In-Reply-To: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> References: <050.050f31a85f7ee6ae879543dbc9563c8b@haskell.org> Message-ID: <065.5c202c6a1067e5aec401ba3528e8c3b6@haskell.org> #16105: Haddock's resource directory isn't properly handled by Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 01:28:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 01:28:52 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.2d1e91dc12e4715452c2e4876765e6e1@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 lerkok): Thanks Matt. Unfortunately that doesn't work either: Here's the original plugin registered: {{{#!hs $ ghc-pkg list sbvPlugin /usr/local/lib/ghc-8.6.3/package.conf.d (no packages) /Users/LeventErkok/.ghc/x86_64-darwin-8.6.3/package.conf.d sbvPlugin-0.11 }}} Example test file: {{{#!hs $ cat T11.hs {-# OPTIONS_GHC -fplugin=Data.SBV.Plugin #-} module T11 where import Data.SBV.Plugin h :: Integer -> Integer h x = x - 1 g :: Integer -> Integer g x = if x < 12 then x+1 else h x {-# ANN f theorem #-} f :: Integer -> Bool f x = g x < g (x+1) }}} And I still get: {{{#!hs $ ghci T11.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling T11 ( T11.hs, interpreted ) *** Exception: [SBV] Impossible happened, while trying to locate GHC name for: Data.Bits.complement CallStack (from HasCallStack): error, called at ./Data/SBV/Plugin/Env.hs:380:30 in sbvPlugin-0.11-9tpp46BgzL09G1cUaUExU2:Data.SBV.Plugin.Env }}} Exactly the same issue. It's the same problem whether I load it in `ghci` or compile with `ghc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 05:19:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 05:19:28 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.f665ac6acf38ccd735e07f6aca651a33@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"9bce364125b55407e632d9a2061d09c6f346fa71/ghc" 9bce3641/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9bce364125b55407e632d9a2061d09c6f346fa71" testsuite: Disable more tests in unregisterised build This disables `ghcilink005`, `foreignInterruptable`, and `T7040_ghci` in the unregisterised build as they tend to fail non-deterministically. See ticket #16085. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 07:04:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 07:04:51 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.353182a100084a46eb6e1d7bab58f2b5@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 osa1): I doubt (1) is possible, so maybe we have to go with (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 09:52:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 09:52:50 -0000 Subject: [GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 In-Reply-To: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> References: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> Message-ID: <061.d1b0e5691c066d33f3dd072e5724b12b@haskell.org> #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > Compiling jsaddle-dom (the JSDOM.Types module in particular) requires > quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer > able to compile it at all with 8 GB of RAM. At first I thought it could > be related to > > https://ghc.haskell.org/trac/ghc/ticket/15304 > > but passing "-fno-worker-wrapper" does not seem to make much of a > difference, therefore it might me a different cause here. > > Reproduce: > > git clone git at github.com:ghcjs/jsaddle-dom.git > > cd jsaddle-dom > > sed -i 's/? "default"/? "ghc843"/1' shell.nix > > nix-shell > > cabal new-build New description: Compiling jsaddle-dom (the JSDOM.Types module in particular) requires quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer able to compile it at all with 8 GB of RAM. At first I thought it could be related to #15304 but passing `-fno-worker-wrapper` does not seem to make much of a difference, therefore it might me a different cause here. Reproduce: {{{ git clone git at github.com:ghcjs/jsaddle-dom.git cd jsaddle-dom sed -i 's/? "default"/? "ghc843"/1' shell.nix nix-shell cabal new-build }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 10:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 10:30:19 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.5e0980e101c81dca71069b3bf201ca14@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): > GHC certainly retains information about modules it has finished compiling in `--make` mode, by design--the information it wrote to the interface file Question: would it be reasonable to add a flag of how much memory is allowed for this kind of buffering? Upon reaching the limit, GHC could clear it up and resort to fetching `hi`-files on demand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 14:41:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 14:41:13 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.897069ef28b97fe0e9796ba5df217734@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 mpickering): No I don't know why this is happening. In my plugins [https://github.com/ocharles/assert- explainer/blob/master/plugin/AssertExplainer.hs#L81 I would use] the `lookupOrig` function so that I can be precise about what module a definition is in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 14:46:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 14:46:34 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.c4e5d3c3b8187a6d49b63dbf93063895@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Julian, can you please paste the exact error you are experiencing as I don't see how `Problem 1` can arise. When we bootstrap GHC, we first compile stage1 with stage0. So no problems here as the call to lookup `mkRational` is made when stage1 is run. When we build stage2, we first build prelude with stage1, including `GHC.Real` so there might be some problems here if a module needs to call `mkRational` before `GHC.Real` is compiled but this is hard to debug without any error messages or other information to be going from! I think at this point it would be very useful if you put your code up as a MR so that people can comment directly about what needs doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 14:51:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 14:51:48 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.8d087259e26b47137ac5f48b8de7c859@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): This is the error (`./boot && ./configure && make -j4`): {{{ WARNING: file compiler/iface/LoadIface.hs, line 428 GHC.Real GHC error in desugarer lookup in GHC.Real: Can't find interface-file declaration for variable mkRational Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181219 for x86_64-apple-darwin): initDs Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[1]: *** [libraries/base/dist-install/build/GHC/Real.o] Error 1 make: *** [all] Error 2 }}} I'll make an MR now... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 15:14:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 15:14:50 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.738ad61767d45f52a5ebb7a0333fd59c@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): https://gitlab.haskell.org/ghc/ghc/merge_requests/55 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 16:07:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 16:07:02 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.ac7d1acbe13d6b9bc08e036b58fa64d8@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 bgamari): I think (2) makes the most sense anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 29 22:26:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Dec 2018 22:26:05 -0000 Subject: [GHC] #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol In-Reply-To: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> References: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> Message-ID: <061.8aa4086478e2f5a41aa1d3c360316265@haskell.org> #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.2 Resolution: | Keywords: clang Operating System: OpenBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5461 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1638350f0629365f20e97554e872d85b75f48d73/ghc" 1638350f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1638350f0629365f20e97554e872d85b75f48d73" rts: fix build failure on OpenBSD (_DYNAMIC symbol collision) Summary: Build failure on OpenBSD-6.4 the the following: ``` rts/RtsSymbols.c:994:1: error: error: redefinition of '_DYNAMIC' as different kind of symbol | 994 | RTS_OPENBSD_ONLY_SYMBOLS | ^ RTS_OPENBSD_ONLY_SYMBOLS ^ ``` On OpenBSD `_DYNAMIC` was always defined in `` headers but used not to be included. The change explicitly includes `` as a source of symbol definition. Signed-off-by: Sergei Trofimovich Test Plan: build-tested on OpenBSD-6.4 Reviewers: bgamari, erikd, simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15945 Differential Revision: https://phabricator.haskell.org/D5461 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 01:49:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 01:49:27 -0000 Subject: [GHC] #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol In-Reply-To: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> References: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> Message-ID: <061.482f74999e1b8e8377e7ac14040b9023@haskell.org> #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.6.2 Resolution: fixed | Keywords: clang Operating System: OpenBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5461 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 01:49:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 01:49:34 -0000 Subject: [GHC] #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol In-Reply-To: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> References: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> Message-ID: <061.fc52ebbfbcedb645aaa98747bab8e9ec@haskell.org> #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.6.2 Resolution: fixed | Keywords: clang Operating System: OpenBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5461 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 09:10:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 09:10:45 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.7ce86f860d7d46e56e7780286610f23f@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): It's worth noting that this MR doesn't include the changes where I attempted to move the functions into `GHC.Real`. I stopped doing that because it would have involved somehow getting the `FractionalLit` type in, too, and I didn't know how to do that while also having it in `BasicTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 09:26:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 09:26:31 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.5d7f136b9d28193e0851b6e5a16bfa85@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Rebased the MR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 10:00:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 10:00:48 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support Message-ID: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> #16106: Remove PowerPC OS X (Darwin) support --------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: powerpc | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- OS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin. The following components contain PowerPC Darwin specific code: * native code generator * RTS * driver * build system -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 10:01:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 10:01:11 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.428e4658390ede4f634006b33d95e26a@haskell.org> #16106: Remove PowerPC OS X (Darwin) support ---------------------------------+-------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------- Changes (by trommler): * owner: (none) => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 10:43:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 10:43:10 -0000 Subject: [GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 In-Reply-To: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> References: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> Message-ID: <061.f1d29ccef4cb13ac1547986a0dede334@haskell.org> #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Description changed by eskimor: Old description: > Compiling jsaddle-dom (the JSDOM.Types module in particular) requires > quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer > able to compile it at all with 8 GB of RAM. At first I thought it could > be related to #15304 but passing `-fno-worker-wrapper` does not seem to > make much of a difference, therefore it might me a different cause here. > > Reproduce: > > {{{ > git clone git at github.com:ghcjs/jsaddle-dom.git > cd jsaddle-dom > sed -i 's/? "default"/? "ghc843"/1' shell.nix > nix-shell > cabal new-build > }}} New description: Compiling jsaddle-dom (the JSDOM.Types module in particular) requires quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer able to compile it at all with 8 GB of RAM. At first I thought it could be related to #15304 but passing `-fno-worker-wrapper` does not seem to make much of a difference, therefore it might be a different cause here. Reproduce: {{{ git clone git at github.com:ghcjs/jsaddle-dom.git cd jsaddle-dom sed -i 's/? "default"/? "ghc843"/1' shell.nix nix-shell cabal new-build }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 12:16:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 12:16:16 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.03bf826cce95b327eff330e4ef4425b2@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Hm. Seems I didn't fully rebase properly. Trying again now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 13:52:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 13:52:51 -0000 Subject: [GHC] #16107: Update GCC compiler & friends Message-ID: <046.7bf324b7f121887d826b46ad7408106f@haskell.org> #16107: Update GCC compiler & friends ----------------------------------------+--------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- gcc used by ghc is now about 1.5 years old. It's going to take some time for a new GHC release as well. Would be good to update gcc too. Probably it's backwards compatible with old gcc so would be easy to patch. https://github.com/ghc/ghc/blob/f11f2521aff16edca150e6eed5102a3da7e4f59a/mk /get-win32-tarballs.sh#L104-L114 source code also points to other tools of which some have newer versions. Packages can be browsed here http://repo.msys2.org/mingw/x86_64/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 13:58:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 13:58:24 -0000 Subject: [GHC] #16108: GHC --version doesn't show arch Message-ID: <046.5a6eb8c15e0de8070ae6c797522d328c@haskell.org> #16108: GHC --version doesn't show arch ----------------------------------------+--------------------------------- Reporter: flip101 | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- On windows type ghc --version displays The Glorious Glasgow Haskell Compilation System, version 8.6.3 Right now it's difficult to determine if it's a 32 bits or 64 bits binary. The Glorious Glasgow Haskell Compilation System, version 8.6.3 (64-bits) Or something like this would be better. Also makes me wonder if there are any other characteristics that make up a difference in ghc binary that is worth mentioning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 14:18:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 14:18:31 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.e16e98a07cffb7db67d2eea120e17029@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ok. Back to having the error above again, now. I'll try moving all the types and functions around `FractionalLit` into `GHC.Real` again now, and hope that importing them into BasicTypes makes sense from there (seems weird to me, but I dno't really understand how it works fully, I guess — feels like I'm trying random stuff without understanding it, which is definitely not how I like to work). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 15:09:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 15:09:16 -0000 Subject: [GHC] #16102: forkProcess causes weird GC summary in the child process In-Reply-To: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> References: <043.2f9fb75cda9caf0333b15577c7965d4d@haskell.org> Message-ID: <058.613c851723d650fba23766997ab5e9df@haskell.org> #16102: forkProcess causes weird GC summary in the child process -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/51 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 15:25:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 15:25:52 -0000 Subject: [GHC] #16109: cabal install H under Windows 10 does not terminate Message-ID: <047.1667fdd0dc3cac04f19dacedbebb05e6@haskell.org> #16109: cabal install H under Windows 10 does not terminate -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: cabal insall | Blocked By: H | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Under Windows 10 using ghc c8.6.3 (Haskell Platform), using cabal to install H (HaskellR) stalls after the message "Completed aeson," with ghc consuming about 5-10% of the CPU forever. I let it run all night and the situation does not change. The command used: 'cabal update; cabal install H'. I tried increasing the priority of the ghc process to "realtime." This increases the cpu usage from 5% to 10-20%, but still no progress after hours (days?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 15:42:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 15:42:31 -0000 Subject: [GHC] #16109: cabal install H under Windows 10 does not terminate In-Reply-To: <047.1667fdd0dc3cac04f19dacedbebb05e6@haskell.org> References: <047.1667fdd0dc3cac04f19dacedbebb05e6@haskell.org> Message-ID: <062.880b4412731441fa768548b409d0f91c@haskell.org> #16109: cabal install H under Windows 10 does not terminate -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime | Test Case: cabal insall performance bug | H Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #16057 Comment: Thanks for the bug report. I see that the source code of H uses a Template Haskell splice, so this is a almost surely a duplicate of #16057. I'll close this in favor of that ticket. (Note that this is a regression that was introduced between 8.6.2 and 8.6.3, so one way to work around this is to use 8.6.2.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 16:09:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 16:09:42 -0000 Subject: [GHC] #16109: cabal install H under Windows 10 does not terminate In-Reply-To: <047.1667fdd0dc3cac04f19dacedbebb05e6@haskell.org> References: <047.1667fdd0dc3cac04f19dacedbebb05e6@haskell.org> Message-ID: <062.4a76764ea6f27e4686717d8557c83a54@haskell.org> #16109: cabal install H under Windows 10 does not terminate -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime | Test Case: cabal insall performance bug | H Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsamperi): It appears that the install process never gets to the source code of H, it stalls after installing aeson, so perhaps the Template Haskell issue comes up in some other package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 16:48:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 16:48:53 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? Message-ID: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- While playing around with GHC HEAD recently, I noticed some rather bizarre behavior when trying to use explicit `forall`s with associated type family defaults. Let's pop open GHCi and recreate it: {{{ $ inplace/bin/ghc-stage2 --interactive -XTypeFamilies -XScopedTypeVariables GHCi, version 8.7.20181215: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> class C a where { type T a b; type forall b. T a b = Either a b } }}} OK, so far, so good. Now let's see what happens when I omit the `b`: {{{ λ> class C a where { type T a b; type forall. T a b = Either a b } }}} That... works? Wow, I wouldn't have expected that... But it gets even worse—I can type in utter nonsense, and GHCi will accept it: {{{ λ> class C a where { type T a b; type forall dup dup dup. T a b = Either a b } λ> class C a where { type T a b; type forall (a :: a). T a b = Either a b } λ> class C a where { type T a b; type forall (a :: k) k. T a b = Either a b } }}} How could this possibly happen? After looking at the source code to see how associated type family defaults are renamed, it becomes clear why this is the case. Here is how they are [http://git.haskell.org/ghc.git/blob/ef57272e28f5047599249ae457609a079d8aebef:/compiler/rename/RnSource.hs#l841 renamed]: {{{#!hs rnTyFamDefltEqn cls (FamEqn { ... , feqn_bndrs = bndrs , ... }) = do { ... ; return (FamEqn { ... , feqn_bndrs = ASSERT( isNothing bndrs ) Nothing , ... }, ...) } }}} Not only are the type variable binders ignored, there's actually an `ASSERT`ion in place which assumes that there will be no binders whatsoever! (I haven't checked, but I suspect the code above will trigger a failure on that `ASSERT`ion.) My questions after seeing all of this are: * Should we be accepting explicit `forall`s in associated type family defaults at all? * If so, should we remove this strange invariant that the binders will always be `Nothing`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 17:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 17:04:50 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm Message-ID: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- Consider this program: {{{#!hs module Main (main) where import Data.Bits import Data.Word main :: IO () main = print $ toInteger (shiftL 1 hm :: Word64) == toInteger (shiftL 1 hm :: Word64) hm :: Int hm = -1 {-# NOINLINE hm #-} }}} The result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bug: Bad shift length-1 $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... False $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bug: Bad shift length-1 }}} This program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 17:31:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 17:31:43 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.9ed3a05fa7e43e6f06d7c9ea4ff94218@haskell.org> #16106: Remove PowerPC OS X (Darwin) support ---------------------------------+-------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------- Changes (by admock): * cc: admock (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 18:08:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 18:08:54 -0000 Subject: [GHC] #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package In-Reply-To: <042.6f9317183740e6c428dbe334554fec22@haskell.org> References: <042.6f9317183740e6c428dbe334554fec22@haskell.org> Message-ID: <057.44a9708865782062dcd10a24ed5466b4@haskell.org> #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 sgraf): davide: Any news on this? Mind if I look into it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 18:26:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 18:26:16 -0000 Subject: [GHC] #16112: T11334b fails in the devel2 way Message-ID: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> #16112: T11334b fails in the devel2 way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{patch --- dependent/should_fail/T11334b.run/T11334b.stderr.normalised 2018-12-30 16:00:25.377677569 +0000 +++ dependent/should_fail/T11334b.run/T11334b.comp.stderr.normalised 2018-12-30 16:00:25.377677569 +0000 @@ -1,24 +1,13 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20181230 for x86_64-unknown-linux): + ASSERT failed! + f_aBF[tau:2] + 2 + 1 + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType -T11334b.hs:8:14: - Cannot default kind variable ‘f0’ - of kind: k0 -> * - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose - -T11334b.hs:8:14: - Cannot default kind variable ‘g0’ - of kind: k10 -> k0 - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose - -T11334b.hs:8:14: - Cannot default kind variable ‘a0’ - of kind: k10 - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 18:26:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 18:26:36 -0000 Subject: [GHC] #16112: T11334b fails in the devel2 way In-Reply-To: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> References: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> Message-ID: <061.bdca5dfa243bb260319fd82a84036789@haskell.org> #16112: T11334b fails in the devel2 way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) Old description: > {{{patch > --- dependent/should_fail/T11334b.run/T11334b.stderr.normalised > 2018-12-30 16:00:25.377677569 +0000 > +++ dependent/should_fail/T11334b.run/T11334b.comp.stderr.normalised > 2018-12-30 16:00:25.377677569 +0000 > @@ -1,24 +1,13 @@ > +ghc: panic! (the 'impossible' happened) > + (GHC version 8.7.20181230 for x86_64-unknown-linux): > + ASSERT failed! > + f_aBF[tau:2] > + 2 > + 1 > + Call stack: > + CallStack (from HasCallStack): > + callStackDoc, called at > compiler/utils/Outputable.hs:: in :Outputable > + pprPanic, called at compiler/utils/Outputable.hs:: > in :Outputable > + assertPprPanic, called at > compiler/typecheck/TcType.hs:: in :TcType > > -T11334b.hs:8:14: > - Cannot default kind variable ‘f0’ > - of kind: k0 -> * > - Perhaps enable PolyKinds or add a kind signature > - In an expression type signature: Proxy 'Compose > - In the expression: Proxy :: Proxy 'Compose > - In an equation for ‘p’: p = Proxy :: Proxy 'Compose > - > -T11334b.hs:8:14: > - Cannot default kind variable ‘g0’ > - of kind: k10 -> k0 > - Perhaps enable PolyKinds or add a kind signature > - In an expression type signature: Proxy 'Compose > - In the expression: Proxy :: Proxy 'Compose > - In an equation for ‘p’: p = Proxy :: Proxy 'Compose > - > -T11334b.hs:8:14: > - Cannot default kind variable ‘a0’ > - of kind: k10 > - Perhaps enable PolyKinds or add a kind signature > - In an expression type signature: Proxy 'Compose > - In the expression: Proxy :: Proxy 'Compose > - In an equation for ‘p’: p = Proxy :: Proxy 'Compose > +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug > }}} New description: {{{#!patch --- dependent/should_fail/T11334b.run/T11334b.stderr.normalised 2018-12-30 16:00:25.377677569 +0000 +++ dependent/should_fail/T11334b.run/T11334b.comp.stderr.normalised 2018-12-30 16:00:25.377677569 +0000 @@ -1,24 +1,13 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20181230 for x86_64-unknown-linux): + ASSERT failed! + f_aBF[tau:2] + 2 + 1 + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType -T11334b.hs:8:14: - Cannot default kind variable ‘f0’ - of kind: k0 -> * - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose - -T11334b.hs:8:14: - Cannot default kind variable ‘g0’ - of kind: k10 -> k0 - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose - -T11334b.hs:8:14: - Cannot default kind variable ‘a0’ - of kind: k10 - Perhaps enable PolyKinds or add a kind signature - In an expression type signature: Proxy 'Compose - In the expression: Proxy :: Proxy 'Compose - In an equation for ‘p’: p = Proxy :: Proxy 'Compose +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 18:32:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 18:32:04 -0000 Subject: [GHC] #16113: T14740 fails in debugged compiler Message-ID: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> #16113: T14740 fails in debugged compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (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: -------------------------------------+------------------------------------- {{{#!patch --- parser/should_fail/T14740.run/T14740.stderr.normalised 2018-12-30 16:06:27.120170052 +0000 +++ parser/should_fail/T14740.run/T14740.comp.stderr.normalised 2018-12-30 16:06:27.120170052 +0000 @@ -1,4 +1,5 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20181230 for x86_64-unknown-linux): + ASSERT failed! file compiler/types/TyCoRep.hs, line 911 -T14740.hs:5:7: - Expecting a lifted type, but ‘(# #)’ is unlifted - In the type signature: x :: ((# #)) => () +Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 18:32:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 18:32:12 -0000 Subject: [GHC] #16112: T11334b fails in the devel2 way In-Reply-To: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> References: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> Message-ID: <061.9bd256ea073b1616e8e86f2160a0f20b@haskell.org> #16112: T11334b fails in the devel2 way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 18:35:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 18:35:04 -0000 Subject: [GHC] #16113: T14740 fails in debugged compiler In-Reply-To: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> References: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> Message-ID: <061.5401020aee8275cd87f58ca9181fbf2e@haskell.org> #16113: T14740 fails in debugged compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The same assertion also fails in `tcfail159`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 19:00:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 19:00:17 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.009b4dfeed64eec8dbb114582139e9cd@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 lerkok): Some further bad news; this impacts `haddock` as well: {{{ $ haddock --optghc="-package ghc" Test.hs Haddock coverage: Warning: Package name is not available. 0% ( 0 / 2) in 'TestPlugin' Missing documentation for: Module header plugin (./TestPlugin.hs:5) haddock: ^^ Could not load '_TestPlugin_plugin_closure', dependency unresolved. See top entry above. }}} There's a related cabal issue: https://github.com/haskell/cabal/issues/888, which suggests adding `{-# LANGUAGE TemplateHaskell #-}` to the `Test.hs` program though it should not be necessary. But doing so doesn't help either. With this `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} {-# LANGUAGE TemplateHaskell #-} -- shouldn't be needed, but let's try main :: IO () main = return () }}} `cabal` now says: {{{ [istanbul]~/qq>haddock --optghc="-package ghc" Test.hs Haddock coverage: Warning: Package name is not available. 0% ( 0 / 2) in 'TestPlugin' Missing documentation for: Module header plugin (./TestPlugin.hs:5) haddock: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): mkPluginUsage: file not found TestPlugin /var/folders/ty/r22vmk1j7kxc60j8f5l3wgzc0000gn/T/.haddock-85267/TestPlugin.o Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:234:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So, we're back to square one here. Unfortunately, the workaround of "first create a .o" file doesn't really work in this context as I don't think that's something I can instruct `haddock` to do; much less if it's coming from `cabal haddock`. Really stumped on how to proceed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 19:02:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 19:02:42 -0000 Subject: [GHC] #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package In-Reply-To: <042.6f9317183740e6c428dbe334554fec22@haskell.org> References: <042.6f9317183740e6c428dbe334554fec22@haskell.org> Message-ID: <057.3b591c45b1ceaea355f2990d6756fcd9@haskell.org> #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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): Please do pick this up, sgraf! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 19:15:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 19:15:26 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.0a40777cbd6af2ec4d67f69058052388@haskell.org> #16106: Remove PowerPC OS X (Darwin) support ---------------------------------+-------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------- Comment (by bgamari): Agreed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 21:19:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 21:19:21 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.884999544dc48aab159933c5bf3129c3@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 mpickering): Workaround: package the plugin in a package? Did you try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 21:32:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 21:32:07 -0000 Subject: [GHC] #16093: mkPluginUsage: file not found In-Reply-To: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> References: <045.ced356b4f6c623d294fdfaf7d6173713@haskell.org> Message-ID: <060.c4d0daeea9a112e4b1bd62b28afc0b22@haskell.org> #16093: mkPluginUsage: file not found -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 lerkok): Not sure how to do that here: The haddock is running for the plugin package itself in my actual use case. (And showing this very symptom.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 23:39:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 23:39:37 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.fb861c0901da5c96b9f7d92c54c36254@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger 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 olligobber): Note this is still an issue in 8.6.2 {{{ GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help Prelude> :print fmap ghc: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): isUnliftedType t1_a1x6[rt] :: TYPE t_a1x5[rt] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:2021:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 30 23:55:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Dec 2018 23:55:06 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.a5505ca7bf6b950f254ae6a098a250ab@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have made some progress here, all on `wip/T15952`. A big goal is to sweep away two tricky invariants: * `Note [The well-kinded type invariant]` in `TcType`, which asked that `tcTypeKind` would work even before zonking. But that led to the horrible need to maintain even Refl casts, because we might have `((a::kappa) (b::Type))` where `kappa` is a unification variable that has already been unified `kappa := Type -> Type`. This is only well-kinded if we can see through that unification variable. So previously we used `mkNakedCastTy` to add a stupid Refl cast. `((a::kappa) |> (Refl (Type->Type)) (b::Type)`. Not only is this unsavory, but it's also very fragile: many functions (e.g. substitution) eliminate that Refl cast. * `Note [The tcType invariant]` in `TcHsType`. This was closely related, and was a delicate invariant about the result kind of `tc_hs_type`. It forced a bunch of invariants on related functions. The good news is that I was able to completely dispense with both invariants. I've introduced * `Type.tcTypeKind :: TcType -> TcKind`. This is non-monadic, but respects the distinction between `Type` and `Constraint`. * `TcMType.tcTypeKindM :: TcType -> TcM TcKind`. This one is monadic, and looks through unification variables. You can call the former on any zonked `TcType`; but if the type may be well-kinded only after zonking, you must use the latter. It's always safe to use `tcTypeKindM`, but there are some times when it is clearly safe to call `tcTypeKind`, and very convenient do to so without resorting to the monad, such as in `TcErrors`. Sadly, it's not clear at every call site which is the right one. A number of other functions had to become monadic too * `tcEqTypeM` (because it calls `tcTypeKindM`) * `piResultTysM` (needed by `tcTypeKindM`) * `splitPiTyInvisibleM` * `invisibleTyBndrCountM` * `tcTupKindSortM` * `tcIsConstraintKindM` * `isPredTyM` All these functions appear together in `TcMType`. All the mkNakedX functions go away, which is great. This is all good, but I'm still unhappy. * There are many calls to `isPredTy`, just to distinguish `->` from `=>`. And we need `isPredTyM` now. I think we should just add an `ArgFlag` to `FunTy`. * These changes did not solve #15918 as we thought it would. The cause of #15918 is that `mkCastTy` calls `isReflexiveCo`, which does not respect the distinction between `Type` and `Constraint`. The reason `mkCastTy` calls the blunderbuss `isReflexiveCo` is described in `Note [Respecting definitional equality]` in `TyCoRep`. So do we need a `mkTcCastTy`, wich ''does'' respect the `Type`/`Constraint` distinction? And thence `mkTcAppTy` (since `mkAppTy` calls `mkCastTy`), and `tcSubstTy` as well? This smells like bringing all the `mkNakedX` functions back! I rather wonder if, rather than having the complicated invariants described in `Note [Respecting definitional equality]` we might instead just make the `splitX` functions able to deal with casts? Oddly, #15799 works in HEAD, and in this new branch; so the new stuff can't claim to have fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 01:54:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 01:54:43 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.bde81ba007eba8bc01a9e29caa9046b7@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 Fuuzetsu): * cc: Fuuzetsu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 04:38:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 04:38:47 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.a96a77692ad26aaea9692e48e82e3b34@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 goldfire): I have not reviewed the code, but just responding to comment:7. I agree about adding `ArgFlag` to `FunTy`, but not the way you probably want. I see `FunTy` as an abbreviation of `ForAllTy`, where the argument is relevant (preserved at runtime) and non-dependent (cannot appear in the rest of the type). Morally (in my opinion), we should have `ForAllTy` store a `TyCoBinder`, which stores either a `Named TyCoVarBinder` or an `Anon Type`. The `TyCoVarBinder` is a pair containing a `TyVar` and an `ArgFlag`. This `ForAllTy` should be called `PiTy`. It was implemented en route to the TypeInType patch but then `FunTy` was re-extracted from it for performance reasons. "Adding `ArgFlag` to `FunTy`" really means that the primordial `PiTy` now stores either a `Named (ArgFlag, TyVar)` or an `Anon (ArgFlag, Type)`. (I've rewritted `TyCoVarBinder` as `(ArgFlag, TyVar)` to simplify the presentation... and to ignore coercion variables, which can indeed safely be ignore in these parts.) But looking at this definition, we see an "obvious" refactor: store a `(NamedFlag, ArgFlag, TyVar)` where `NamedFlag` is a `Bool` cognate that says whether or not the quantifier is dependent. In the end, though, this information is needed only for performance reasons, as we can always treat quantifiers as dependent, but some usage sites won't take advantage of this capability. So that leaves us with `(ArgFlag, TyVar)` as the payload of the binder part of a `PiTy` (along with the "body" part, containing a `Type`). In other words: {{{#!hs data Type = ... | PiTy (ArgFlag, TyVar) Type | ... }}} Now, consider this code that we might try to compile: {{{#!hs data Dict :: Constraint -> Type where MkDict :: c => Dict c foo :: forall (x :: Proxy (MkDict :: Dict c)). Proxy x -> () }}} What's the representation of the type of `foo`? It should be something like {{{#!hs foo :: PiTy (Specified, c :: Constraint) $ PiTy (Inferred, ct :: c) $ PiTy (Specified, x :: Proxy (Dict c) (MkDict c ct)) $ PiTy (Required, _ :: Proxy (Proxy (Dict c) (MkDict c ct)) x) $ unitTy }}} Now we have a usage site of `foo`. We instantiate this type. But, critically, '''how do we instantiate `ct`'''? Do we (a) emit an wanted constraint `c`, or (b) create a fresh unification variable `alpha` and then unify it with the right part of the type of the passed argument to `foo`? This choice matters -- it's conceivable that the solver in strategy (a) will find a different solution for `ct` than unification would come up with (in a situation with incoherency -- which normally does not imperil the type system). The bottom line here is that we need to indicate, for implicit arguments, precisely how GHC should try to infer them when they are omitted. Note that Agda does this: unification is indicated by single braces and solving is indicated by double braces. Currently, `ArgFlag` says when an argument is implicit. In the future, though, I think it will additionally need to specify an instantiation strategy for implicit arguments. To wit, we might have {{{#!hs data InstStrategy = Solve | Unify data ArgFlag = Inferred InstStrategy | Specified InstStrategy | Required }}} or possibly {{{#!hs data InstStrategy = Solve | Unify data VisibleInstAllowed = CanBeVisible | CannotBeVisible data ArgFlag = Invisible InstStrategy VisibleInstAllowed | Visible }}} Zooming back to the present: should we add `ArgFlag` to `FunTy`? I say: "no", because the current `ArgFlag` doesn't scale to the situation described above. Instead -- if we don't want to buy into the more elaborate scheme above -- we should make a new {{{#!hs data NonDepArgFlag -- rename me = SolvedFor | Visible -- I wish I could just reuse Required but no TDNR }}} and then add that to `FunTy`. This approach then naturally scales up to the more elaborate scheme described above. It also has the added bonus of not using the three-way `ArgFlag` to describe a situation which currently only has 2 possibilities. ------------------------------------- Frustrating about #15918. But I agree with your analysis here. As long as we have two different equality relations (the one where `Type ~ Constraint` and the one where it doesn't), this problem will persist. And I think trying to cheat by avoiding writing all these extra functions will fail. As to the idea of simplifying `mkCastTy` in favor of complicating `tcSplitXXX`, I think that might work fine... but I don't think it will save sweat or tears. We would need to have `tc` variants of all the splitting functions instead of all the making functions. And the problems we'll run into will be the same. I favor doing the work at construction, because I conjecture that we construct less often than we split, and it will make inspecting dumps easier (because we'll know that things that look different really are different). And I don't think that having, e.g., `mkTcCastTy` is as bad as the nakedness business. The naked casts were a nasty, fragile hack, using `Refl` in a way it was never intended. `mkTcCastTy`, on the other hand, is a perfectly sensible operation to build a type in a way so that types we consider equal have identical representations. The downside to the new approach is that it requires more code duplication, etc., than the naked- casts trick. -------------------------- About #15799: That bug requires #12045 to witness, though the underlying fault exists in HEAD. I never drilled down to figure out how #12045 triggers it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 04:57:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 04:57:58 -0000 Subject: [GHC] #16110: Explicit foralls in associated type family defaults are completely ignored? In-Reply-To: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> References: <050.1ae6b2a1275e4d10dee6f177abfa1bb2@haskell.org> Message-ID: <065.f790cde06eeaef22fd3044aec5c7305b@haskell.org> #16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 goldfire): * cc: mayac (added) Comment: Cc'ing the author of the new feature. Matt? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 07:18:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 07:18:04 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.bbbef4e0973e1a3cc92b4b287bd652d3@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Changes (by trommler): * status: patch => merge Comment: Fixed in changeset:ef57272e28f5047599249ae457609a079d8aebef. Could this be merged to the 8.6 branch as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 09:29:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 09:29:10 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.3c6828cc761369687f6035ac48294701@haskell.org> #16106: Remove PowerPC OS X (Darwin) support ---------------------------------+-------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------- Description changed by trommler: Old description: > OS X for PowerPC is not supported by Apple anymore. GHC's support has > most likely bit-rotted and we have no test machine. Let's go ahead and > remove support for PowerPC Darwin. > > The following components contain PowerPC Darwin specific code: > * native code generator > * RTS > * driver > * build system New description: OS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin. The following components contain PowerPC Darwin specific code: * native code generator * RTS * driver * build system * testsuite -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 15:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 15:02:07 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." Message-ID: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't understand what's happening here: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Prelude> data T a Prelude> instance Eq a => Eq a => Eq (T a) where (==) = undefined :2:10: error: • Class ‘Eq’ does not have a method ‘==’ • In the instance declaration for ‘Eq (T a)’ }}} Is that even syntactically correct? (ghc-8.4.4 says "malformed instance") If so, then I'd assume that `A => B => C` means `A && B => C`, that is, `(A,B) => C` in this case, but it does not, since this works: {{{ instance (Eq a, Eq a)=> Eq (T a) where (==) = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 15:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 15:56:58 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.fb08294608f11b70214f13c26e2db8e2@haskell.org> #16106: Remove PowerPC OS X (Darwin) support -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: patch Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/63 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/63 Comment: I removed all traces of PowerPC Darwin that I could find with `git grep`. This patch has passed validate on powerpc64le Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 16:24:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 16:24:11 -0000 Subject: [GHC] #16114: strange "instance .. => .. => .. where ..." In-Reply-To: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> References: <049.eeed01eddbff1ff2d316e865660d775c@haskell.org> Message-ID: <064.65d67ced7aa5d1f3f946ea1c88ddd35f@haskell.org> #16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Good catch. This seems to have been caused by commit 1c062b794bf71a329f65813ce7b72fe2bd3935f0 (`Simplify rnLHsInstType`), which removed this "`Malformed instance`" error message. Thoughts, simonpj? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 16:24:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 16:24:32 -0000 Subject: [GHC] #16115: Missing associated type instance not reported with error Message-ID: <045.a02b44ddfabe4100eda07a68d256646c@haskell.org> #16115: Missing associated type instance not reported with error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed [https://stackoverflow.com/questions/53987924/haskell-couldnt- match-expected-type-item-nat-with-actual-type this SO question] was caused by a warning disappearing as a result of the error it caused. {{{#!hs {-# language TypeFamilies, DataKinds #-} module NoWarning where data Nat = Zero | Succ Nat deriving Show class FromList a where type Item a :: * fromList :: [Item a] -> a instance FromList Nat where fromList [] = Zero fromList (a:as) = Succ (fromList as :: Nat) fish :: Nat fish = fromList [(),(),()] }}} If you delete `fish`, you get a nice warning: {{{ NoWarning.hs:8:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘Item’ • In the instance declaration for ‘FromList Nat’ | 8 | instance FromList Nat where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} But with `fish`, all you get is {{{ NoWarning.hs:13:18: error: • Couldn't match expected type ‘Item Nat’ with actual type ‘()’ • In the expression: () In the first argument of ‘fromList’, namely ‘[(), (), ()]’ In the expression: fromList [(), (), ()] | 13 | fish = fromList [(),(),()] | }}} That warning is the proper explanation of the problem, and it's just missing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 17:50:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 17:50:57 -0000 Subject: [GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables Message-ID: <050.52cb18a7610be3a9ca0e961b030d0df1@haskell.org> #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This doesn't typecheck on GHC HEAD: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a b instance C (Maybe a) where type forall b. T (Maybe a) b = Either a b }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: The RHS of an associated type declaration mentions out-of-scope variable ‘a’ All such variables must be bound on the LHS | 9 | type forall b. T (Maybe a) b = Either a b | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But it ought to. `a` isn't out of scope at all—it's bound by the class head `instance C (Maybe a)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 21:22:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 21:22:05 -0000 Subject: [GHC] #16058: GHC built on macOS Mojave nondeterministically segfaults In-Reply-To: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> References: <046.94a0f99f3dd27610ab45df43c6d0df65@haskell.org> Message-ID: <061.fcd515616be83067495725c6f1d73376@haskell.org> #16058: GHC built on macOS Mojave nondeterministically segfaults -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 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 gwynne): This crashing is caused by the incorrect practice of loading static archives directly into memory. The `align` field of the various sections in the `__TEXT` segment is not respected; instead the entire file is mapped directly in using `mmap()`, which results in sections often loading at addresses which are only 8-byte aligned. The files on disk are not properly aligned, since `ld` was never given the opportunity to correctly arrange them. In turn, this causes any SSE instructions which load from memory (as found in, especially, crypto algorithms implemented in C) to raise `#GP` faults - SSE memory loads require 16-byte alignment. It's essentially blind luck that this has been working for any length of time in the past. This technique of loading static archives directly into memory at runtime is problematic at best; this crash is far from the only issue. With no involvement by `ld` and `dyld`, no symbols or debug information were available. There was absolutely no evidence anywhere in the crash logs to even make a start at tracking down the issue; only the presence of a consistent repro case and a lot of examining memory regions by hand made finding the root cause possible. `MH_OBJECT` files are not intended to be treated as final executable code. And to add insult to injury, the technique is fundamentally incompatible with code signing. Re-implementing parts of `dyld` by hand like this is not a replacement for macOS not supporting static linking. In the absence of switching to a supported behavior (e.g. dynamic loading), an appropriate fix consists of: 1. Disable the `mmap()` codepath in the Mach-O loader. It prevents correct alignment handling and does not provide a significant performance benefit. 2. Teach the loader to handle alignment on a section-by-section (''not'' segment!) basis and to correctly apply the appropriate relocations. The existing "align the entire file" codepath is not sufficient. 3. Remove the conceit that there will be only one segment to load. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 31 21:27:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Dec 2018 21:27:50 -0000 Subject: [GHC] #16117: Random segfaults at runtime on macOS Mojave caused by GHC linker misaligning sections Message-ID: <045.10c97ab5432f45bfa2a5efd444748c79@haskell.org> #16117: Random segfaults at runtime on macOS Mojave caused by GHC linker misaligning sections -------------------------------------+------------------------------------- Reporter: gwynne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Linking) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC-built binaries sometimes crash at runtime on Mojave. The crash is caused by the incorrect practice of loading static archives directly into memory. The `align` field of the various sections in the `__TEXT` segment is not respected; instead the entire file is mapped directly in using `mmap()`, which results in sections often loading at addresses which are only 8-byte aligned. The files on disk are not properly aligned, since `ld` was never given the opportunity to correctly arrange them. In turn, this causes any SSE instructions which load from memory (as found in, especially, crypto algorithms implemented in C) to raise `#GP` faults - SSE memory loads require 16-byte alignment. It's essentially blind luck that this has been working for any length of time in the past. This technique of loading static archives directly into memory at runtime is problematic at best; this crash is far from the only issue. With no involvement by `ld` and `dyld`, no symbols or debug information were available. There was absolutely no evidence anywhere in the crash logs to even make a start at tracking down the issue; only the presence of a consistent repro case and a lot of examining memory regions by hand made finding the root cause possible. `MH_OBJECT` files are not intended to be treated as final executable code. And to add insult to injury, the technique is fundamentally incompatible with code signing. Re-implementing parts of `dyld` by hand like this is not a replacement for macOS not supporting static linking. In the absence of switching to a supported behavior (e.g. dynamic loading), an appropriate fix consists of: 1. Disable the `mmap()` codepath in the Mach-O loader. It prevents correct alignment handling and does not provide a significant performance benefit. 2. Teach the loader to handle alignment on a section-by-section (''not'' segment!) basis and to correctly apply the appropriate relocations. The existing "align the entire file" codepath is not sufficient. 3. Remove the conceit that there will be only one segment to load. -- Ticket URL: GHC The Glasgow Haskell Compiler