March 2017 - ghc-tickets

[GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation
by GHC 08 Mar '19

08 Mar '19

#8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ------------------------------------+--------------------------------- Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ios | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I have been trying to statically link Pandoc packages to iOS application following the guide in https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS and it's great so far! I have finally successfully use Pandoc library in iOS app, but the binary size is very big! 1. More than 50MB when using Pandoc library. 2. Around 5MB for simple haskell code. I try to add “split-objs: True” in .cabal/config file, but when running cabal I got this message: {{{ Preprocessing library pandoc-1.12.2.1... unused terminals: 1 on the commandline: Warning: ignoring -fsplit-objs }}} And if I ignore that, at the end of build, I get another error message that stop the build. {{{ cabal: dist-i386/build/Text/Pandoc_o_split: does not exist }}} I try with another package and got similar error message. It seems that split-objs not only being ignored by cross-compilation ghc, but will also fail the build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8095: TypeFamilies painfully slow
by GHC 08 Mar '19

08 Mar '19

#8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | -------------------------------------+------------------------------------- I'm using the TypeFamilies extension to generate types that are quite large. GHC can handle these large types fine when they are created manually, but when type families get involved, GHC's performance dies. Unlike in ticket #5321, using tail recursion does not eliminate the problem, and the order of arguments greatly affects compile time. I've attached a file Types.hs that demonstrates the problems. This file generates another Haskell file which has the problems. It takes 3 flags. The first is the size of the type to generate, the second is which type family function to use, and the third is whether to call the type family or just use a manually generated type. Here are my performance results: Using non-tail recursion, I get these results. I have to increase the stack size based on the size of the type I want to generate. {{{ $ ./Types 200 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m2.973s $ ./Types 300 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=350 real 0m6.018s $ ./Types 400 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=450 real 0m9.995s $ ./Types 500 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=550 real 0m15.645s }}} Tail recursion generates much slower compile times for some reason, and I still need to adjust the stack size: {{{ $ ./Types 200 b a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m16.120s }}} Changing the order of arguments to the recursive type family greatly changes the run times: {{{ $ ./Types 200 c a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m6.095s }}} Without the type family, I get MUCH better performance: {{{ $ ./Types 10000 a d > test.hs && time ghc test.hs > /dev/null real 0m2.271s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #11715: There's something fishy going on with Constraint
by GHC 07 Mar '19

07 Mar '19

#11715: There's something fishy going on with Constraint -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (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: -------------------------------------+------------------------------------- I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase, {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 82

[GHC] #12509: ghci -XSafe fails in an inscrutable way
by GHC 06 Mar '19

06 Mar '19

#12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: 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: -------------------------------------+------------------------------------- Trying to run `ghci -XSafe` produces the following output: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help <interactive>:1:6: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:30: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. <interactive>:1:46: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:70: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:94: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. <interactive>:1:111: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:135: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:159: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. <interactive>:1:176: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} I'm not sure whether this should work, but in any case the error message is horrible. I tried adding `-trust base` to no avail. For comparison, ghc-7.10.3 starts with no trouble: {{{ > ghci -XSafe GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> }}} (Motivation: I'm using ghci in Safe mode to track down import problems with SafeHaskell. As a workaround, I can use `:set -XSafe` after ghci's startup is done.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12509> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?)
by GHC 06 Mar '19

06 Mar '19

#12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.0.20160511. Example from the user guide: [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts… #constraints-in-kinds Constraints in kinds] {{{#!hs type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where MkNat :: T 42 MkSymbol :: T "Don't panic!" }}} Deriving a standalone `Show` instance *without* the constraint works fine {{{#!hs deriving instance Show (T a) }}} but I couldn't define a `Show` instance given the constraints: {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit a0’ -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘Show’, namely ‘T a’ -- In the stand-alone deriving instance for ‘Show (T a)’ deriving instance Show (T a) }}} let's add constraints {{{#!hs -- • Couldn't match expected kind ‘'True’ -- with actual kind ‘IsTypeLit lit’ -- • In the first argument of ‘Show’, namely ‘T (a :: lit)’ -- In the instance declaration for ‘Show (T (a :: lit))’ instance IsTypeLit lit ~ 'True => Show (T (a :: lit)) where }}} let's derive for a single literal {{{#!hs -- • Illegal type synonym family application in instance: -- T Nat -- ('Data.Type.Equality.C:~ -- Bool -- (IsTypeLit Nat) -- 'True -- ('GHC.Types.Eq# Bool Bool (IsTypeLit Nat) 'True <>)) -- 42 -- • In the stand-alone deriving instance for ‘Show (T (42 :: Nat))’ deriving instance Show (T (42 :: Nat)) }}} same happens with {{{#!hs instance Show (T 42) where }}} ---- The documentation > Note that explicitly quantifying with `forall a` is not necessary here. seems to be wrong since removing it results in {{{ tVDv.hs:10:17-18: error: … • Expected kind ‘a’, but ‘42’ has kind ‘Nat’ • In the first argument of ‘T’, namely ‘42’ In the type ‘T 42’ In the definition of data constructor ‘MkNat’ Compilation failed. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13208: Do two-phase inlining in simpleOptPgm
by GHC 06 Mar '19

06 Mar '19

#13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | 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: -------------------------------------+------------------------------------- As of #12988, having `simpleOptPgm` leave β-redexes lying around is painful because it requires a special loophole in Core Lint to allow a jump inside a β-redex. We'd rather use a two-phase approach, mirroring the simplifier's `preInlineUnconditionally` and `postInlineUnconditionally`, so we can aggressively eliminate β-redexes without fear of exponential blowup. Consider: {{{ joinrec j1 x = e1 in join j2 x y = jump j1 e2 in jump j2 e3 e4 }}} Since `j2` is only used once, it gets inlined. But `simpleOptPgm` only performs inlining //after// a binding is simplified, so we end up here: {{{ joinrec j1 x = e1' in (\x y -> jump j1 e2') e3' e4' }}} Since `e2'` was already simplified, performing the β-reduction here risks exponential blowup for the same reason it can happen in the simplifier (see the Secrets paper; `perf/compiler/T783` is a live example, increasing in allocs by over 80% if we re-simplify here). We //could// just `let`-bind `e3'` and `e4'` (carefully avoiding capturing free occurrences of `x` in `e4'`), but not if one them is actually a type argument. Well, okay, we //could// introduce a type `let`, but doing that here means the desugarer can now return a type `let` and we're not prepared for that. (Specifically, under certain circumstances, the simplifier never runs in between the desugarer and Float Out, and the latter breaks in the presence of type `let`.) So for the moment, we leave the β-redex there, but this needs a special rule just for β-redexes because normally you can't have a jump under a lambda (or an application, for that matter). In the long term, we'd prefer to take the simplifier's approach instead: If we want to inline something because it only occurs once (even though it may be big), we add it to the substitution //before// simplifying it so that we only simplify it once. This means the substitution has to carry lexical closures around, though, just like the simplifier does (see `SimplSR`'s `ContEx` disjunct), so it's not trivial. The `simpleOptPgm` β-redexes are the only reason for the special rule in Core Lint (see Note [Beta redexes] in `CoreLint.hs`), so once this is done we can be rid of that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12596: can't find interface-file declaration
by GHC 05 Mar '19

05 Mar '19

#12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | Owner: 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: -------------------------------------+------------------------------------- full repro at https://github.com/mwotton/liftwoes/issues/1 ``` /home/mark/projects/liftwoes/src/Lib.hs:14:11: error: • Can't find interface-file declaration for variable Data.Text.Internal.pack Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the first argument of ‘(:)’, namely ‘Data.Text.Internal.pack ((:) 'A' [])’ In the first argument of ‘HS.fromList’, namely ``` {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} module Lib where import Data.Data import qualified Data.Set as HS import qualified Data.Text as T import qualified Data.Text.IO as T import Data.Time -- import Instances.TH.Lift import Instances import Language.Haskell.TH.Syntax table = $(do r <- runIO (HS.fromList . T.lines <$> T.readFile "/usr/share/dict/words") [|r|] ) someFunc = do print $ HS.member "foo" table }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10892: ApplicativeDo should use *> and <*
by GHC 05 Mar '19

05 Mar '19

#10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | 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: Differential Revisions: | -------------------------------------+------------------------------------- From @ekmett: Would it be possible to tweak the generation to use `(<*)` or `(*>)` where appropriate when the result isn't being used? For many Applicatives this can be a massive asymptotic win in terms of sharing and/or computational cost. When desugaring using (<*) you'd just omit any handling of the unused result instead. {{{ (\x y -> ...) <$> foo <* bar <*> baz }}} corresponds to {{{ do x <- foo bar y <- baz return ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #8657: -fregs-graph still has a limit on spill slots
by GHC 04 Mar '19

04 Mar '19

#8657: -fregs-graph still has a limit on spill slots -----------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`. SHA-1 fails to compile with `-fregs-graph` in 7.8. Related: #7679 (`-fregs-graph` generates poor code with the new codegen). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12919: Equality not used for substitution
by GHC 04 Mar '19

04 Mar '19

#12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} import Data.Kind data N = Z data V :: N -> Type where VZ :: V Z type family VC (n :: N) :: Type where VC Z = Type type family VF (xs :: V n) (f :: VC n) :: Type where VF VZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ VZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ Op.hs:20:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at Op.hs:19:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at Op.hs:20:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25