September 2015 - 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] #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 07 Apr '16

07 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] #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

[GHC] #10436: Excessive numbers of packages loaded for TH
by GHC 31 Mar '16

31 Mar '16

#10436: Excessive numbers of packages loaded for TH -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When using Template Haskell, the behaviour of ghc with regard to loading packages differs in these two cases: {{{ ghc --make Blah.hs }}} vs {{{ ghc --make Blah.hs -package foo }}} In the first case, ghc will work out for itself which packages it needs to load to run the TH code in `Blah.hs` while in the second case, ghc will unconditionally load package `foo` in addition to anything else. Why is this a problem? Consider a real example (reported on IRC): {{{ ghc --make Main.hs [1 of 4] Compiling Uplink ( Uplink.hs, Uplink.o ) [2 of 4] Compiling FlightData ( FlightData.hs, FlightData.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [3 of 4] Compiling Joystick ( Joystick.hs, Joystick.o ) [4 of 4] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... }}} This just loads `base` and its deps. Great, it works. Now the exact same `Main.hs` built by cabal (which of course uses `-package-id` flags): {{{ cabal build Building jpl-0.1.0.0... Preprocessing executable 'jpl' for jpl-0.1.0.0... [1 of 4] Compiling Uplink ( Uplink.hs, dist\build\jpl\jpl- tmp\Uplink.o ) [2 of 4] Compiling FlightData ( FlightData.hs, dist\build\jpl\jpl- tmp\FlightData.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package SHA-1.6.4.2 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. }}} ... snip a further 80, '''yes 80 packages''' ... {{{ Loading package linear-1.18.0.1 ... linking ... done. Loading package sdl2-2.0.0 ... linking ... ghc.exe: unable to load package `sdl2-2.0.0' ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup ghc.exe: warning: WSAStartup from ws2_32 is linked instead of __imp_WSAStartup ghc.exe: warning: WSACleanup from ws2_32 is linked instead of __imp_WSACleanup }}} ... snip more boring details of the linker errors ... So yes the problem is that in practice some packages (typically FFI things) just can't be loaded in GHCi/TH and then this scuppers everything else, despite the fact that these packages never needed to be loaded in the first place. So the feature request is this: always use the parsimonious demand-driven algorithm for deciding what packages to load when running TH snippets, and don't consider `-package` flags to be instructions to load these packages for running TH code. As a bonus it'll be quicker and our build output shorter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8731: long compilation time for module with large data type and partial record selectors
by GHC 30 Mar '16

30 Mar '16

#8731: long compilation time for module with large data type and partial record selectors -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc1 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- in both ghc 7.6 and 7.8rc, the Constants module in LLVM-General-Pure (and a few other similar modules) have surprisingly long (and noticable!) compilation times. This seems to related to how GHC handles a many constructor data type with overlapping field names. the time is nearly the same for building a static module with O1 and O2 {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O2 1 ↵ [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O2 7.52s user 0.23s system 99% cpu 7.755 total }}} {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O1 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O1 6.62s user 0.20s system 100% cpu 6.768 total }}} heck even with -O0 its slow (though not terrible) {{{ carter repoScratcher/bad-ast » time ghc Constant.hs -O0 [1 of 1] Compiling Constant ( Constant.hs, Constant.o ) ghc Constant.hs -O0 2.76s user 0.14s system 101% cpu 2.873 total }}} Seems like there might something wrong in how we handle data types like this, the complexity need not -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10853: Refine addTopDecls
by GHC 28 Mar '16

28 Mar '16

#10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This suggested refactoring/documentation task is spurred on by #10486. Readers do not have to read that ticket to understand this task. Currently, `addTopDecls` is restricted in what it can add. In an email exchange with Geoff Mainland (the original implementor of `addTopDecls`), it was unclear exactly why this restriction is in place. So, I propose lifting the restriction. We do have to be careful about ordering. As it is currently implemented, here is what happens: {{{ -- region A, including everything up to but not including a top-level splice $( {- region B, the contents of a top-level splice -} ) -- region C, everything after the splice }}} In addition to those regions, we also have {{{ -- region D, consisting of all declarations added with `addTopDecls`. }}} By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the expected behavior should be this: 1. Rename region A. Anything defined in other regions is not in scope. 2. Rename region D, with declarations from region A in scope. 3. Type-check regions A and D together. 4. When running TH code in region B, all declarations from A and D are in scope and can be accessed via `reify` and friends. 5. Combine regions B and C together, and recur to step 1 (where the combined B and C is now a new region A). This all means that A and D are mutually recursive w.r.t. the type-checker but not the renamer. This is a bit peculiar, but not terrible. For example, this means that there could be a function whose definition is in A and type signature in D. Proper mutual recursion would be hard (impossible?) without better renaming support. In any case, I don't see a reason to restrict what's allowed in `addTopDecls`. So, at a minimum, I propose: * Remove restrictions in `addTopDecls` * Document `addTopDecls` generally * Document the above behavior, detailing the interaction between these regions Perhaps better, we could do: * Remove restrictions in `addTopDecls` * Rejigger the implementation of `addTopDecls` to lump region D in with B and C. This looks quite straightforward, and it makes for a simpler story about mutual recursion. This is a potentially-breaking change, if existing code has, say, a function defined in A with its type signature in D. * Document the new, simpler behavior Regardless of which proposal we go with, some testing is in order, to make sure that this is all correct. I've done no testing in formulating this ticket, just reading code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6