October 2015 - ghc-tickets

[GHC] #10818: GHC 7.10.2 takes much longer to compile some packages
by GHC 11 Sep '17

11 Sep '17

#10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If we compile the iproute package by GHC, GHC 7.10.2 take much longer than GHC 7.8.4. See the report from Travis CI: https://travis-ci.org/kazu-yamamoto/iproute/builds/77427248 I can reproduce this on my local MacBookAir: - GHC 7.8.4: cabal build 8.81s user 0.94s system 103% cpu 9.430 total - GHC 7.10.2: cabal build 37.86s user 3.49s system 98% cpu 42.066 total -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9661: Branchless ==# is compiled to branchy code
by GHC 08 Sep '17

08 Sep '17

#9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a comment on #6135, but Jan Stolarek requested that I file a separate report. The branchless tests `<#`, `>#`, `<=#`, and `>=#`, and their wordy cousins, seem to work properly, but `==#` and `eqWord#` don't. If I write {{{#!hs foo x = tagToEnum# ((x <# 3#) `orI#` (x ># 100#) `orI#` (x ==# 12#) `orI#` (x ==# 15#)) }}} I get (in 7.8.3 and in 7.9) {{{#!hs IsDigit.foo :: GHC.Prim.Int# -> GHC.Types.Bool [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,1*U>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x3_a2if [Occ=Once!] :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}] IsDigit.foo = \ (x3_a2if :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}} and branching assembly to match. Jan Stolarek indicates this is probably a problem with constant folding. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9661> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #10365: Make Semigroup as a superclass of Monoid
by GHC 07 Sep '17

07 Sep '17

#10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a -superclass-of-Monoid-td5767835.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types
by GHC 06 Sep '17

06 Sep '17

#9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we see `m >>= (\_ -> n)` with a type that admits an optimized `>>` or `<$`, we should try to take advantage of that. I don't currently know if this applies to any types under "GHC HQ" control. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10328: Control.Monad exports lead to weird Haddocks
by GHC 06 Sep '17

06 Sep '17

#10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `Control.Monad` exports, and therefore documents, the `Functor` class (but only the `fmap` member) and the `Monad` class. It does not export, and therefore does not document, the `Applicative` class. This is all pretty weird. Since `Functor` is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from `Control.Monad`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10328> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9756: Warn about unnecessary unsafeCoerce
by GHC 06 Sep '17

06 Sep '17

#9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `unsafeCoerce` has been around a lot longer than `coerce`, so older code tends to use it even if `coerce` could do the job. It would be nice if the type checker could produce a warning when it detected such a situation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9574: GHC Panic: No Skolem Info
by GHC 05 Sep '17

05 Sep '17

#9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.8.3 and from git both panic with Couldn't match kind ‘o1’ with ‘(,) o o’ ‘o1’ is untouchable inside the constraints (Object (c :><: c) a) bound by a type expected by the context: Object (c :><: c) a => Tagged a (c (FMap (ProductF c) a) (FMap (Proj2 c c) a)) at Product.hs:35:9-15ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140908 for x86_64-unknown-linux): No skolem info: o1_a6XS I have not yet attempted to reduce the problem at all. The offending code is the use of fmap here: {{{#!hs proj2 :: forall (c :: o -> o -> *). ProductCategory c => NatTr (c :><: c) c (ProductF c) (Proj2 c c) proj2 = NatTr t where NatTr t = fmap (CompF Proj2 IdentityF) e e :: NatTr (c :><: c) (c :><: c) (Comp ('KProxy :: KProxy o) (Diag c) (ProductF c)) (IdentityF (c :><: c)) e = counit }}} fmap is defined as {{{#!hs fmap :: forall f (a :: o1) (b :: o1). Functor f ('KProxy :: KProxy (o1 -> o2)) => f -> Domain f a b -> Codomain f (FMap f a :: o2) (FMap f b :: o2) fmap _ = proxy morphMap (Proxy :: Proxy f) }}} while CompF is defined by {{{#!hs data CompF f g (k :: KProxy (o3 -> o4, o1 -> o2)) where CompF :: (Functor f ('KProxy :: KProxy (o3 -> o4)), Functor g ('KProxy :: KProxy (o1 -> o2))) => f -> g -> CompF f g ('KProxy :: KProxy (o3 -> o4, o1 -> o2)) }}} This makes some sense because there is a functional dependency between the functor and the kind proxy. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8317: Optimize tagToEnum# at Core level
by GHC 29 Aug '17

29 Aug '17

#8317: Optimize tagToEnum# at Core level ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6135 | ------------------------------------+------------------------------------- Old comparison primops that returned Bool were implemented by inserting call to `tagToEnum#` in the code generator. This call to `tagToEnum#` was later optimized away by a special case in the code geenrator (see [[GhcFile(compiler/codeGen/StgCmmExpr.hs)]], Note [case on bool])). Now that we have new comparison primops (see #6135) we no longer insert `tagToEnum#` in the code generator - all uses of `tagToEnum#` come from explicit calls in a source program. But we still have that special case in the code generator to optimize away `tagToEnum#`. We should drop that special case in the code generator and handle scrutinizing of `tagToEnum#` at the Core level by: 1. removing call to `tagToEnum#` in the scrutinee 2. adding calls to `dataToTag#` in case branches 3. constant-folding inserted `dataToTag#` Here is an example. This Haskell code: {{{ if tagToEnum# (a ># b) then E1 else E2 }}} will be translated to this Core: {{{ case tagToEnum# (a ># b) of True -> E1 False -> E2 }}} and optimized like this: {{{ case a ># b of dataToTag# True -> E1 dataToTag# False -> E2 }}} ====> {{{ case a ># b of 1 -> E1 0 -> E2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10807: PatternGuards and MultiWayIf layout rules
by GHC 16 Aug '17

16 Aug '17

#10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!hs {-# LANGUAGE PatternGuards, MultiWayIf fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9352: Allow `State# s` argument/result types in `ccall` FFI imports
by GHC 16 Aug '17

16 Aug '17

#9352: Allow `State# s` argument/result types in `ccall` FFI imports -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket is to allowing code like {{{#!hs {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE MagicHash #-} module M where import GHC.Exts foreign import ccall unsafe "foo" c_foo :: Int# -> State# s -> State# s foreign import ccall unsafe "bar" c_foo :: Int# -> State# s -> (# State# s, Int# #) }}} See also discussion in #9218 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9352> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10