March 2017 - ghc-tickets

[GHC] #13316: Bad inlining cascade leads to slow optimisation
by GHC 24 Apr '17

24 Apr '17

#13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider this simple program {{{ {-# INLINE [0] f #-} f x y = case y of True -> reverse x False -> reverse (reverse x) foo a b = let x = [a,a,a,a] in f x b }}} If you compile with -DDEBUG you'll see {{{ bash$ ghc-stage1 Foo.hs -O -fforce-recomp -c WARNING: file compiler/simplCore/SimplCore.hs, line 670 Simplifier bailing out after 4 iterations [17, 1, 1, 1] Size = {terms: 60, types: 49, coercions: 0, joins: 0/0}}}} }}} Yikes! One transformation per simplifier iteration! What is going on? Before inlining `f` we have {{{ (f [a,a,a,a] b) }}} Then, we inline, beta-reduce, and build let bindings thus {{{ let x1 = a : [] x2 = a : x1 x3 = a : x2 x4 = a : x3 in case b of True -> reverse x4 False -> reverse (reverse x4) }}} So far so good. But then, bizarrely, we do `postInlineUnconditionally` on `x4` (see comments in that function). But not on `x3` because its occ- info is "once inside lambda". Then in the next iteration we `postInlineUnconditionally` `x3`, and so on. Terrible, terrible. My thought: revisit these comments in `postInlineUnconditionally`: {{{ OneOcc { occ_in_lam = in_lam, occ_int_cxt = int_cxt } -- OneOcc => no code-duplication issue -> smallEnoughToInline dflags unfolding -- Small enough to dup -- ToDo: consider discount on smallEnoughToInline if int_cxt is true -- -- NB: Do NOT inline arbitrarily big things, even if one_br is True -- Reason: doing so risks exponential behaviour. We simplify a big -- expression, inline it, and simplify it again. But if the -- very same thing happens in the big expression, we get -- exponential cost! -- PRINCIPLE: when we've already simplified an expression once, -- make sure that we only inline it if it's reasonably small. && (not in_lam || -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = <non-value> -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot- spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} What is particularly annoying in this case is that `x` is used in all code paths, so all this inlining simply duplicates code while gaining nothing. Moreover, if we had {{{ let x = blah in case y of A -> ...x... B -> ..x..x... C -> }}} then the multiple uses of `x` in the `B` branch would disable this entire `preInlineUnconditionally` thing, even though it might be a good idea to push the allocation of `x` into the `A` and `B` branches, to avoid the `C` code path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11384: Error says to fix incorrect return type
by GHC 24 Apr '17

24 Apr '17

#11384: Error says to fix incorrect return type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Defining a constructor that returns the wrong type (non-parent type). If the constructor is not fully-applied or over-saturated GHC reports an error, instead of telling the developer to change the return type: {{{ Prelude> data A Prelude> data B a where MkB :: A () <interactive>:2:23: error: • Expecting one fewer argument to ‘A’ Expected kind ‘* -> *’, but ‘A’ has kind ‘*’ • In the type ‘A ()’ In the definition of data constructor ‘MkB’ In the data declaration for ‘B’ }}} Expected: 1. Suggest GADTs: {{{ • Illegal generalised algebraic data declaration for ‘B’ (Use GADTs to allow GADTs) • In the data declaration for ‘B’ }}} 2. Complain about incorrect return type: {{{ • Data constructor ‘MkB’ returns type ‘A’ instead of an instance of its parent type ‘B a’ • In the definition of data constructor ‘MkB’ In the data type declaration for ‘B’ }}} It shouldn't suggest the user fix the incorrect return type -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10709: Using ($) allows sneaky impredicativity on its left
by GHC 24 Apr '17

24 Apr '17

#10709: Using ($) allows sneaky impredicativity on its left -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Observe the following shady interaction with GHCi: {{{ GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.IO Prelude GHC.IO> import Control.Monad Prelude GHC.IO Control.Monad> :t mask mask :: forall b. ((forall a. IO a -> IO a) -> IO b) -> IO b Prelude GHC.IO Control.Monad> :t replicateM 2 . mask <interactive>:1:16: Couldn't match type ‘a’ with ‘(forall a2. IO a2 -> IO a2) -> IO a1’ ‘a’ is a rigid type variable bound by the inferred type of it :: a -> IO [a1] at Top level Expected type: a -> IO a1 Actual type: ((forall a. IO a -> IO a) -> IO a1) -> IO a1 In the second argument of ‘(.)’, namely ‘mask’ In the expression: replicateM 2 . mask Prelude GHC.IO Control.Monad> :t (replicateM 2 . mask) undefined <interactive>:1:17: Cannot instantiate unification variable ‘a0’ with a type involving foralls: (forall a1. IO a1 -> IO a1) -> IO a Perhaps you want ImpredicativeTypes In the second argument of ‘(.)’, namely ‘mask’ In the expression: replicateM 2 . mask Prelude GHC.IO Control.Monad> :t (replicateM 2 . mask) $ undefined (replicateM 2 . mask) $ undefined :: forall a. IO [a] }}} Due to the way that GHC processes `($)`, it allows this form of impredicativity on the LHS of `($)`. This case is inspired by https://github.com/ghc/nofib/blob/master/smp/threads006/Main.hs which contains the line {{{ tids <- replicateM nthreads . mask $ \_ -> forkIO $ return () }}} I think that line should be rejected. The problem stems from the treatment of `OpenKind` as described in `Note [OpenTypeKind accepts foralls]` in TcMType. Unrelated work changes this behavior by rejecting the nofib program. The point of this ticket is to provoke discussion about what is right and what is wrong here, not to request a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8808: ImpredicativeTypes type checking fails depending on syntax of arguments
by GHC 24 Apr '17

24 Apr '17

#8808: ImpredicativeTypes type checking fails depending on syntax of arguments -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- g1 and g2 below type check, but g1', g2', and g2'' don't even though the types are exactly the same. {{{ {-# LANGUAGE ImpredicativeTypes, NoMonomorphismRestriction #-} module Test where f1 :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char]) f1 (Just g) = Just (g [3], g "hello") f1 Nothing = Nothing f2 :: [forall a. [a] -> [a]] -> Maybe ([Int], [Char]) f2 [g] = Just (g [3], g "hello") f2 [] = Nothing g1 = (f1 . Just) reverse g1' = f1 (Just reverse) g2 = f2 [reverse] g2' = f2 ((:[]) reverse) g2'' = f2 (reverse : []) }}} Compiling it with HEAD gives these errors: {{{ [1 of 1] Compiling Test ( test.hs, test.o ) test.hs:12:16: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a2] -> [a2]’ In the first argument of ‛Just’, namely ‛reverse’ In the first argument of ‛f1’, namely ‛(Just reverse)’ test.hs:15:17: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a0] -> [a0]’ In the first argument of ‛: []’, namely ‛reverse’ In the first argument of ‛f2’, namely ‛((: []) reverse)’ test.hs:16:12: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a1] -> [a1]’ In the first argument of ‛(:)’, namely ‛reverse’ In the first argument of ‛f2’, namely ‛(reverse : [])’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10619: Order matters when type-checking
by GHC 24 Apr '17

24 Apr '17

#10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo True = (\x -> x) :: (forall a. a -> a) -> forall b. b -> b foo False = \y -> y }}} the module compiles. But when I say {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo False = \y -> y foo True = (\x -> x) :: (forall a. a -> a) -> forall b. b -> b }}} it doesn't, failing with {{{ Bug.hs:6:13: Couldn't match type ‘b0 -> b0’ with ‘forall a. a -> a’ Expected type: (forall a. a -> a) -> forall a. a -> a Actual type: (forall a. a -> a) -> b0 -> b0 In the expression: (\ x -> x) :: (forall a. a -> a) -> forall b. b -> b In an equation for ‘foo’: foo True = (\ x -> x) :: (forall a. a -> a) -> forall b. b -> b }}} I believe this behavior stems from the special case in `tcMonoBinds`, for non-recursive functions without a type signature. I believe the bug would be fixed if that function also checks to make sure that there is precisely one clause to the function. Do you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13252: Perf: Make dep_finsts a map from type family Name to Module
by GHC 21 Apr '17

21 Apr '17

#13252: Perf: Make dep_finsts a map from type family Name to Module -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- Today, when we do a family consistency check, we always do a pairwise comparison of every module, even though most of the time, the modules don't even define instances of the same family (making the check futile.) A far better strategy is to say, for any family, which modules transitively below us define instances for it, and only check THOSE pairwise. All we have to do is turn dep_finsts from a list of modules into a mapping from type family names to modules; then we can union the maps and do pairwise comparisons as before. Note that we want to RECORD the map from Name to Module, because we expect any family to have instances defined in many modules (Module to Name is better if a single module defines instances for many families, but clearly this is rare.) This is related to #9717, in that the proposed map here is a more coarse version of what was proposed in that ticket. This may strike a happy compromise between keeping interface files small and speeding things up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9210: "overlapping instances" through FunctionalDependencies
by GHC 21 Apr '17

21 Apr '17

#9210: "overlapping instances" through FunctionalDependencies -------------------------------------------+------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- This program prints `("1",2)`, but if you reverse the order of the two instances, it prints `(1,"2")`. {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} -- extracted from http://lpaste.net/105656 import Control.Applicative import Data.Functor.Identity modify :: ((a -> Identity b) -> s -> Identity t) -> (a -> b) -> (s -> t) modify l f s = runIdentity (l (Identity . f) s) class Foo s t a b | a b s -> t where foo :: Applicative f => (a -> f b) -> s -> f t instance Foo (x, a) (y, a) x y where foo f (a,b) = (\fa -> (fa,b)) <$> f a instance Foo (a, x) (a, y) x y where foo f (a,b) = (\fb -> (a,fb)) <$> f b main = print $ modify foo (show :: Int -> String) (1 :: Int, 2 :: Int) }}} Note that the two instances involved `Foo (Int, Int) (String, Int) Int String` and `Foo (Int, Int) (Int, String) Int String` are not actually overlapping. But, they have the same `a`, `b`, and `s` fields and it seems that this makes GHC think that either one is equally valid, thanks to the fundep. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC
by GHC 20 Apr '17

20 Apr '17

#13495: ghc-stage1: panic! (the 'impossible' happened) creating cross compiler for PPC --------------------------------+---------------------------------------- Reporter: jms | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- We have a product based on a Freescale MPC8544E. I have previously built powerpc-unknown-linux-gnuspe-ghc-7.8.3 and that produces viable code though annoyingly rather large binaries but this is covered elsewhere. I looked at both 7.8.4 and 7.10 a while ago but they proved to be non- starters for reasons I no longer remember. Now for reasons tooling reasons (Stack and friends) it would be nice to use 8.0.2 My procedure is as follows In the (ghc-7.83 or) ghc-8.0.2 source directory base=powerpc-unknown-linux-gnuspe; ./configure --prefix=/tmp/prefix --target=$base --with-gcc=$base-gcc --with-ld=$base-ld --with-nm=$base-nm --with-ar=$base-ar --with-ranlib=$base-ranlib --enable-unregisterised I edit mk/build.mk to make flavour "quick-cross" I edit ghc.mk and comment out anything with haskeline or terminfo The bottom of settings says ("Unregisterised", "YES"), ("LLVM llc command", "/usr/bin/llc-3.7"), ("LLVM opt command", "/usr/bin/opt-3.7") But the make itself (on Ubuntu 16 amd64) fails. "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries /ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist- install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O -fllvm -no-user-package-db -rtsopts -Wno- trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim /dist-install/build -stubdir libraries/ghc-prim/dist-install/build -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.0.2 for powerpc-unknown-linux): LlvmCodeGen.Ppr: Cross compiling without valid target info. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13411: GCC driver fails on Windows 10 15019+
by GHC 20 Apr '17

20 Apr '17

#13411: GCC driver fails on Windows 10 15019+ -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our GCC driver seems to be failing with a compatibility error on Windows 10 Insider builds 15019+. Leaving error code 0xc0000142. This driver has been unchanged since Windows XP and may just need some old APIs replaced. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13501: TH segmentation fault on Linux when calling function from another package
by GHC 20 Apr '17

20 Apr '17

#13501: TH segmentation fault on Linux when calling function from another package -------------------------------------+------------------------------------- Reporter: jmaki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The bug was hit when using Buck (buckbuild.com) to build. I had two packages, A containing a single module with a TH function of type `TH.Q [TH.Dec]` and module B importing A it and calling that function at top-level. I've attached a tarball that reproduces the problem. I've verified that the problem occurs with 7.10.3, 8.0.2 and a semi-recent GHC HEAD from @bitonic. The issue doesn't occur on macOS and does not occur when the modules are in a single package or if the package is compiled as a shared library. The problem also does not occur when using stack, so this is likely related to how buck creates packages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10