May 2017 - ghc-tickets

Re: [GHC] #605: Optimisation: strict enumerations
by GHC 14 May '17

14 May '17

#605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/605#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12600: Overloaded method causes insufficient specialization
by GHC 13 May '17

13 May '17

#12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: 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: -------------------------------------+------------------------------------- The `foo` function in the following code does not get specialized completely by `ghc -O2`, even though all the overloaded functions in the module are marked `INLINE`. Specifically, it gets compiled into a call to a function with an `Eq Int` dictionary passed at runtime. {{{#!hs module Foo where class Eq1 f where eq1 :: (Eq a) => f a -> f a -> Bool data F a = F !a !a data G f a = G !(f a) !(f a) instance Eq1 F where eq1 = \(F a b) (F c d) -> -- In order to reproduce the problem, the body of this function needs to be -- large enough to prevent GHC from voluntarily inlining it. larger $ larger $ larger $ larger $ larger $ larger $ a == c && b == d {-# INLINE eq1 #-} larger :: a -> a larger = id {-# NOINLINE larger #-} instance (Eq1 f) => Eq1 (G f) where eq1 = \(G a b) (G c d) -> eq1 a c && eq1 b d {-# INLINE eq1 #-} foo :: G F Int -> G F Int -> Bool foo a b = eq1 a b }}} Looking at the dumps, it looks like there may be a problem is the specializer. It creates a specialization of `eq1` with the type `(Eq a) => G F a -> G F a -> Bool` rather than the fully-specialized type: `G F Int -> G F Int -> Bool` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13346: Run nofib with -fspec-constr-keen
by GHC 13 May '17

13 May '17

#13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Per Ben Gamari's comment on https://phabricator.haskell.org/D3186, we should try running `nofib` with `-fspec-constr-keen`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13693: RTS cannot be reinitialized reliably after hs_exit()
by GHC 13 May '17

13 May '17

#13693: RTS cannot be reinitialized reliably after hs_exit() -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 6.10.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #2863 added the FFI spec violation to the docs, but as far as I can tell, there is and was no ticket to actually fix the problems, which seem to be: 1. If the runtime is deinitialized by an `hs_exit()` matching the ''first'' `hs_init()`, then it cannot be reinitialized reliably using `hs_init()`. 2. This condition is not detected, and leads to unpredictable behavior. I'll add a link to ''this'' ticket to the user's guide; even if the ticket is ultimately closed as `WONTFIX`, it will be good to have a persistent reference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11272: Overloaded state-monadic function is not specialised
by GHC 13 May '17

13 May '17

#11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13682: When printf "%g" with trailing 0 number, decial point be printed.
by GHC 13 May '17

13 May '17

#13682: When printf "%g" with trailing 0 number, decial point be printed. ----------------------------------------+--------------------------------- Reporter: nakaji_dayo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: printf | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- C lang's printf function doesn't print decimal point if only trailing 0s. But GHC does. {{{ Prelude Text.Printf> :m + Text.Printf Prelude Text.Printf> printf "%g\n" 2.0 2.0 }}} {{{ #include <stdio.h> int main() { printf("%g\n", 2.0); return 0; } // output: 2 }}} Is this bug? Should printf be compatible with C? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13682> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12962: No automatic SCC annotations for functions marked INLINABLE
by GHC 12 May '17

12 May '17

#12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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: -------------------------------------+------------------------------------- Judging from .prof files and the -xc and -prof callstacks, GHC adds no automatic SCC annotations for functions marked `INLINABLE`. The user's guide only mentions `INLINE`: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h…, not `INLINABLE`. Is it a bug in documentation or implementation? In my case I managed to work around by using `-fexpose-all-unfoldings` instead of the tons of `INLINABLE` I was using before, but in general case, adding all the SCC annotations by hand seems prohibitive. e.g., in code that needs a lot of `INLINABLE` to enable specialization. Since `-fexpose-all-unfoldings` does not inhibit profiling and compiling with no optimization doesn't help recover it, the culprit is probably not the actual inlining or specialization, but rather handling of the `INLINABLE` pragma itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym
by GHC 12 May '17

12 May '17

#11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (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: -------------------------------------+------------------------------------- For convenience, I'll use GHCi to demonstrate flag behavior. First, we define a file: ``` {-# LANGUAGE TypeInType #-} import Data.Kind type Star = Type newtype T k (t :: k) = T () ``` Next, we load it up in GHCi, WITHOUT `-XTypeInType`. Now we observe strange behavior: ``` ezyang@sabre:~$ ghc-8.0 --interactive C.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( C.hs, interpreted ) Ok, modules loaded: Main. *Main> :k T Type Int T Type Int :: * *Main> :k T Star Int <interactive>:1:3: error: • Data constructor ‘Star’ cannot be used here (Perhaps you intended to use DataKinds) • In the first argument of ‘T’, namely ‘Star’ In the type ‘T Star Int’ ``` Of course, if we pass `-TypeInType` to GHCi that fixes the problem (BTW, `DataKinds` does NOT solve the problem.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11966: Surprising behavior with higher-rank quantification of kind variables
by GHC 12 May '17

12 May '17

#11966: Surprising behavior with higher-rank quantification of kind variables -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry about the rubbish title. I wrote the following code, which type checks: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Test where import Data.Kind (Type) -- Simplification type family Col (f :: k -> j) (x :: k) :: Type -- Base types data PGBaseType = PGInteger | PGText -- Transformations data Column t = Column Symbol t newtype Nullable t = Nullable t newtype HasDefault t = HasDefault t -- Interpretations data Expr k data Record (f :: forall k. k -> Type) = Record {rX :: Col f ('Column "x" 'PGInteger) ,rY :: Col f ('Column "y" ('Nullable 'PGInteger)) ,rZ :: Col f ('HasDefault 'PGText)} }}} However, if I play with this in GHCI, I can get the following error: {{{ λ> let x = undefined :: Record Expr <interactive>:136:29-32: error: • Expected kind ‘forall k. k -> Type’, but ‘Expr’ has kind ‘forall k. k -> *’ • In the first argument of ‘Record’, namely ‘Expr’ In an expression type signature: Record Expr In the expression: undefined :: Record Expr }}} It seems that if I write {{{#!hs data Expr :: forall k. k -> Type }}} things work, but I'm unclear if/why that is necessary, and the error message certainly needs to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon
by GHC 12 May '17

12 May '17

#12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: Yes. | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UnicodeSyntax #-} import Prelude.Unicode type Constrd a = Num a ⇒ a data ADT a = ADT (Constrd a) ExistentiallyLost data ExistentiallyLost = ∀ u. TC u ⇒ ExistentiallyLost u class u ~ (ATF1 u, ATF2 u) ⇒ TC u where type ATF1 u ∷ * type ATF2 u ∷ * uie_handlers ∷ ADT Int -- Loop: -- - ADT depends on ExistentiallyLost (also the Constrd appendage) -- - ExistentiallyLost depends on TC -- - TC depends on ADT }}} --> {{{ [1 of 1] Compiling Main ( /home/deepfire/src/ghc-testcases /tyconroles-sees-a-tctycon-tyalias.hs, interpreted ) <- ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160421 for x86_64-unknown-linux): tyConRoles sees a TcTyCon Constrd Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10