March 2016 - ghc-tickets

[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] #11751: Parse error with case in where
by GHC 03 Apr '16

03 Apr '16

#11751: Parse error with case in where ----------------------------------------+--------------------------------- Reporter: samuela | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following code produces a peculiar parse error: {{{#!hs subtype = 0 where (x, y) = case (1, 2) of (a, b) -> (3, 4) }}} `parse_error.hs:3:5: parse error on input ‘(’` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11763: Implement `-f(no-)version-macros` flag for controlling version macro generation
by GHC 01 Apr '16

01 Apr '16

#11763: Implement `-f(no-)version-macros` flag for controlling version macro generation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 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: #10970 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since a9c93bdd8b027d6de09a3eada7721e7fd2d3e050 / #10970 GHC is able to generate `MIN_VERSION_...` and `VERSION_...` natively without Cabal's help. Currently, this feature is currently triggered by `-hide-all-packages`. However, additionally, it seems reasonable to be able to control this more explicitly. E.g. either to be able to explicitly disable even if `-hide- all-packages` implicitly enabled the macros, as well as be able to explicitly request macro generation for currently visible packages even without any `-hide-all-package`/`-package` flags. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #11778: Preserve demandInfo on lambda binders in the simpifier
by GHC 31 Mar '16

31 Mar '16

#11778: Preserve demandInfo on lambda binders in the simpifier -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: -------------------------------------+------------------------------------- In ticket:11731#comment:30, simonpj writes: > Meanwhile, there is a separate issue in ticket:11731#comment:20. It seems that for any un-saturated lambda, we nuke (a) the `occInfo` on the binders (fair enough; the next run of the occurrence analyser will regenerate it), and (b) the `demandInfo` on the binders. The reasoning is explained in comment:20. > > But (b) is permanent; it won't be re-generated until the next run of the demand analyser. And, worse, it applies to function definitions > {{{ > f = \xy . x+y > }}} > Here `x` and `y` will be marked as strictly demanded, but that info will get stripped after the first run of the simplifier. Try it on > {{{ > f :: [Int] -> [Int] -> Int > f x y = head x + head y > }}} > After the demand analyser we have > {{{ > f = \ (x_amY [Dmd=<S,1*U>] :: [Int]) (y_amZ [Dmd=<S,1*U>] :: [Int]) -> ... > }}} > but after the first run of the simplifier we get > {{{ > f = \ (x_amY :: [Int]) (y_amZ :: [Int]) -> ... > }}} > (`f` itself still has a strictness signature that says it is strict in both args.) > > Does this matter? Well, the main reason is that if `f` is inlined, we'd like to get a strict `let`. And now we won't. > > Happily I think it is easily fixed. The key thing is that when doing beta-reduction, which effectively does `(\x.e) b` into `let x=b in e`, we must kill off x's demand/occurrence info if the lambda is not saturated. > > So, idea, in `Simplify.hs`: > > * Give an extra `Bool` to `simplLam` indictating "saturated". > > * Compute (value) saturation in the `simplExprF1 env expr@(Lam {}) cont`, before calling `simpLam`, but do no zapping. > > * In `simplLam`, in the beta-reduction case, > {{{ > simplLam env (bndr:bndrs) body (ApplyToVal { sc_arg = arg, sc_env = arg_se > , sc_cont = cont }) > = do { tick (BetaReduction bndr) > ; simplNonRecE env' (zap_unfolding bndr) (arg, arg_se) (bndrs, body) cont } > }}} > do the binder-zapping right there, if "saturated" is not true. (That neatly puts it with the unfolding-zapping code.) > > Now the non-beta-reduced lambdas won't be zapped, which is right. > > Would you like to try that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11778> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2