January 2017 - ghc-tickets

[GHC] #11444: 8.0 rc1 panics in applyTypeToArgs
by GHC 31 Jan '17

31 Jan '17

#11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce, clone https://github.com/rrnewton/haskell-lockfree and switch to ghc-8.0 branch. Then run {{{cabal install atomic-primops/}}} (note the trailing slash, we don't want to install it from Hackage). It should fail with a message like this: {{{ ➜ haskell-lockfree git:(ghc-8.0) ✗ cabal install atomic-primops/ Warning: The package list for 'hackage.haskell.org' is 25.1 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Notice: installing into a sandbox located at /home/omer/haskell/haskell-lockfree/.cabal-sandbox Configuring primitive-0.6.1.0... Building primitive-0.6.1.0... Warning: /tmp/pkgConf-primitive-0.6.110252023621350490027.0: Unrecognized field abi on line 21 Installed primitive-0.6.1.0 Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Failed to install atomic-primops-0.8.0.2 Build log ( /home/omer/haskell/haskell-lockfree/.cabal-sandbox/logs /atomic-primops-0.8.0.2.log ): [1 of 1] Compiling Main ( atomic-primops/dist/dist-sandbox- ad71ba7e/setup/setup.hs, atomic-primops/dist/dist-sandbox- ad71ba7e/setup/Main.o ) Linking atomic-primops/dist/dist-sandbox-ad71ba7e/setup/setup ... Configuring atomic-primops-0.8.0.2... Building atomic-primops-0.8.0.2... Preprocessing library atomic-primops-0.8.0.2... [1 of 3] Compiling Data.Atomics.Internal ( Data/Atomics/Internal.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Internal.o ) Data/Atomics/Internal.hs:69:20: warning: Defined but not used: data constructor ‘Ticket’ [2 of 3] Compiling Data.Atomics.Counter ( Data/Atomics/Counter.hs, dist /dist-sandbox-ad71ba7e/build/Data/Atomics/Counter.o ) [3 of 3] Compiling Data.Atomics ( Data/Atomics.hs, dist/dist-sandbox- ad71ba7e/build/Data/Atomics.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160111 for x86_64-unknown-linux): applyTypeToArgs Expression: readMutVar# eta_s4sC st_s4sD Type: forall d_15 a_12. MutVar# d_15 a_12 -> State# d_15 -> (# State# d_15, a_12 #) Args: [eta_s4sC, st_s4sD] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: atomic-primops-0.8.0.2 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 31 Jan '17

31 Jan '17

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 31 Jan '17

31 Jan '17

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering <matthewtpickering@…>): In [changeset:"748b79741652028827b6225c36b8ab55d22bdeb0/ghc" 748b7974/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="748b79741652028827b6225c36b8ab55d22bdeb0" Use top-level instances to solve superclasses where possible This patch introduces a new flag `-fsolve-constant-dicts` which makes the constraint solver solve super class constraints with available dictionaries if possible. The flag is enabled by `-O1`. The motivation of this patch is that the compiler can produce more efficient code if the constraint solver used top-level instance declarations to solve constraints that are currently solved givens and their superclasses. In particular, as it currently stands, the compiler imposes a performance penalty on the common use-case where superclasses are bundled together for user convenience. The performance penalty applies to constraint synonyms as well. This example illustrates the issue: ``` {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-} module B where class M a b where m :: a -> b type C a b = (Num a, M a b) f :: C Int b => b -> Int -> Int f _ x = x + 1 ``` Output without the patch, notice that we get the instance for `Num Int` by using the class selector `p1`. ``` f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int f = \ (@ b_a1EB) ($d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) -> + @ Int (GHC.Classes.$p1(%,%) @ (Num Int) @ (M Int b_a1EB) $d(%,%)_a1EC) eta1_B1 B.f1 ``` Output with the patch, nicely optimised code! ``` f :: forall b. C Int b => b -> Int -> Int f = \ (@ b) _ _ (x_azg :: Int) -> case x_azg of { GHC.Types.I# x1_a1DP -> GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#) } ``` Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: mpickering, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2714 GHC Trac Issues: #12791, #5835 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13044: make it possible to apply GHC rewrite rules to class methods
by GHC 31 Jan '17

31 Jan '17

#13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Make it possible to apply GHC rewrite rules to class methods. As Conal wrote in a discussion on glasgow-haskell-users, it is too bad that we can't use class laws as optimizations in the form of rewrite rules. In that same thread Simon PJ referenced https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples. https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more background. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 31 Jan '17

31 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: fixed | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: I verified that HEAD still validates on OS X using the in-tree GMP, and that the bus error from `ghc -e 'length (show (2^(5*10^6) :: Integer))'` is gone. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles
by GHC 31 Jan '17

31 Jan '17

#7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.6.3 Resolution: fixed | Keywords: floating | point Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9238, #13212 | Differential Rev(s): Phab:D145 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * related: #9238 => #9238, #13212 Comment: Ticket for adding a faster `abs` implementation is #13212. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7858#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13164: idle time full GCs (idle cpu usage)
by GHC 31 Jan '17

31 Jan '17

#13164: idle time full GCs (idle cpu usage) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: idle GC | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In an interactive program I noticed idle CPU usage of ~12% due to the full GCs done by the RTS on default settings. For this specific usecase this is a lot of wasted CPU cycles for no gain. Passing {{{-I0}}} to the RTS "fixes" this; nonetheless I think that the default behaviour could/should be improved, even when considering other usecases where full GCs are a good choice. The program in question keeps ~50MB allocated on the heap but does close to no short-lived allocations in between the idle GCs. Some relevant data from the summary: {{{ 930,569,008 bytes allocated in the heap 4,847,446,928 bytes copied during GC 46,255,056 bytes maximum residency (111 sample(s)) 378,200 bytes maximum slop 94 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1784 colls, 0 par 0.123s 0.100s 0.0001s 0.0006s Gen 1 111 colls, 0 par 9.377s 9.418s 0.0848s 0.1099s INIT time 0.000s ( 0.003s elapsed) MUT time 2.250s ( 95.029s elapsed) GC time 9.500s ( 9.518s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.007s ( 0.008s elapsed) Total time 11.760s (104.557s elapsed) }}} The detailed GC statistics of the idle GCs look like {{{ Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 13304 45958728 46210536 0.070 0.068 0.920 1.550 0 0 (Gen: 1) 11568 45958720 46210536 0.100 0.102 1.043 2.584 0 0 (Gen: 1) 15432 45958720 46210536 0.103 0.105 1.167 3.588 0 0 (Gen: 1) 11568 45958720 46210536 0.100 0.102 1.287 4.586 0 0 (Gen: 1) 11568 45958720 46210536 0.107 0.107 1.413 5.592 0 0 (Gen: 1) 11568 45958720 46210536 0.073 0.080 1.503 6.566 0 0 (Gen: 1) 11568 45958720 46210536 0.073 0.073 1.593 7.560 0 0 (Gen: 1) 11568 45958720 46210536 0.067 0.068 1.677 8.557 0 0 (Gen: 1) }}} I don't really know what exactly "alloc bytes" means, but my guess is that those numbers are indeed fairly low and those GCs are mostly useless. To clarify the intention of this request: '''Tweak the idle GC (default) configuration in some way so that interactive programs with moderate heap use reasonable amount of CPU time while idle.''' And "reasonable" is intentionally vague as I don't know how to weight other usecases. Minimal example: {{{ import Control.Concurrent main :: IO () main = do let large = [1..1000000] print $ length large [1..20] `forM_` \_ -> do threadDelay 400000 print $ sum large }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 30 Jan '17

30 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"32729d3586d7ecdeb8561b6d0b2a688db709560c/ghc" 32729d35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32729d3586d7ecdeb8561b6d0b2a688db709560c" Turn libraries/integer-gmp/gmp/tarball into a submodule The submodule repository contains the latest version of the GMP source distribution (6.1.2) with the doc/ subdirectory removed, as described in gmp/ghc.mk. Rather than applying the old patch from gmp/tarball/patch I moved its contents into gmp/gmpsrc.patch, canceling a patch related to memory management there. Experimentally, the PIC-related patch for OS X is still necessary. The upgrade to GMP 6.1.2 fixes #7655. Test Plan: Built on OS X with in-tree gmp and tested that the command `ghc -e 'length (show (2^(5*10^6) :: Integer))'` no longer segfaults. Reviewers: mpickering, hvr, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D3044 GHC Trac Issues: #7655 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context
by GHC 30 Jan '17

30 Jan '17

#12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12784 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Quoting [https://ghc.haskell.org/trac/ghc/ticket/12784#comment:15 simonpj] in #12784: > This keeps bugging me. Is this ok or not? > {{{ > class Monad m => MonadSupply m where > fresh :: m Integer > default fresh :: MonadTrans t => t m Integer > fresh = lift fresh > }}} > It's accepted right now. But I think it should not be; specifically, '''I think the type of the default method should differ from the main method only in its context'''. Thus if > {{{ > fresh :: C => blah > }}} > then the default method should look like > {{{ > default fresh :: C' => blah > }}} > with the same `blah`. So we should write > {{{ > class Monad m => MonadSupply m where > fresh :: m Integer > default fresh :: (MonadTrans t, MonadSupply m', m ~ t m') => m Integer > -- NB: same 'm Integer' after the '=>' > fresh = lift fresh > }}} > Why? Several reasons: > > * It would make no sense at all to have a type that was actually ''incompatible'' with the main method type, e.g. > {{{ > default fresh :: m Bool > }}} > That would ''always'' fail in an instance decl. > > * We use Visible Type Application to instantiate the default method in an instance, for reasons discussed in `Note [Default methods in instances]` in `TcInstDcls`. So we need to know exactly what the universally quantified type variables are, and when instantaited that way the type of the default method must match the expected type. > > * Perhaps by changing only the context, we are making it a bit more explicit the ways in which the default method is less polymorphic than the original method. > > With this change, the patches to Agda in comment:14 would all be signalled at the ''class'' decl, which is the right place, not the instance decl. The patches to Agda would still be needed, of course. > > Does that rule make sense to everyone? The [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #class-default-signatures user manual] is silent on what rules the default signature should obey. It's just formalising the idea that the default signature should match the main one, but perhaps with some additional constraints. > > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11046: lookupTypeName does not support type operators
by GHC 30 Jan '17

30 Jan '17

#11046: lookupTypeName does not support type operators -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following non-working code (minus a missing import) was [http://stackoverflow.com/questions/33465109/template-haskell-how-to- lookup-type-operator-name posted on stackoverflow]: `IssueTH.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module IssueTH where import Language.Haskell.TH f :: Q [Dec] f = do Just n <- lookupTypeName "GHC.TypeLits.*" return [] }}} `Issue.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Issue where import IssueTH import GHC.TypeLits $f }}} `ghc Issue.hs` fails with message: `Pattern match failure in do expression at IssueTH.hs:7:5-10` This gives no error if `*` is replaced by an alphanumeric type like `Nat`. Similar tests seem to fail whenever attempting to look up a type operator with `lookupTypeName`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12