July 2016 - ghc-tickets

[GHC] #12240: Common Sense for Type Classes
by GHC 14 Jul '16

14 Jul '16

#12240: Common Sense for Type Classes -------------------------------------+------------------------------------- Reporter: Mathnerd314 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- GHC erroneously reports that there is "No instance of C". But, in fact, there is an instance, `C Int Char`; furthermore, it is the only instance. So GHC should use it! {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module T4921 where class C a b where f :: (a,b) instance C Int Char where f = undefined x = fst f y = fst f :: Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 14 Jul '16

14 Jul '16

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Regarding syntax, could it use data constructor syntax with a magic module {{{#!hs import GHC.OrPatterns ( (:|:) ) -- ( pattern (:|:) ) ? f A = ... f B = ... f unexpected@(C{} :|: D{} :|: E{}) = pprTrace "f" (ppr unexpected) }}} like Edward's suggestion in Records/OverloadedRecordFields/OverloadedLabels {{{#!hs import GHC.ImplicitValues( p, q, area ) }}} ---- {{{#!hs import qualified GHC.OrPatterns as OR ( (:|:) ) f (C{} OR.:|: D{} OR.:|: E{}) = ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs
by GHC 13 Jul '16

13 Jul '16

#781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.5 (Linker) | Keywords: Resolution: | getEnvironment Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: | getEnvironment01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Possibly... I think I looked into it but couldn't find a way to do it, but that may have changed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/781#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs
by GHC 13 Jul '16

13 Jul '16

#781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.5 (Linker) | Keywords: Resolution: | getEnvironment Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: | getEnvironment01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Could the RTS linker distinguish code and data references the way the system dynamic linker does? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/781#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12385: Another case of type families not being reduced
by GHC 12 Jul '16

12 Jul '16

#12385: Another case of type families not being reduced -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Similar to #12381 and #11348 but this one doesn't pass with GHC HEAD either, {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, FlexibleInstances #-} import GHC.Types type family F (a :: Type) :: Type class C a where type D (a :: Type) :: F a instance (F a ~ Bool) => C a where type D a = True }}} fails with, {{{ Hi.hs:11:14: error: • Expected kind ‘F a’, but ‘'True’ has kind ‘Bool’ • In the type ‘True’ In the type instance declaration for ‘D’ In the instance declaration for ‘C a’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11835: ApplicativeDo failed to desugar last line with pure $ <expr>
by GHC 12 Jul '16

12 Jul '16

#11835: ApplicativeDo failed to desugar last line with pure $ <expr> -------------------------------------+------------------------------------- Reporter: Cosmia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: ApplicativeDo | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11607 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ApplicativeDo #-} f m = do x <- m 1 y <- m 2 return $ x + y }}} f should have type (Applicative f, Num a, Num b) => (a -> f b) -> f b but ghc considers f a monad maybe similar with #11607 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11835> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10647: Notice about lack of SIMD support.
by GHC 12 Jul '16

12 Jul '16

#10647: Notice about lack of SIMD support. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In some cases, when SIMD primitives are used without the `-fllvm` flag, instead of giving the friendly `SIMD vector instructions require the LLVM back-end.`, GHC crashes with varying messages. The simplest example is {{{#!hs {-# LANGUAGE MagicHash #-} module Foo where import GHC.Prim data V = V Int8X16# }}} In 7.8.4 this crashes with {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Size.intSize W128 }}} According to osa1, in HEAD this still crashes, but with {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150717 for x86_64-unknown-linux): Format.intFormat W128 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8308: Resurrect ticky code for counting constructor arity
by GHC 12 Jul '16

12 Jul '16

#8308: Resurrect ticky code for counting constructor arity ----------------------------------------------+---------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- There is a dead piece of ticky profiling code that computes histograms of data constructor arities (including tuples) and size of vector returns. The function responsible is `bumpHistogram` in [[GhcFile(compiler/codeGen/StgCmmTicky.hs)]], which masks the commented out function `bumpHistogramE`. We can improve ticky profiling by resurrecting this dead code. There are following things that need to be done: 1. Replace current no-op `bumpHistogram` with `bumpHistogramE`. Note that current implementation of `bumpHistogramE` computes constructor arity at runtime. This is unnecessary because we know arity at compile time so we can avoid runtime check by doing sth like this: {{{ bumpHistogram lbl n = do let offset = n `min` 8 emit (addToMem cLong (cmmIndexExpr cLongWidth (CmmLit (CmmLabel (mkRtsDataLabel lbl))) (CmmReg (CmmInt (fromIntegral offset) cLongWidth))) 1) }}} Note that `mkRtsDataLabel` function does not exist anymore but we should be able to replace that call with `mkCmmDataLabel rtsPackageId lbl` (speculation). 2. We need to declare arrays that will store histogram values. Declarations of variables used for storing ticky statistics are in [[GhcFile(includes/stg/Ticky.h)]]. We also need to initialize the declared array to contain only zeros. 3. Having declared the arrays we need to fix printing of computed arities. This is done in [[GhcFile(rts/Ticky.c)]]. Note that there is a lot of code that is commented out (`/* krc: comment out some of this stuff temporarily */`) or disabled with `#if FALSE` pragma. We need to resurect *some* of it. There is a `PR_HST` macro for printing one histogram entry. This seems bad. We should probably rework the part of code responsible for printing out results of historgams. 4. Current code counts arities from 0 to 8. Everything above 8 is put into the same bin as 8. This magical 8 is spread all over the code. We should declare a constant that is visible both in Haskell sources (see `bumpHistogram` in 1.) and RTS files and have all code behave properly depending on that constant - we should have loops instead of statically printing 9 elements of histogram array. 5. Some ticky functions that count arity histograms are not used. For example `tickyReturnNewCon` should probably be called by `cgConApp` like this: {{{ ; emit =<< fcode_init ; tickyReturnNewCon ; emitReturn [idInfoToAmode idinfo] } }}} The above is a an outline, which should be fairly accurate, but unexpected things may show up along the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12127: ghc-8.0.1: panic! (the 'impossible' happened) filterImports/combine (double import)
by GHC 12 Jul '16

12 Jul '16

#12127: ghc-8.0.1: panic! (the 'impossible' happened) filterImports/combine (double import) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- It's a distilled example or repa-devil-0.3.2.6 build failure: {{{#!hs -- Cursored.hs: {-# LANGUAGE TypeFamilies #-} module Cursored where class Source r where data Array r instance Source () where data Array () = F { f :: Int } }}} {{{#!hs -- Bug.hs: module DevIL () where import Cursored (Array(..), Source(..)) }}} {{{ [1 of 2] Compiling Cursored ( Cursored.hs, Cursored.o ) [2 of 2] Compiling DevIL ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): filterImports/combine (Array, Array{Array, F, f}, Nothing) (Array, Source{Source, Array}, Nothing) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The error is the same as #11959 but involved entities are slightly different. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11554: Self quantification in GADT data declarations
by GHC 12 Jul '16

12 Jul '16

#11554: Self quantification in GADT data declarations -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- GHC hangs on this (it was panicking on the same code before : [https://github.com/goldfirere/ghc/issues/56](https://github.com/goldfirere/… : {{{#!hs {-# LANGUAGE GADTs, TypeInType #-} import Data.Kind data A :: Type where B :: forall (a :: A). A }}} I guess the typechecker tries to infer the kind of A from the type of the constructors and hangs. Maybe recursive occurrences of a type as a kind in its constructors should only be allowed when its kind signature is specified and can be used to typecheck the constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14