March 2016 - ghc-tickets

[GHC] #10513: ghc 7.6.3 Compiler panic with Generics
by GHC 07 Apr '16

07 Apr '16

#10513: ghc 7.6.3 Compiler panic with Generics -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, Agda only compiles with ghc 7.4, 7.8, and 7.10, see https://code.google.com/p/agda/issues/detail?id=1558 Here is a the relevant commit: https://github.com/agda/agda/commit/f7b47de0cb167514f6db859b204abd638887b76f Generics do not seem to work properly in ghc 7.6 {{{ [ 92 of 312] Compiling Agda.Syntax.Abstract.Name ( src/full/Agda/Syntax/Abstract/Name.hs, dist/build/Agda/Syntax/Abstract/Name.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: Agda-2.4.3:Agda.Syntax.Fixity.D1PrecedenceLevel{tc a4mIV} [(rc0D, Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Fixity'{tc rc0D}'), (r4mFT, Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Precedence{tc r4mFT}'), […] (r4mKa, Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fTypeable1ThingWithFixity{v r4mKa}'), (r4mKb, Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fGenericThingWithFixity{v r4mKb}'), (r4mKc,ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know whether you are maintaining old ghcs, but it seems we have to drop Generics until we drop support for ghc 7.6 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10669: Missing Generic instances for base types.
by GHC 07 Apr '16

07 Apr '16

#10669: Missing Generic instances for base types. -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is instance Generic Int in GHC.Generics, but no Generic Word. Also there is no Generic instances for Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10868: Make GHC generics capable of handling unboxed types
by GHC 07 Apr '16

07 Apr '16

#10868: Make GHC generics capable of handling unboxed types -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott RyanGlScott | Type: feature | Status: new request | 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: #8468 Differential Revisions: | -------------------------------------+------------------------------------- Currently, GHC generics will not accept any unboxed constructor arguments: {{{ $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help λ> :set -XMagicHash -XDeriveGeneric λ> :m + GHC.Generics GHC.Exts λ> data IntHash = IntHash Int# deriving Generic <interactive>:4:38: Can't make a derived instance of ‘Generic IntHash’: IntHash must not have unlifted or polymorphic arguments In the data declaration for ‘IntHash’ }}} This makes GHC generics strictly less powerful than `deriving` clauses in some scenarios, as typeclasses like `Eq`, `Ord`, and `Show` are capable of special-casing certain unboxed types: {{{ λ> :set -ddump-deriv λ> data IntHash = IntHash Int# deriving Show ==================== Derived instances ==================== Derived instances: instance GHC.Show.Show Ghci1.IntHash where GHC.Show.showsPrec a_a1OJ (Ghci1.IntHash b1_a1OK) = GHC.Show.showParen ((a_a1OJ GHC.Classes.>= 11)) ((GHC.Base..) (GHC.Show.showString "IntHash ") (GHC.Show.showsPrec 11 (GHC.Types.I# b1_a1OK))) GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0) }}} As discussed on the GHC devs mailing list [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009895.html previously], Andres suggested adding new generic representation types to mark where `Int#`, `Char#`, etc. are used (suggesting the name `UInt` to represent `Int#`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing
by GHC 07 Apr '16

07 Apr '16

#11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 TEST=GEq1 WAY=optasm TEST_HC=ghc-7.11.20151225 ... cd ./generics/GEq && ./GEq1 </dev/null > GEq1.run.stdout 2> GEq1.run.stderr Actual stdout output differs from expected: --- ./generics/GEq/GEq1.stdout.normalised 2015-12-26 15:32:22.984189653 +0100 +++ ./generics/GEq/GEq1.run.stdout.normalised 2015-12-26 15:32:22.984189653 +0100 @@ -3,5 +3,5 @@ True True False -True -True \ No newline at end of file +False +False \ No newline at end of file *** unexpected failure for GEq1(optasm) }}} The test was last touched by Ryan in 6cde981a8788b225819be28659caddc35b77972d (#10868) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11775: singleton classes in ghc.generics are defined but not exported
by GHC 07 Apr '16

07 Apr '16

#11775: singleton classes in ghc.generics are defined but not exported -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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 noticed in the bottom of the GHC.Generics module in the RC candidate that theres some type classea and instnaces involving singletons included and notated as copied from the singletons package but not exported {{{ -------------------------------------------------------------------------------- -- Copied from the singletons package -------------------------------------------------------------------------------- -- | The singleton kind-indexed data family. data family Sing (a :: k) -- | A 'SingI' constraint is essentially an implicitly-passed singleton. -- If you need to satisfy this constraint with an explicit singleton, please -- see 'withSingI'. class SingI (a :: k) where -- | Produce the singleton explicitly. You will likely need the @ScopedTypeVariables@ -- extension to use this method the way you want. sing :: Sing a -- | The 'SingKind' class is essentially a /kind/ class. It classifies all kinds -- for which singletons are defined. The class supports converting between a singleton -- type and the base (unrefined) type which it is built from. class (kparam ~ 'KProxy) => SingKind (kparam :: KProxy k) where -- | Get a base type from a proxy for the promoted kind. For example, -- @DemoteRep ('KProxy :: KProxy Bool)@ will be the type @Bool@. type DemoteRep kparam :: * -- | Convert a singleton to its unrefined version. fromSing :: Sing (a :: k) -> DemoteRep kparam }}} etc, is this deliberate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10030: packageName for GHC.Generics.Datatype
by GHC 07 Apr '16

07 Apr '16

#10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 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: | -------------------------------------+------------------------------------- Seems it's perfectly ok to have the data type of the same name in the same module, but different packages. Yet used in the same module: {{{ {-# LANGUAGE PackageImports #-} {-# LANGUAGE RankNTypes #-} module Data.Foo where import "void" Data.Void as A import Data.Void as B foo :: A.Void -> a foo = absurd bar :: B.Void -> a bar x = x () }}} {{{ {-# LANGUAGE RankNTypes #-} module Data.Void where type Void = forall a b. a -> b }}} https://gist.github.com/phadej/8b628d579ddf6958d937 motivated by: http://stackoverflow.com/questions/28159068/packagename- with-ghc-generics I'd propose to change `Datatype` class to be: {{{ class Datatype d where -- | The name of the datatype (unqualified) datatypeName :: t d (f :: * -> *) a -> [Char] -- | The fully-qualified name of the module where the type is declared moduleName :: t d (f :: * -> *) a -> [Char] -- | The package name of the module where the type is declared packageName :: t d (f :: * -> *) a -> [Char] -- | Marks if the datatype is actually a newtype isNewtype :: t d (f :: * -> *) a -> Bool isNewtype _ = False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X
by GHC 06 Apr '16

06 Apr '16

#8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X ------------------------------------+--------------------------------- Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- According to the OS X man page for sysctl(https://developer.apple.com/library/mac/documentation/Darwin/Referen…, HW_NCPU used by the current implementation of getNumberOfProcessors() is deprecated. Instead, Mac OS X provides the following 4 options: * hw.physicalcpu: The number of physical processors available in the current power management mode. * hw.physicalcpu_max: The maximum number of physical processors that could be available this boot. * hw.logicalcpu: The number of logical processors available in the current power management mode. * hw.logicalcpu_max: The maximum number of logical processors that could be available this boot. I am not sure which one fits best to GHC runtime. Any idea? sysconf implementation of getNumberOfProcessors() seems to prefer _SC_NPROCESSORS_ONLN to _SC_NPROCESSORS_CONF when both are defined. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11698: GHC's tct_closed flag is not being set correctly
by GHC 06 Apr '16

06 Apr '16

#11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 `Note [Bindings with closed types]` in `TcEnv` describes when a binding is "closed", which in turn affects generalisation. (See the Note for details.) But the implementation doesn't follow the Note. Instead it uses this function in `TcEnv`: {{{ isClosedLetBndr :: Id -> TopLevelFlag -- See Note [Bindings with closed types] in TcRnTypes -- Note that we decided if a let-bound variable is closed by -- looking at its type, which is slightly more liberal, and a whole -- lot easier to implement, than looking at its free variables isClosedLetBndr id | isEmptyVarSet (tyCoVarsOfType (idType id)) = TopLevel | otherwise = NotTopLevel }}} It may be easier but it's also wrong. Consider {{{ f x = ( let g y = x+y in ... , x::Int) }}} Is `g` closed (which affects how definitions in `...` are generalised)? Well if we typecheck the second element of the tuple first, we may "know" that `x::Int` by the time we are inferring a type for `g`, conclude that `g` has no free type variables, and say that it is closed. But if we do the `x::Int` part second, so while type checking the `let` we think that `x::alpha`, then we'll say that `g` is open. This looks nasty. I think we should do it the way the `Note` says. Thanks to Facundo for pointing this out. Not urgent, but plainly wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration
by GHC 06 Apr '16

06 Apr '16

#11770: Demand analysis: Wrong one-shot annotation due to fixed-point iteration -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- After quite a while of staring at the core of nofib’s `fft2` benchmark, where my dynamic entry counting code (#10613), I found the problem. Here is a small example: {{{ foo :: Int -> Int -> Int foo 10 c = 0 foo n c = let bar :: Int -> Int bar n = n + c {-# NOINLINE bar #-} in bar n + foo (bar (n+1)) c }}} Clearly, `bar` is not single-entry. But the demand analyzer believes it is: {{{ Rec { -- RHS size: {terms: 32, types: 12, coercions: 0} foo [Occ=LoopBreaker] :: Int -> Int -> Int [LclIdX, Arity=2, Str=<S(S),1*U(U)><L,U(U)>m, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 192 20}] foo = \ (ds [Dmd=<S(S),1*U(U)>] :: Int) (c [Dmd=<L,U(U)>] :: Int) -> case ds of wild [Dmd=<L,1*U(U)>] { I# ds [Dmd=<S,U>] -> case ds of ds { __DEFAULT -> let { bar [InlPrag=NOINLINE, Dmd=<C(S(S)),C(U(U))>] :: Int -> Int [LclId, Arity=1, CallArity=1, Str=<S(S),1*U(U)>m {axl-><S(S),1*U(U)>}, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 0}] bar = \ (n [Dmd=<S(S),1*U(U)>, OS=OneShot] :: Int) -> $fNumInt_$c+ n c } in case bar wild of _ [Occ=Dead, Dmd=<L,A>] { I# x [Dmd=<S,U>] -> case foo (bar (I# (+# ds 1#))) c of _ [Occ=Dead, Dmd=<L,A>] { I# y [Dmd=<S,U>] -> I# (+# x y) } }; 10# -> lvl } } end Rec } }}} The reason is that during the first fixed-point iteration for `foo`, `foo` itself is assumed to not put any demand on its arguments. Under this assumption, it is correct to find that `bar` is called at most once. This is then noted in the lambda binder. The second iteration corrects the demand, but not the one-shot annotation, because that is only added by the demand analyzer, never dropped: {{{#!hs setOneShotness :: Count -> Id -> Id setOneShotness One bndr = setOneShotLambda bndr setOneShotness Many bndr = bndr }}} This can be fixed by changing that code (from `DmdAnal.hs`) to {{{#!hs setOneShotness :: Count -> Id -> Id setOneShotness One bndr = setOneShotLambda bndr setOneShotness Many bndr = clearOneShotLambda bndr }}} But this would have other consequences, e.g. erasing any possible manual one-shot annotations using `oneShot`. Or maybe `setOneShotness` should not be set by the demand analyzer during its work, but once at the end, or maybe even the next simplifier pass should take care of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11779: Merge "Skip TEST=TcCoercibleFail when compiler_debugged"
by GHC 06 Apr '16

06 Apr '16

#11779: Merge "Skip TEST=TcCoercibleFail when compiler_debugged" -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- Hi, please merge 49c55e68aae9841c166430ae566b0d9bdc03c99d into ghc-8.0, to keep the test suite (and travis) useful. Thanks, Joachim -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3