August 2015 - ghc-tickets

Re: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC
by GHC 10 Aug '15

10 Aug '15

#1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: I'm slowly reverting this work. There's no point in pretending GHC can still be compiled by other compilers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1405#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10758: the 'impossible' happened
by GHC 09 Aug '15

09 Aug '15

#10758: the 'impossible' happened -------------------------------------------+------------------------------- Reporter: martinmr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- I was working on solving problems 64 and 65 of the Euler project. When I was working on problem 64 I was able to load the file into ghci. I finished the problem and moved on to problem 65. When I tried to load 65.hs in ghci I got ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<6>() Same thing happened when I tried to load 64.hs (which used to work fine) and a number of other files from problems I had previously solved. Not all files trigger this issue and I have not changed ghc or cabal at all apart from installing the arithmoi and parallel packages. I am attaching my code for problems 64 and 65 in case my code is somehow triggering the bug (you can look at the problem statement at https://projecteuler.net/problem=64 and https://projecteuler.net/problem=65) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances
by GHC 08 Aug '15

08 Aug '15

#8178: Need TypeRep for Symbol and numeric type literals; and Typeable instances ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Nicolas Trangez points out that we don't have a `TypeRep` for types involving literal strings or numerics. E.g. what is `(typeRep (undefined :: Proxy "foo"))`? Here is Nicolas's example: {{{ {-# LANGUAGE DataKinds, KindSignatures, DeriveFunctor, DeriveDataTypeable #-} module Main where import Data.Typeable import GHC.TypeLits data NoSymbol n a b = NoSymbol a b deriving (Typeable) data WithSymbol (n :: Symbol) a b = WithSymbol a b deriving (Typeable) data Sym deriving (Typeable) main :: IO () main = do print $ typeOf (undefined :: NoSymbol Sym Int Int) let d = undefined :: WithSymbol "sym" Int Int {- print $ typeOf d No instance for (Typeable Symbol "sym") arising from a use of ‛typeOf’ -} return () }}} Just as types contain literal strings and natural numbers, so too must `TypeRep`, in some way. Once we have a suitable `TypeRep` we can make built-in instance for `Typeable` that return the appropriate representation. At the moment we have (in `Data.Typeable.Internals`): {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} with instances for Eq and Ord. Perhaps we need {{{ data TypeRep = TcApp {-# UNPACK #-} !Fingerprint TyCon [TypeRep] | TcSym String | TcNat Integer }}} or something like that? I'm not certain. I think Iavor is going to think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 08 Aug '15

08 Aug '15

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: Incorrect result at runtime => Runtime performance bug Comment: Since RULES are usually (always?) defined for performance reasons, I'm grouping this with all other [https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Runtime+perfo… runtime performance bugs]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7374: rule not firing
by GHC 08 Aug '15

08 Aug '15

#7374: rule not firing -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7374#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9853: Stateful transformation causes non-termination in Hoopl analysis.
by GHC 08 Aug '15

08 Aug '15

#9853: Stateful transformation causes non-termination in Hoopl analysis. -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It seems that Hoopl's analyses may apply rewrites to nodes multiple times without invoking the `restart` function between applications. This causes havoc for code transformations that have side-effects, for example a transformation that introduces a new variable to hold some intermediate result. In such an analysis, a transformation may introduce a new variable, which leads to a changed fact. Later the transformation may be run again, leading to a new fact, and so on (when there is a loop in the control flow. The attached example illustrates this problem. This example modifies the constant propagation pass provided in the testing directory of the hoopl library. The example added a new instruction called "Funny" that gets rewritten to an unconditional branch instruction and introduces a new variable. The main program P1 performs the analysis on a particular program that has a loop in the control flow graph and causes the hoopl analysis to run forever. Is this a bug in Hoopl? Ie. should analyses that have side-effects involving checkpointed state be supported? If not, could it be changed to support these analyses? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10540: Showing type synonym isn't exported by Hoopl
by GHC 08 Aug '15

08 Aug '15

#10540: Showing type synonym isn't exported by Hoopl -------------------------------------+------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/hoopl | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: | warning at compile-time Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hoopl exports {{{#!hs showGraph :: Showing n -> Graph n e x -> String }}} But it doesn't export `Showing`. This doesn't make sense, as it's a user- supplied function. So to know what I should pass to `showGraph` I can only look at the source. `:i Showing` doesn't work. Below is a patch to export the innocent type synonym: {{{#!patch diff --git a/src/Compiler/Hoopl/Show.hs b/src/Compiler/Hoopl/Show.hs index 8a8b35f..66172b0 100644 --- a/src/Compiler/Hoopl/Show.hs +++ b/src/Compiler/Hoopl/Show.hs @@ -4,7 +4,7 @@ #endif module Compiler.Hoopl.Show - ( showGraph, showFactBase + ( showGraph, showFactBase, Showing ) where }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10540> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10757: ghci panic: floatExpr tick break<1062>()
by GHC 08 Aug '15

08 Aug '15

#10757: ghci panic: floatExpr tick break<1062>() -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: panic ghci | Operating System: Unknown/Multiple optimisation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Loading a file with {-# OPTIONS -O #-} in ghci causes a panic. See details below. $ cat panic.hs {-# OPTIONS -O #-} main :: IO () main = return () $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :load panic.hs [1 of 1] Compiling Main ( panic.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5296: Add explicit type applications
by GHC 07 Aug '15

07 Aug '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:18 simonpj]: > Can I tell, in GHCi, whether a particular function (perhaps in scope by being imported) is amenably to VTA? Perhaps `:info f` tells me? No. But there should be. `:info` would be easy to modify. But I think `:type` should indicate this as well somehow. > > For (2) I suggest just saying `(3 :: Int)`. There are more exciting things to do than allow "@" in place of "::". Yes, I suppose that's true. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 07 Aug '15

07 Aug '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: Related Tickets: | Differential Revisions: Phab:D1138 -------------------------------------+------------------------------------- Comment (by simonpj): Can I tell, in GHCi, whether a particular function (perhaps in scope by being imported) is amenably to VTA? Perhaps `:info f` tells me? For (2) I suggest just saying `(3 :: Int)`. There are more exciting things to do than allow "@" in place of "::". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0