September 2016 - ghc-tickets

[GHC] #12642: reports incorrect target arch on mips64el
by GHC 30 Sep '16

30 Sep '16

#12642: reports incorrect target arch on mips64el -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: mips | Type of failure: Debugging | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Please handle "mips64el" in GHC_CONVERT_CPU and FPTOOLS_SET_HASKELL_PLATFORM_VARS. Having "ArchMipseb" show up in ghc --info output is confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns
by GHC 29 Sep '16

29 Sep '16

#12641: Indentation works differently for multi-way if than for guards when using comma-separate view patterns -------------------------------------+------------------------------------- Reporter: ahmadsalim | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to parse the following piece of code: {{{#!hs {-# LANGUAGE MultiWayIf #-} module Test where data AB = A | B aAndB :: AB -> AB -> Bool aAndB ab1 ab2 = if | A <- ab1 , B <- ab2 -> True | otherwise -> False }}} I get the following error {{{ test.hs:9:6: error: parse error (possibly incorrect indentation or mismatched brackets) }}} This is as currently is inconsistent with how guards are parsed, e.g.: {{{#!hs aAndB2 :: AB -> AB -> Bool aAndB2 ab1 ab2 | A <- ab1 , B <- ab2 = True | otherwise = False }}} works perfectly fine. Note, that if I indent the comma a bit in aAndB, the following will parse correctly: {{{#!hs aAndB :: AB -> AB -> Bool aAndB ab1 ab2 = if | A <- ab1 , B <- ab2 -> True | otherwise -> False }}} Of course, this is far from a major issue, but I thought it would probably be beneficial to report the issue nonetheless. It also looks likely less neat with the comma indented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12641> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12634: Panic with piResultTys1
by GHC 29 Sep '16

29 Sep '16

#12634: Panic with piResultTys1 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} twacePowDec :: t m' r -> t m r twacePowDec = undefined data Bench a bench :: (a -> b) -> a -> Bench params bench f = undefined bench_twacePow :: forall t m m' r . _ => t m' r -> Bench '(t,m,m',r) bench_twacePow = bench (twacePowDec :: t m' r -> t m r) }}} produces (in GHCi): {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:13:58: error: • Expected a type, but ‘'(t, m, m', r)’ has kind ‘(k1 -> k2 -> *, k0, k1, k2)’ • In the first argument of ‘Bench’, namely ‘'(t, m, m', r)’ In the type ‘t m' r -> Bench '(t, m, m', r)’ Bug.hs:14:52: error: • Expected kind ‘k1’, but ‘m’ has kind ‘k0’ • In the first argument of ‘t’, namely ‘m’ In an expression type signature: t m' r -> t m r In the first argument of ‘bench’, namely ‘(twacePowDec :: t m' r -> t m r)’ • Relevant bindings includeghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): piResultTys1 k_a18K[tau:3] [m'_a17U[sk], r_a17V[sk]] }}} The intent was to use this code with `-XPartialTypeSignatures`, but the bug occurs with or without that extension. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12640: Class member functions not substituted for MultiParamTypeClasses
by GHC 29 Sep '16

29 Sep '16

#12640: Class member functions not substituted for MultiParamTypeClasses -------------------------------------+------------------------------------- Reporter: jeremy-list | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- When the following code is compiled with "-O2 -ddump-rule-firings" the rule is not fired: presumably because the simplifier does not recognize that (+++) = ex_or. {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} class Ex2 a b c | a b -> c where (+++) :: a -> b -> c instance Ex2 Bool Bool Bool where (+++) = ex_or {-# INLINE [2] ex_or #-} ex_or = (||) {-# RULES "force-inline" forall a b . ex_or a b = a || b #-} main = print (True +++ True) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9520: Running an action twice uses much more memory than running it once
by GHC 29 Sep '16

29 Sep '16

#9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a [http://www.haskell.org/pipermail/haskell- cafe/2014-August/115751.html Haskell cafe discussion] about conduit. This may be related to #7206, but I can't be certain. It's possible that GHC is not doing anything wrong here, but I can't see a way that the code in question is misbehaving to trigger this memory usage. Consider the following code, which depends on conduit-1.1.7 and conduit- extra: {{{#!hs import Data.Conduit ( Sink, (=$), ($$), await ) import qualified Data.Conduit.Binary as CB import System.IO (withBinaryFile, IOMode (ReadMode)) main :: IO () main = do action "random.gz" --action "random.gz" action :: FilePath -> IO () action filePath = withBinaryFile filePath ReadMode $ \h -> do _ <- CB.sourceHandle h $$ CB.lines =$ sink2 1 return () sink2 :: (Monad m) => Int -> Sink a m Int sink2 state = do maybeToken <- await case maybeToken of Nothing -> return state Just _ -> sink2 $! state + 1 }}} The code should open up the file "random.gz" (I simply `gzip`ed about 10MB of data from /dev/urandom), break it into chunks at each newline character, and then count the number of lines. When I run it as-is, it uses 53KB of memory, which seems reasonable. However, if I uncomment the second call to `action` in `main`, maximum residency shoots up to 45MB (this seems to be linear in the size of the input file. I additionally tried copying `random.gz` into two files, `random1.gz` and `random2.gz`, and changed the two calls to `action` to use different file names. It still resulted in large memory usage. I'm going to continue working to make this a smaller reproducing test case, but I wanted to start with what I had so far. I'll also attach the core generated by both the low-memory and high-memory versions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9349: excessive inlining with -fpre-inlining
by GHC 29 Sep '16

29 Sep '16

#9349: excessive inlining with -fpre-inlining --------------------------------------------+------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Differential: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ The program at https://gist.github.com/jorendorff/a3005968adc8f054baf7 runs very slowly when compiled with `-O` or higher. It seems that `arr` and/or `rangeMap` is being inlined into the do block on lines 89-91 and recomputed for each iteration of the loop. The program runs nearly instantly when compiled with `-O0` or with `-O -fno-pre-inlining`. (Of course, this does not mean `-fpre-inlining` is necessary the culprit; it could be enabling some subsequent misoptimization.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9349> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12632: Inline and Noinline pragmas ignored for instance functions
by GHC 29 Sep '16

29 Sep '16

#12632: Inline and Noinline pragmas ignored for instance functions -------------------------------------+------------------------------------- Reporter: jeremy-list | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An example source file which triggers the incorrect behaviour follows. I am currently unclear whether the effected inline and noinline pragmas are actually ignored by the simplifier or whether the inline rule shadowing warning is fired incorrectly. {{{#!hs class A a where (>>#) :: a -> a -> a instance A (Maybe a) where {-# NOINLINE (>>#) #-} a >># b = undefined {-# RULES "example" forall (a :: Maybe Int) (b :: Maybe Int) . a >># b = Just 4 #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12632> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12638: GHC panic when resolving Show instance
by GHC 28 Sep '16

28 Sep '16

#12638: GHC panic when resolving Show instance -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: PolyKinds, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm playing around with rolling my own type defaulting and found a panic. Note: adding a stub `Show (W a)` instance resolves this (i.e. `show _ = "test"`). {{{ {- Test.hs -} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Test where import Data.Proxy data W (a :: k) = Wk | W (MkStar a) type family MkStar (a :: k) :: * main = print (W Proxy :: W (Proxy (~))) }}} {{{ $ ghc Test.hs -o test [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:13:8: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): print_equality ~ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If `x = W Proxy :: W (Proxy (~))` is only defined, there is no issue. It seems to occur exactly when resolving a `Show` instance for `W (Proxy (~))` and one does not exist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12626: Remove redundant type applications in Core
by GHC 28 Sep '16

28 Sep '16

#12626: Remove redundant type applications in Core -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This ticket is a fork for #12618, which proposes to add saturated data constructor applications to Core with the purpose of omitting redundant type applications (think `(,)`), and explores generalizing the idea to any application. Below are my comments to that ticket, which I delete there, to make it less noisy (I got excited on the travel back from ICFP and spammed it too much). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12635: Compress core in interface files
by GHC 28 Sep '16

28 Sep '16

#12635: Compress core in interface files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: -------------------------------------+------------------------------------- Inspired by #12626 and #12618, the idea came up of storing less stuff about Core expressions in interface files if we can infer it while reading it. For example, in the unfolding of an function `Int -> Int`, which might look like `\x::Int → ...`, the type annotation of the variable is obviously redundant. This avenue should be explored more. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0