January 2017 - ghc-tickets

[GHC] #13206: Error in GHC.Generics documentation
by GHC 30 Jan '17

30 Jan '17

#13206: Error in GHC.Generics documentation -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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 Generic instance shown as automatically derived for the Tree type should read {{{ instance Generic (Tree a) where type Rep (Tree a) = D1 ('MetaData "Tree" "Main" "package-name" 'False) (C1 ('MetaCons "Leaf" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a)) :+: C1 ('MetaCons "Leaf" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Tree a)) :*: S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Tree a))))) from (Leaf f) = M1 (L1 (M1 (M1 (K1 f)))) from (Node f g) = M1 (R1 (M1 ((M1 (K1 f)) :*: (M1 (K1 g))))) to (M1 (L1 (M1 (M1 (K1 f))))) = Leaf f to (M1 (R1 (M1 ((M1 (K1 f)) :*: (M1 (K1 g)))))) = Node f g }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] Batch modify: #11819, #12939
by GHC 30 Jan '17

30 Jan '17

Batch modification to #11819, #12939 by bgamari: milestone to None Comment: Ticket retargeted after milestone closed -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=11819%2C12939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13209: ghc panic with optimization.
by GHC 30 Jan '17

30 Jan '17

#13209: ghc panic with optimization. -------------------------------------+------------------------------------- Reporter: 1chb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: GHC rejects | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc eqFn && ./eqFn Works fine and the program runs fine too, but a bit slow. Adding optimization (-O) makes ghc panic (even after setting a bigger 'tick' factor): ghc -fsimpl-tick-factor=2000 -O eqFn && ./eqFn [1 of 1] Compiling Main ( eqFn.hs, eqFn.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for i386-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone f_XOO To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 700804 My program eqFn.hs: {{{ {-# LANGUAGE FlexibleInstances #-} instance Eq a => Eq (Bool -> a) where f == g = f True == g True && f False == g False nand a b = not (a && b) xor a b = nand (nand a c) (nand b c) where c=nand a b halfAdder a b = (xor a b, a && b) -- (sum, cOut) fullAdder cIn a b = let (s, c') = halfAdder a b (sum, c'') = halfAdder cIn s in (sum, c' || c'') adder2 cIn a0 b0 a1 b1 = let (o0, cTmp) = fullAdder cIn a0 b0 (o1, cOut) = fullAdder cTmp a1 b1 in (o0, o1, cOut) adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 = let (o0, o1, cTmp) = adder2 cIn a0 b0 a1 b1 (o2, o3, cOut) = adder2 cTmp a2 b2 a3 b3 in (o0, o1, o2, o3, cOut) adder8 cIn a0 b0 a1 b1 a2 b2 a3 b3 a4 b4 a5 b5 a6 b6 a7 b7 = let (o0, o1, o2, o3, cTmp) = adder4 cIn a0 b0 a1 b1 a2 b2 a3 b3 (o4, o5, o6, o7, cOut) = adder4 cTmp a4 b4 a5 b5 a6 b6 a7 b7 in (o0, o1, o2, o3, o4, o5, o6, o7, cOut) main = print (adder8 == adder8) }}} Btw, it works if I replace adder8 with adder4 in the last line. I think this is a bug because, if the problem is too complicated for the optimizer it should just skip that part instead of failing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13207: Performance regressions from removing LNE analysis
by GHC 30 Jan '17

30 Jan '17

#13207: Performance regressions from removing LNE analysis -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12988 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `CoreToStg`'s LNE analysis has been superseded by the occurrence analyzer's join-point analysis. However, there are a few cases where the occurrence analyzer doesn't find a join point where the old analysis would've found an LNE. Known causes include: 1. The LNE analysis was untyped, which (very) occasionally allows an LNE where a join point would've fallen afoul of the polymorphism rule (see Note [The polymorphism rule of join points] in `CoreSyn.hs`). 2. Sometimes a rewrite rule prevents a binding from being christened a join point; such a binding would've been found by the LNE analysis (which runs after Core Tidy has removed rules from local binders). The biggest loss in NoFib is `spectral/cryptarithm2`, which saw a 0.3% increase in allocations because a rule prevented detection of a join point. Specifically, there's a `go` that gets SpecConstr'd as an `$sgo`. All the calls to `$sgo` happen to be tail calls, but some calls to `go` aren't, so it's only the rule that keeps `$sgo` from becoming a join point. In summary (adapted from the `cryptarithm2` situation): {{{ letrec $sgo = \x y z -> ... go {- non-tail call -} ... {-# RULE "SPEC go" forall x y z. go ((x,y):z) = $sgo x y z #-} go = \xs -> ... go ... in ... go ... $sgo a b c {- tail call -} ... }}} The only thing keeping `$sgo` from becoming a join point is the rule. Possible solutions: 1. Run the occurrence analyzer after Core Tidy. Seems like the solution needing the least code. Problems: * Core Tidy turns top-level binders into `GlobalId`s. Would need to adapt the occurrence analyzer. * Would also need to run the simplifier, or at least `simpleOptPgm`, after Core Tidy, so one of those would also have to adapt. * Only covers case 2. 2. Write a new pass that just throws out all the rules from the local binders in the module, then run it (and then the simplifier) at the end of the Core-to-Core pipeline, just before Core Tidy. (Local rules don't appear in ifaces anyway.) * Needs a whole new traversal, albeit a very simple one. Though it's possible that dropping the rules would lead to other optimizations (`$sgo` would end up pre-inlined in the above example), so it might be helpful anyway. * Also only covers case 2. 3. Write the LNE analysis as an STG-to-STG pass. Only idea that covers both cases. * Needs even more code, and duplicative of the occurrence analyzer. 4. Loosen the join-point invariants somehow. For example, if we could flag a rule as applying only to tail calls, that rule could contain a jump in its RHS even though its LHS isn't a jump. * But this is already problematic in the above example—we also can't make `$sgo` a join point so long as it's mutually recursive with `go`, which it still is so long as the rule is there. In other words, even if the rule doesn't directly keep `$sgo` from being a join point, it's still the only thing keeping it from breaking free of `go`'s recursive group, which it must do to become a join point. * So it doesn't cover case 2 very well and it doesn't cover case 1 at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 29 Jan '17

29 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3044 Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * differential: Phab:3044 => Phab:D3044 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 29 Jan '17

29 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:3044 Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * differential: => Phab:3044 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 29 Jan '17

29 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: rwbarton Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by rwbarton): * owner: hvr => rwbarton -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation
by GHC 29 Jan '17

29 Jan '17

#7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+-------------------------------------- Reporter: Doug310 | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: gmp Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by rwbarton): Replying to [comment:53 rwbarton]: > Another suggestion is to add to the repo a big patch file that we apply to the untarred GMP 5.0.4 source to turn it into the GMP 6.1.2 source. (We apply some other patches after unpacking already.) I was unable to create such a patch smaller than 1MB compressed, even by importing the unpacked tarballs into git and creating a patch with `git format-patch -M -B -C -C -D`. So this doesn't seem like a promising approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7655#comment:54> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10420: "Care with plugin imports" is wrong / orphan RULE visibility
by GHC 29 Jan '17

29 Jan '17

#10420: "Care with plugin imports" is wrong / orphan RULE visibility -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A module loaded by a plugin poisons the module cache, so we never load an orphan RULE or instance even if we legitimately should do so. The way to test this is a bit convoluted, but it goes something like this: plugins07.hs {{{ module Main where import Plugins07a import RuleDefiningPlugin {-# NOINLINE x #-} x = "foo" main = putStrLn (show x) }}} Plugins07a.hs {{{ --{-# OPTIONS_GHC -fplugin RuleDefiningPlugin #-} module Plugins07a where }}} RuleDefiningPlugin.hs, in ANOTHER PACKAGE (otherwise, EPT rules don't apply) {{{ module RuleDefiningPlugin where import GhcPlugins {-# RULES "unsound" forall x. show x = "SHOWED" #-} plugin :: Plugin plugin = defaultPlugin }}} I'll commit the full test. Here's what happens: * Building `Plugins07a` results in `loadPluginInterface` on `RuleDefiningPlugin`. We load the `ModIface` but only add its types to the environment because of the "Care with plugin imports" special case. * Building `plugins07.hs` results in a normal source level import for `RuleDefiningPlugin`, but `ModIface` is already in the cache so we don't load anything. RULE is not loaded, disaster! Admittedly, actually triggering this bug requires a convoluted chain of events. But really this problem arose because the "Care with plugin imports" fix is just completely nonsense. Here's what we should do: * We should apply the same fix from #2182 on orphan instances to orphan rules too. This way, we can safely load RULEs into the EPS without accidentally bringing them into scope when they shouldn't be. * Loading an interface should unconditionally suck in the instances and rules. The result is more correct and simpler, so it seems worth fixing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10420> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13187: Strange debug output printed: isPredTy Const Int (, ) Bool Char
by GHC 28 Jan '17

28 Jan '17

#13187: Strange debug output printed: isPredTy Const Int (,) Bool Char -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed this when debugging an issue in `th-desugar`. If you have this file: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where type Const a b = b test36_expand = $([| let f :: Const Int (,) Bool Char -> Char f = snd in f |]) }}} And compile it on GHC HEAD with `-ddump-tc-trace` enabled, even if you redirect the output of `-ddump-tc-trace` to a file with `-ddump-to-file`, GHC will still print what appears to be debugging messages! {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs -ddump-to-file -fforce- recomp -ddump-tc-trace [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) isPredTy Const Int (,) Bool Char }}} The source of that `isPredTy` message is in `Type` ([http://git.haskell.org/ghc.git/blob/3eebd1f5fd56689baa63fcc63b7f4bde0ae70d0… here]): {{{#!hs go_k :: Kind -> [KindOrType] -> Bool -- True <=> ('k' applied to 'kts') = Constraint go_k k [] = isConstraintKind k go_k k (arg:args) = case piResultTy_maybe k arg of Just k' -> go_k k' args Nothing -> pprTrace "isPredTy" (ppr ty) False -- This last case should not happen; but it does if we -- we call isPredTy during kind checking, especially if -- there is actually a kind error. Example that showed -- this up: polykinds/T11399 }}} Several things stand out here: 1. Should we be using `pprTrace` this way? 2. Given that the comment says that "This last case should not happen", is this program indicative of a bug? Or perhaps this code really can be legitimately reached, and the comment should be updated to reflect this? FWIW, `polykinds/T11399` exhibits the same issue: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug2.hs -ddump-to-file -fforce- recomp -ddump-tc-trace [1 of 1] Compiling T11399 ( Bug2.hs, Bug2.o ) isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * isPredTy a_aCn[sk:1] * Bug2.hs:10:32: error: • Couldn't match kind ‘*’ with ‘GHC.Types.RuntimeRep’ When matching kinds a :: * -> * TYPE :: GHC.Types.RuntimeRep -> * Expected kind ‘* -> *’, but ‘UhOh a’ has kind ‘a * -> *’ • In the first argument of ‘Functor’, namely ‘(UhOh a)’ In the instance declaration for ‘Functor (UhOh a)’ | 10 | instance Functor a => Functor (UhOh a) where | ^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5