February 2016 - ghc-tickets

[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

[GHC] #11383: CAFs lose sharing due to implicit call stacks
by GHC 05 Apr '16

05 Apr '16

#11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 implicit call stack machinery adds a constraint to CAFs, which loses sharing in some cases. The regression is fixed by -O (actually `-ffull- laziness`), but it is surprising nonetheless, and might cause problems for people using GHCi or other places where -O is turned off. For example: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} module Main where import System.Environment fib :: Integer -> Integer fib n = if n < 2 then 1 else fib (n-1) + fib (n-2) x = if fib 3 > 20 then error "x" else fib 30 main = do [n] <- getArgs case n of "a" -> print (x + x) "b" -> print x }}} Try it as follows (requires 8.0+): {{{ $ ghc imp.hs -fforce-recomp -O -fno-full-laziness $ ./imp a +RTS -t 2692538 <<ghc: 430859568 bytes, 822 GCs, 36580/44384 avg/max bytes residency (2 samples), 1M in use, 0.000 INIT (0.000 elapsed), 0.156 MUT (0.203 elapsed), 0.018 GC (0.009 elapsed) :ghc>> $ ./imp b +RTS -t 1346269 <<ghc: 215456192 bytes, 411 GCs, 36580/44384 avg/max bytes residency (2 samples), 1M in use, 0.000 INIT (0.000 elapsed), 0.073 MUT (0.119 elapsed), 0.008 GC (0.004 elapsed) :ghc>> }}} With GHC 7.10 and earlier both commands perform the same. Note that this only uses `error`, and doesn't require `ImplicitParams`. It does require `NoMonomorphismRestriction`, however. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11383> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11231: GHC's configure script does not honour CC env var
by GHC 04 Apr '16

04 Apr '16

#11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- `./configure --help` tells us that: {{{ ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Report bugs to <glasgow-haskell-bugs(a)haskell.org>. }}} However, neither - `CC=clang-3.8 ./configure`, nor - `./configure CC=clang-3.8` has any effect. `./configure` keeps using the `/usr/bin/gcc` in `$PATH`. The only invocation that has the desired effect is - `./configure --with-gcc=clang-3.8` However, this is utterly surprising and confusing to experienced developers who are used to Autoconf `./configure` scripts adhering to the conventions regarding `CC`, and contradicts the `--help` message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10970: Built in MIN_VERSION macro support
by GHC 04 Apr '16

04 Apr '16

#10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Pursuant to https://mail.haskell.org/pipermail/ghc- devs/2015-September/010015.html Recapped here: when preprocessing Haskell source code, we generate a temporary stub header file which defines a number of MIN_VERSION macros, ala what Cabal generates today. Specifically, for every explicitly specified package dependency (via a `-package` or `-package-id` argument), we generate a `MIN_VERSION_pkgname` macro which tests for the version recorded for the package database. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[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