February 2018 - ghc-tickets

[GHC] #14824: automatically select instance
by GHC 27 Feb '18

27 Feb '18

#14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 is {{{#!hs class C a b where m :: [a] -> b instance C x0 x0 instance C x1 x2 instance C x0 x3 }}} x0 x1 x2 x3 is Types. FunctionalDependencies can't work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13075: Top-level bang pattern accepted
by GHC 27 Feb '18

27 Feb '18

#13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I compile/link {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where !(Just x) = Nothing main = putStrLn "hi there!" }}} I get {{{ rae:09:50:49 ~/temp> ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... ld: can't open output file for writing: Bug, errno=21 for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) }}} This bogus code should be rejected more gracefully (and earlier). It actually also loads into GHCi, but shouldn't. Will fix while I'm in the area. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14855: Implementation of liftA2 for Const has high arity
by GHC 26 Feb '18

26 Feb '18

#14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | 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: -------------------------------------+------------------------------------- {{{ instance Monoid m => Applicative (Const m) where pure _ = Const mempty liftA2 _ (Const x) (Const y) = Const (x `mappend` y) (<*>) = coerce (mappend :: m -> m -> m) }}} https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Con… `(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the following not have better inlining behavior? {{{ liftA2 _ = coerce (mappend :: m -> m -> m) }}} Going further, should the unused argument also be moved to the RHS? What about `pure`? What are the pros and cons compared to this other alternative: {{{ pure = \_ -> mempty liftA2 = \_ -> coerce (mappend :: m -> m -> m) }}} This came up while implementing `Applicative` for `K1` in phab:D4447. `K1` is essentially the same type as `Const` and thus their instances should be identical for the sake of consistency. Is `Const`'s `Applicative` instance already optimal? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14855> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13596: Try disabling inlining of DynFlags combinators
by GHC 26 Feb '18

26 Feb '18

#13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `DynFlags` requires a surprisingly amount of effort to compile. One thing I've been meaning to try is disabling inlining of `make_ord_flag` and such to characterize how much of an impact these inlinings have on simplification effort. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #855: Improvements to SpecConstr
by GHC 26 Feb '18

26 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Calling the very simple optimiser (in `CoreOpt`) on the LHS might help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14850: mallocBytes allows underflow
by GHC 26 Feb '18

26 Feb '18

#14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.… This function doesn't complain when passed a negative number. Instead you get something like `*** Exception: malloc: resource exhausted (out of memory)` Which is confusing, and probably not consistent across platforms. This came up in https://github.com/tel/saltine/issues/42 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14850> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14839: Bits typeclass law for LSB
by GHC 26 Feb '18

26 Feb '18

#14839: Bits typeclass law for LSB -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: base | 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 documentation for the `Bits` typeclass claims: > Bits are numbered from 0 with bit 0 being the least significant bit. However, there's no law specified in the typeclass that enforces this. I realized this recently because I've been adding the laws for `Bits` to a library of property tests I maintain: http://hackage.haskell.org/package /quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html#v:bitsLaws In another package of mine, someone requested to add a `Bits` instance for a type but with the MSB considered bit 0. (https://github.com/andrewthad /haskell-ip/issues/29) I thought this would fail to satisfy a law of `Bits`, but it doesn't. So at the least, I was thinking we could add the following laws to `FiniteBits`: {{{ countTrailingZeros (bit 0) = 0 countLeadingZeros (bit 0) = finiteBitSize undefined - 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #855: Improvements to SpecConstr
by GHC 26 Feb '18

26 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This is what I have so far: [https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6… #diff-992f9a53caac96c0e6303669d68a20e1 diff] The reason why I couldn't find the lambda's free vars in the `ValueEnv` earlier is that the matching [https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6… #diff-992f9a53caac96c0e6303669d68a20e1R2140 argToPat case] didn't add them before. That's a problem for our specific case, where the free vars of the lambda are bound within the call-pattern, e.g. `Just (let x = 4 in \y. x + y)`. With that fix in place, the free var values are detected just fine and guided by the `ConVal` case I could implement the [https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6… #diff-992f9a53caac96c0e6303669d68a20e1R2180 specialisation code]. From what I can tell, the generated specialisation looks great, but it isn't called anywhere because now the rules no longer fire. My particular solution would just introduce let bindings into the lambda body that re-bind things we find to be values (similar to how arguments of a data con are handled). Example: {{{ let { lvl_s4md = *# sc_s4rb sc_s4rb lvl_s4lL = I# lvl_s4md lvl_s4ll = Yield @ Bool @ Int False lvl_s4lL } in MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> case ds_d2Fz of { False -> Stop @ Bool @ Int; True -> lvl_s4ll }) True ==> let { lvl_s4md = *# sc_s4rb sc_s4rb lvl_s4lL = I# lvl_s4md lvl_s4ll = Yield @ Bool @ Int False lvl_s4lL } in MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> let { lvl_s4ll = Yield @ Bool @ Int False (I# sc_s4md) } in case ds_d2Fz of { False -> Stop @ Bool @ Int; True -> lvl_s4ll }) True }}} Kind-of a manual float-in of all bindings we know are values and have corresponding `ScrutOcc` (which we ignore at the moment). This results in a much better specialisation for `Just (MkStream <lam> True)` I believe (`dump-simpl`): {{{ $s$wgo_s4rg :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $s$wgo_s4rg (sc_s4rf :: GHC.Prim.Int#) (sc1_s4re :: GHC.Prim.Int#) (sc2_s4rd :: GHC.Prim.Int#) = jump $wgo_s4ph GHC.Types.SPEC (GHC.Prim.+# sc2_s4rd sc_s4rf) sc1_s4re (GHC.Base.Just @ (Stream Int) (Main.MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> case ds_d2Fz of { False -> Main.Stop @ Bool @ Int; True -> Main.Yield @ Bool @ Int GHC.Types.False (GHC.Types.I# sc_s4rf) }) GHC.Types.False)); }}} There's a problem though: That function doesn't get called any more, because the corresponding RULE looks like this: {{{ "SC:$wgo2" [0] forall (sc_s4rj :: GHC.Prim.Int#) (sc_s4rk :: Bool) (sc_s4ri :: GHC.Prim.Int#) (sc_s4rh :: GHC.Prim.Int#). $wgo_s4ph GHC.Types.SPEC sc_s4rh sc_s4ri (GHC.Base.Just @ (Stream Int) (Main.MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> let { sc_s4rf :: GHC.Prim.Int# [LclId] sc_s4rf = sc_s4rj } in let { lvl_s4ll :: Step Bool Int [LclId] lvl_s4ll = Main.Yield @ Bool @ Int GHC.Types.False (GHC.Types.I# sc_s4rf) } in case ds_d2Fz of { False -> Main.Stop @ Bool @ Int; True -> lvl_s4ll }) sc_s4rk)) = jump $s$wgo_s4rr sc_s4rj sc_s4rk sc_s4ri sc_s4rh }}} E.g. the extra bindings I introduced obstruct the RULE engine. I can probably figure out how to generate the right rules tomorrow. Please yell if I'm missing some critical pass or function to do this! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 26 Feb '18

26 Feb '18

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm. I suppose you could add the original program from this ticket: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module T5927 where data Exists c where Exists :: c a => a -> Exists c instance (forall a. c a => Show a) => Show (Exists c) where show (Exists a) = show a }}} But this actually fails! {{{ Bug.hs:9:10: error: • Could not deduce: c (Exists c) arising from a use of ‘GHC.Show.$dmshowsPrec’ from the context: forall a. c a => Show a bound by the instance declaration at Bug.hs:9:10-53 • In the expression: GHC.Show.$dmshowsPrec @(Exists c) In an equation for ‘showsPrec’: showsPrec = GHC.Show.$dmshowsPrec @(Exists c) In the instance declaration for ‘Show (Exists c)’ • Relevant bindings include showsPrec :: Int -> Exists c -> ShowS (bound at Bug.hs:9:10) | 9 | instance (forall a. c a => Show a) => Show (Exists c) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:9:10: error: • Could not deduce: c (Exists c) arising from a use of ‘GHC.Show.$dmshowList’ from the context: forall a. c a => Show a bound by the instance declaration at Bug.hs:9:10-53 • In the expression: GHC.Show.$dmshowList @(Exists c) In an equation for ‘showList’: showList = GHC.Show.$dmshowList @(Exists c) In the instance declaration for ‘Show (Exists c)’ • Relevant bindings include showList :: [Exists c] -> ShowS (bound at Bug.hs:9:10) | 9 | instance (forall a. c a => Show a) => Show (Exists c) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I'm not sure what to make of this. If you implement `showsPrec` and `showList` manually: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module T5927 where import Text.Show data Exists c where Exists :: c a => a -> Exists c instance (forall a. c a => Show a) => Show (Exists c) where show (Exists a) = show a showsPrec p (Exists a) = showsPrec p a showList l = showListWith (\(Exists a) -> shows a) l }}} Then it typechecks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #855: Improvements to SpecConstr
by GHC 26 Feb '18

26 Feb '18

#855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Thanks for your insights! I have to read up on defunctionalisation, but what you suggest is basically what I had in mind in 1. above: Query the free variables of the lambda and see if they are in the [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23… #diff-992f9a53caac96c0e6303669d68a20e1R2163 ValueEnv] (meaning their RHSs are in WHNF, too). For some reason they weren't present where I expected them, looking into this now. >Should we specialise on (G1 x) or on the deeper pattern (G1 (Yield a b c))? It depends how much f' scrutinises its argument. And you can see that from what applyG does. Well, I'm not sure we can see that without running some kind of simplification first. But with `SPEC`, the matching `ArgOcc` is irrelevant, so we can look into this later. I [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc23… #diff-992f9a53caac96c0e6303669d68a20e1R1144 conveniently left] `CallOcc` with an `ArgOcc` field for when the result of the call is scrutinised for that. I'll go and see if I can get the free vars of the lambda into the `ValueEnv`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/855#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0