December 2015 - ghc-tickets

[GHC] #9563: Support for deriving Generic1 for data families
by GHC 07 Apr '16

07 Apr '16

#9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code: {{{#!hs import GHC.Generics data family F typ :: * -> * data A data instance F A a = AData a deriving Generic1 }}} produces an error when run with ghc 7.8.2 or 7.8.3: {{{ Couldn't match type ‘Rep1 (F A)’ with ‘M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1))’ The type variables ‘t0’, ‘t1’, ‘t2’, ‘t3’, ‘t4’, ‘t5’ are ambiguous Expected type: Rep1 (F A) a Actual type: M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1)) a In the pattern: M1 (M1 (M1 g1)) In an equation for ‘to1’: to1 (M1 (M1 (M1 g1))) = AData (unPar1 g1) In the instance declaration for ‘Generic1 (F A)’ }}} whereas ghc 7.6.3 simply refuses to go ahead with the message: {{{ generic1.hs:14:40: Derived instance `Generic1 (F A)' requires illegal partial application of data type family F In the data instance declaration for `F' }}} Either a check has gone missing in 7.8.x, or a bug has crept up in the Generic1 support. I have gone through past tickets and https://ghc.haskell.org/trac/ghc/ticket/5936 suggests that it is the latter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #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] #10401: state hack-related regression
by GHC 06 Apr '16

06 Apr '16

#10401: state hack-related regression -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following program `exp.hs`: {{{ import Control.Monad import Debug.Trace expensive :: String -> String expensive x = trace "$$$" x {-# NOINLINE expensive #-} main :: IO () main = do str <- fmap expensive getLine replicateM_ 3 $ print str }}} When run as `echo hi | ./exp`, it might print either {{{ $$$ "hi" "hi" "hi" }}} or {{{ $$$ "hi" $$$ "hi" $$$ "hi" }}} depending on the compiler version and optimization settings. In 7.8.4, building with `-O2` produces the second (bad) output, while building with `-O2 -fno-state-hack` produces the first output, not surprisingly. However in 7.10.1 and in HEAD both `-O2` and `-O2 -fno-state-hack` produce the second output. It seems this difference in behavior between 7.8.4 and 7.10.1 may be due to the following difference in the unfolding for IO's fmap. In 7.8.4 {{{ ba867929df0910f70431843781ad014d $fFunctorIO2 :: (a -> b) -> GHC.Types.IO a -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, b #) {- Arity: 3, HasNoCafRefs, Strictness: <L,1*C1(U)><C(S),1*C1(U(U,U))><L,U>, Unfolding: (\ @ a @ b f :: a -> b x :: GHC.Types.IO a s :: GHC.Prim.State# GHC.Prim.RealWorld -> case x `cast` (GHC.Types.NTCo:IO[0] <a>_R) s of ds { (#,#) ipv ipv1 -> (# ipv, f ipv1 #) }) -} }}} while in 7.10.1 {{{ d645bee15151bb50f2bad5912d533b38 $fFunctorIO2 :: (a -> b) -> IO a -> State# RealWorld -> (# State# RealWorld, b #) {- Arity: 3, HasNoCafRefs, Strictness: <L,1*C1(U)><C(S),1*C1(U(U,U))><L,U>, Unfolding: InlineRule (3, True, False) (\ @ a @ b f :: a -> b x :: IO a s :: State# RealWorld[OneShot] -> -- ^^^^^^^ case x `cast` (NTCo:IO[0] <a>_R) s of ds { (#,#) ipv ipv1 -> (# ipv, f ipv1 #) }) -} }}} I didn't completely confirm this, though, nor determine how that difference arose in the first place (I assume the libraries were built with `-O2` for both versions?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11271: Costly let binding gets duplicated in IO action value
by GHC 06 Apr '16

06 Apr '16

#11271: Costly let binding gets duplicated in IO action value -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- The following code is much slower when optimized. {{{#!hs module Main where import Control.Monad import Data.Char import System.IO -- getInt: read a integer from stdin, skipping spaces {-# NOINLINE getInt #-} -- to simplify generated core getInt :: IO Int getInt = skipSpaces >> go 0 where skipSpaces = do next <- hLookAhead stdin if isSpace next then getChar >> skipSpaces else return () go n = do next <- hLookAhead stdin if isNumber next then getChar >> go (10 * n + digitToInt next) else return n {-# NOINLINE generateSlowList #-} generateSlowList :: Int -> [Int] generateSlowList 0 = [1] generateSlowList n = scanl (+) 1 (generateSlowList (n-1)) main = do n <- getInt let ls = generateSlowList n --- !!! replicateM_ n $ do i <- getInt print (ls !! i) }}} How to run: {{{ (echo 10000; yes 5000) | time ./slow > /dev/null }}} After a rough look through the generated core, it seems that the `ls` was moved into the argument to `replicateM_`, which is a lambda taking a `State# RealWorld`. It means that a list is rebuilt every time it's indexed, even though a let binding could have caused sharing. By the way it seems that `-fno-state-hack`, which seems related, doesn't seem to help. Interesting to note that using a bang pattern (`let !ls = ...`) would make the problem go away. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10752: Print which warning-flag controls/enabled an emitted warning
by GHC 05 Apr '16

05 Apr '16

#10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 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: | -------------------------------------+------------------------------------- Both `gcc` and `clang` tell which warning flag a reported warning can be controlled with, e.g. {{{ $ clang-3.5 -Wall -c hello.c hello.c:3:7: warning: unused variable 'x' [-Wunused-variable] int x; ^ 1 warning generated. }}} {{{ $ gcc -Wall -c hello.c hello.c: In function ‘main’: hello.c:3:7: warning: unused variable ‘x’ [-Wunused-variable] int x; ^ hello.c:4:1: warning: control reaches end of non-void function [-Wreturn- type] } ^ }}} With GHC however, we need to lookup the documentation (or memorise all warning flags) to find out which `-fno-warn-*` flag we need to use to silence a specific warning. I propose we augment GHC's warnings in a similar style to how `gcc`/`clang` report flags in compile warnings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10752> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24