November 2014 - ghc-tickets

Re: [GHC] #7430: GHC API reports CPP errors in confusing ways
by GHC 24 Nov '14

24 Nov '14

#7430: GHC API reports CPP errors in confusing ways -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: GHC API | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Linux | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Confirmed with 7.8.3. Unfortunately the example doesn't compile with `ghc-7.9.20141121`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7430#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7437: peculiar behaviour with default instances and type variables
by GHC 24 Nov '14

24 Nov '14

#7437: peculiar behaviour with default instances and type variables -------------------------------------+------------------------------------- Reporter: bos | Owner: simonpj Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * component: Compiler => Compiler (Type checker) Comment: Uncommenting the `FlexibleInstances` pragma does not have an effect on the error message with ghc HEAD (or ghc-7.8.3), and the message also seems much improved: {{{ $ cat test.hs {-# LANGUAGE DefaultSignatures, FlexibleContexts, DeriveGeneric #-} {-# LANGUAGE FlexibleInstances #-} module Whee where ... $ ghc-7.9.20141121 test.hs [1 of 1] Compiling Whee ( test.hs, test.o ) test.hs:12:1: Could not deduce (Put a0) from the context (Put a, Generic t, GPut (Rep t)) bound by the type signature for put :: (Put a, Generic t, GPut (Rep t)) => t -> [()] at test.hs:(12,1)-(17,21) The type variable ‘a0’ is ambiguous In the ambiguity check for the type signature for ‘put’: put :: forall a. Put a => forall t. (Generic t, GPut (Rep t)) => t -> [()] To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: put :: a -> [()] In the class declaration for ‘Put’ }}} Does that means this issue is resolved? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7437#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile
by GHC 24 Nov '14

24 Nov '14

#7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile -------------------------------------+------------------------------------- Reporter: | Owner: orenbenkiki | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Profiling | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by orenbenkiki): Well... it has been a while since I submitted the original report and my code base has mutated and grown a lot since then. It is a pretty large project and contains information I can't release out of my company... The question seems to be why the generated code builds the linked list dynamically rather than as static initializers, this "should" be unrelated to the inputs... right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7443#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls
by GHC 24 Nov '14

24 Nov '14

#8031: Template Haskell gets confused with kind variables introduced in separate foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: PolyKinds Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: th/T8031 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T8031 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8031#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8044: "Inaccessible code" error reported in wrong place
by GHC 24 Nov '14

24 Nov '14

#8044: "Inaccessible code" error reported in wrong place -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: GADTs | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Here is my file `Bug.hs`: {{{ {-# LANGUAGE GADTs, TypeFamilies #-} module Bug where data X a where XInt :: X Int XBool :: X Bool XChar :: X Char type family Frob a where Frob Int = Int Frob x = Char frob :: X a -> X (Frob a) frob XInt = XInt frob _ = XChar }}} Compiling this file produces the error {{{ Bug.hs:15:6: Couldn't match type ‛Int’ with ‛Char’ Inaccessible code in a pattern with constructor XInt :: X Int, in an equation for ‛frob’ In the pattern: XInt In an equation for ‛frob’: frob XInt = XInt }}} The line/column number single out the pattern `XInt` in the first clause of the function `frob`. But, the real problem (as I see it), is the right- hand side of the ''second'' clause of `frob`. Indeed, when I comment out the second line of the function, the error goes away, even though it was reported on the first line. I do not believe that this error is caused by closed type families, per se, because I have run across it without them, just in code that was too hard to pare down enough to make a bug report out of. This was tested on 7.7.20130702. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7643: Kind application error
by GHC 24 Nov '14

24 Nov '14

#7643: Kind application error -------------------------------------+------------------------------------- Reporter: gmainland | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7354, #8355 None/Unknown | Test Case: | typecheck/should_compile/T7643 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_compile/T7643 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7643#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7643: Kind application error
by GHC 24 Nov '14

24 Nov '14

#7643: Kind application error -------------------------------------+------------------------------------- Reporter: gmainland | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7354, #8355 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"63d2adaef999258d874a760591e9c9ec3d75aeaf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="63d2adaef999258d874a760591e9c9ec3d75aeaf" Test #7643 in typecheck/should_compile/T7643. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7643#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8031: Template Haskell gets confused with kind variables introduced in separate foralls
by GHC 24 Nov '14

24 Nov '14

#8031: Template Haskell gets confused with kind variables introduced in separate foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.7 Haskell | Keywords: PolyKinds Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"5c3541548e441456ca6a0dd62caf8acd7fc5cf33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5c3541548e441456ca6a0dd62caf8acd7fc5cf33" Test #8031 in th/T8031 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8031#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile
by GHC 24 Nov '14

24 Nov '14

#7443: Generated C code under -prof -fprof-auto -fprof-cafs very slow to compile -------------------------------------+------------------------------------- Reporter: | Owner: orenbenkiki | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Profiling | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: I had a look at the files in the attached zip file. There is a `RUN` script with hard coded directory paths that don't exist on my system, two `.hscpp` that import a module called `Haski` that I can't find on hackage, and a giant `c` that is supposedly giving you troubles. As it stands, your problem is rather hard to reproduce. Could you please make a smaller, self-contained, example? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7443#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7460: Double literals generated bad core
by GHC 24 Nov '14

24 Nov '14

#7460: Double literals generated bad core -------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The word2Float and word2Double primops were added, which solved this issue. The output of `ghc-7.6.3 -ddump-simpl -O2 test.hs` contained calls to `doubleFromInteger`, but the same command using `ghc-7.8.3` does not (which is good). Other things must have changed as well, because the code is about twice as fast with 7.8.3, while comment:8 talked about a difference of only 20%. commit 2e8c769422740c001e0a247bfec61d4f78598582 {{{ Author: Johan Tibell <> Date: Wed Dec 5 19:08:48 2012 -0800 Implement word2Float# and word2Double# }}} commit cd01e48fbc548ff8d81ab547108bfdde8a113cd7 {{{ Author: Johan Tibell <> Date: Thu Dec 13 12:03:40 2012 -0800 Add test for word2Double# and word2Float# }}} commit a18cf9cbdfec08732f5b7e0c886a5d899a6a5998 {{{ Author: Johan Tibell <> Date: Thu Dec 13 14:49:58 2012 -0800 Add fromIntegral/Word->Double and fromIntegral/Word-Float rules }}} commit 8cd4ced57dccc1f4f54d242982209ec61e145700 {{{ Author: Johan Tibell <> Date: Tue Dec 18 14:40:02 2012 +0100 perf test for Word->Float/Double conversion }}} commit 6d5f25f5e0b33173fb2e7983cab40808c723f220 {{{ Author: Geoffrey Mainland <> Date: Thu Jan 3 16:59:03 2013 +0000 Fix LLVM code generated for word2Float# and word2Double#. }}} commit 744035fdd4b882c17ef7c6e4439b9e7099e7ec3d {{{ Author: Johan Tibell <> Date: Mon Jan 7 21:35:07 2013 -0800 Fix Word2Float# test on 32-bit }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7460#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0