July 2014 - ghc-tickets

[GHC] #9325: mod73 output file needs to be reordered
by GHC 31 Jul '14

31 Jul '14

#9325: mod73 output file needs to be reordered -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: mod73 | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Difficulty: Unknown Test Case: mod73 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- The correct output from the mod73 test needs to be reordered in HEAD: {{{ =====> mod73(normal) 1610 of 4044 [0, 0, 0] cd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c mod73.hs >mod73.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./module/mod73.stderr 2014-07-16 21:21:57.000000000 +0100 +++ ./module/mod73.comp.stderr 2014-07-17 20:15:54.000000000 +0100 @@ -2,6 +2,6 @@ mod73.hs:3:7: Not in scope: ‘Prelude.g’ Perhaps you meant one of these: - data constructor ‘Prelude.LT’ (imported from Prelude), + data constructor ‘Prelude.GT’ (imported from Prelude), data constructor ‘Prelude.EQ’ (imported from Prelude), - data constructor ‘Prelude.GT’ (imported from Prelude) + data constructor ‘Prelude.LT’ (imported from Prelude) *** unexpected failure for mod73(normal) Unexpected results from: TEST="mod73" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9325> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9380: ghc generates seemingly incorrect code
by GHC 31 Jul '14

31 Jul '14

#9380: ghc generates seemingly incorrect code -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- GHC generates a wrong code for the case-match on GADT with polymorphic type, here is a minimal example attached, expected results are 'A' in all test cases (this is case for ghc-HEAD), however in: test0 - result is missing as matches are removed from code (according to core) test1 - returns A as expected test2 - output 'o_O' without any checks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9387: LLVM backend: redundant code for functions calling themselves
by GHC 30 Jul '14

30 Jul '14

#9387: LLVM backend: redundant code for functions calling themselves -----------------------------------+--------------------------------------- Reporter: jmoy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------------+--------------------------------------- It seems that the LLVM backed does not recognize when a function calls itself. As a result it generates redundant load and store instructions. I am compiling the following simple recursive Fibonacci function {{{ fib::Int->Int fib n = loop n 0 1 where loop !n !a !b = if n==1 then a else loop (n-1) b (a+b) }}} I am attaching the files produced by {{{ ghc -c -O3 -fllvm -ddump-stg -ddump-cmm -ddump-llvm -ddump-to-file Fib.hs }}} I rename the generated LLVM file with a `.ll` extension and run `llc -O3` on it to generate the attached `.s` file (LLVM version 3.4.2). The actual work gets done in `Fib_zdwloop_info`. It begins as: {{{ Fib_zdwloop_info: # @Fib_zdwloop_info # BB#0: # %css pushq %rax movq %r13, (%rsp) movq %rbp, -8(%rsp) movq %r12, -16(%rsp) movq %rbx, -24(%rsp) movq %r14, -32(%rsp) movq %rsi, -40(%rsp) movq %rdi, -48(%rsp) movq %r8, -56(%rsp) movq %r9, -64(%rsp) movq %r15, -72(%rsp) movss %xmm1, -76(%rsp) movss %xmm2, -80(%rsp) movss %xmm3, -84(%rsp) movss %xmm4, -88(%rsp) movsd %xmm5, -96(%rsp) movsd %xmm6, -104(%rsp) }}} Later on when the function makes a recursive call to itself the code generated is {{{ movq -8(%rsp), %rbp movq -16(%rsp), %r12 movq -24(%rsp), %rbx movq -32(%rsp), %r14 movq -40(%rsp), %rsi movq -72(%rsp), %r15 popq %rax jmp Fib_zdwloop_info # TAILCALL }}} Given that the values are being loaded from the stack to the registers in the second excerpt, it is redundant to re-store the same values into the stack at the entry of the function. It seems to me that this is happening because LLVM uses a general function call instruction to translate a function calling itself. I was wondering if it is possible to recognize this special case in the LLVM backed or earlier so that instead of a function call we can translate this as the LLVM level as a jump to some point after the function entry. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #1620: ModBreaks.modBreaks_array not initialised
by GHC 30 Jul '14

30 Jul '14

#1620: ModBreaks.modBreaks_array not initialised -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * version: 7.8.3 => 7.8.2 * milestone: => 7.10.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1620#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1620: ModBreaks.modBreaks_array not initialised (was: Bug in debugger 6.7.20070817)
by GHC 30 Jul '14

30 Jul '14

#1620: ModBreaks.modBreaks_array not initialised -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * version: 6.7 => 7.8.3 * resolution: fixed => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1620#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8438: Validation failure compiling primitive-memops.c
by GHC 30 Jul '14

30 Jul '14

#8438: Validation failure compiling primitive-memops.c -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): So, did this go away, or what? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8438#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 29 Jul '14

29 Jul '14

#5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: (LLVM) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: rwbarton (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5567#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version
by GHC 29 Jul '14

29 Jul '14

#7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): @k.gadek for your use case, can't you do ` --ghc-options="-fasm"` ? Which accelerate package aside from accelerate-llvm (which is still prerelease quality last I checked) actually uses llvm? All the other (aside from the interpreted mode) do runtime compilation using the opencl/cuda ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7143#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9376: Recursive closed type families fails
by GHC 29 Jul '14

29 Jul '14

#9376: Recursive closed type families fails -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the following code, I am getting strange compiler errors that I suspect has to do with the recursive application of the OrdRec type family: {{{ import GHC.Prim import Data.Proxy import qualified Data.Set as Set type family OrdRec (f :: * -> *) a b :: Constraint where OrdRec f a (f b) = ( Ord a, Ord (f b), OrdRec f a b ) OrdRec f a b = ( Ord a, Ord b ) setmap :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b setmap f set = Set.map f set }}} GHC gives the error message: {{{ ClosedTypeFamilyRecursion.hs:11:16: Could not deduce (Ord b) arising from a use of ‘Set.map’ from the context (OrdRec Set.Set a b) bound by the type signature for setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b at ClosedTypeFamilyRecursion.hs:10:11-66 Possible fix: add (Ord b) to the context of the type signature for setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b In the expression: Set.map f set In an equation for ‘setmap’: setmap f set = Set.map f set Failed, modules loaded: none. }}} If we modify the OrdRec type family to remove the recursive application: {{{ type family OrdRec (f :: * -> *) a b :: Constraint where OrdRec f a (f b) = ( Ord a, Ord (f b) ) OrdRec f a b = ( Ord a, Ord b ) }}} Then GHC is able to compile the file fine. What's extra weird, though, is that ghci appears to be able to evaluate the recursive type family correctly. If we comment out the setmap function, then load into ghci, we can verify that the OrdRec type family is giving the correct Ord constraints: {{{ ghci> :t Proxy :: Proxy (OrdRec [] Int Float) Proxy :: Proxy (OrdRec [] Int Float) :: Proxy (Ord Int, Ord Float) ghci> :t :t Proxy :: Proxy (OrdRec [] Int [Float]) Proxy :: Proxy (OrdRec [] Int [Float]) :: Proxy (Ord Int, Ord [Float], (Ord Int, Ord Float)) ghci> :t Proxy :: Proxy (OrdRec [] Int [[Float]]) Proxy :: Proxy (OrdRec [] Int [[Float]]) :: Proxy (Ord Int, Ord [[Float]], (Ord Int, Ord [Float], (Ord Int, Ord Float))) }}} But if I try to define the setmap function interactively in ghci, I get the same error message: {{{ ghci> > let setmap = (\f set -> Set.map f set) :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b <interactive>:39:25: Could not deduce (Ord b1) arising from a use of ‘Set.map’ from the context (OrdRec Set.Set a b) bound by the inferred type of setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b at <interactive>:39:5-98 or from (OrdRec Set.Set a1 b1) bound by an expression type signature: (OrdRec Set.Set a1 b1) => (a1 -> b1) -> Set.Set a1 -> Set.Set b1 at <interactive>:39:14-98 Possible fix: add (Ord b1) to the context of an expression type signature: (OrdRec Set.Set a1 b1) => (a1 -> b1) -> Set.Set a1 -> Set.Set b1 or the inferred type of setmap :: (OrdRec Set.Set a b) => (a -> b) -> Set.Set a -> Set.Set b In the expression: Set.map f set In the expression: (\ f set -> Set.map f set) :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b In an equation for ‘setmap’: setmap = (\ f set -> Set.map f set) :: OrdRec Set.Set a b => (a -> b) -> Set.Set a -> Set.Set b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9376> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version
by GHC 29 Jul '14

29 Jul '14

#7143: ghc-7.6.0.20120810-x86_64-windows.exe -> ghc can't figure out LLVM version -------------------------------------+------------------------------------- Reporter: cetinsert | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.1-rc1 (LLVM) | Keywords: llvm Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by k.gadek): For the record: I reinstalled LLVM on my system using ''brew'' with additional flags (notably ''--with-clang'') and now it all appears to work. Anyway, OS X by default is not able to build anything with `-fllvm` so despite the blame on Apple for doing this weird LLVM-mockery, I think this should be anticipated in some way; at least some note around download section, or – even better – give more meaningful error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7143#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0