- ghc-tickets - Haskell.org

[GHC] #9700: Support C structures in Haskell FFI
by GHC 22 May '17

22 May '17

#9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D252 -------------------------------------+------------------------------------- This ticket is for tracking progress on [[CStructures]] language extension proposal. The idea is to support C structures in Haskell FFI. See wiki for details. If it will be accepted, I'm going to implement it in few steps. The first one is to support structures as return value. Platform specific part for that is already implemented, see Phab:D252 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13741: Newtype unwrapping causes GHC panic
by GHC 22 May '17

22 May '17

#13741: Newtype unwrapping causes GHC panic -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: newtype ghci | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some combination of newtypes and infix operators is causing GHCi to panic. Steps to reproduce: 1. Open a fresh GHCi session. 2. Define `Cont`: `newtype Cont a r = Cont {(>>-) :: (a -> r) -> r}` 3. Define a `Functor` instance for `Cont`: `instance Functor (Cont r) where fmap f c = Cont $ \k -> c >>>- f . k` 4. Observe the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get_op >>>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13740: GHC panic with operator constructor of newtype
by GHC 22 May '17

22 May '17

#13740: GHC panic with operator constructor of newtype -------------------------------------+------------------------------------- Reporter: codebje | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code causes a GHC panic: {{{ newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- a . b }}} This slight modification, however, is fine: {{{ newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- (a . b) }}} The presence or absence of a type signature for `x` makes no difference. Compiling with "-v" suggests the panic occurs during type checking: {{{ Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 7.10.3 Using binary package database: /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d/package.cache Using binary package database: /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache Using binary package database: /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb loading package database /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb loading package database /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *panic.hs !!! Chasing dependencies: finished in 0.57 milliseconds, allocated 0.224 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-05-22 07:07:41 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file panic.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( panic.hs, panic.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.38 milliseconds, allocated 0.209 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): get_op >>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13728: Clarify the difference between NameL and NameU in Template Haskell
by GHC 22 May '17

22 May '17

#13728: Clarify the difference between NameL and NameU in Template Haskell -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reading the docs in Language.Haskell.TH.Syntax, I got the impression that when reifying the type {{{#!hs data P a b = P a b }}} defined outside of TH, the type variables a and b will be NameLs; but in my experiments, they come out as NameUs. Are NameLs used anywhere at all? In any case, I think the docs should be updated to explain the difference clearly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing.
by GHC 21 May '17

21 May '17

#11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: | Operating System: Unknown/Multiple yhjulwwiefzojcbxybbruweejw | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the documentation on newName: "Although names generated by newName cannot ''be captured'', they can ''capture'' other names." We recently ran into a case where we'd really have liked a way to create a name which can't interact at all with other names in the code, apart from where it is used in the construction of the TH expression. In this code: https://github.com/reflex-frp/reflex/blob/develop/src/Reflex/Dynamic/TH.hs The `newName "dynamicQuotedExpressionVariable"` used to be simply `newName "dyn"`, and we ended up having occurrences of `dyn` in the quasiquoted expressions (which would be constructed by NameG) get captured by that newName rather than referring to reflex-dom's definition of `dyn`. There ought to be some Q Name action which can be executed to give fresh names which can be used internally by a TH macro without fear that they can be referred to in any way other than using the Name value obtained from the action. The documentation for `Name` seems to suggest that newName is presently the closest thing, so perhaps we need a new primitive for creating totally-non-interacting Names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13736: GHC panic with DataKinds and TypeOperators
by GHC 21 May '17

21 May '17

#13736: GHC panic with DataKinds and TypeOperators -------------------------------------+------------------------------------- Reporter: turion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- The following program causes a GHC panic: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} import GHC.TypeLits data Proxy (n :: Nat) = Proxy data Foo a = Foo a foo :: Foo (Proxy (2 * 2)) foo = Foo _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8048: Register spilling produces ineffecient/highly contending code
by GHC 21 May '17

21 May '17

#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: register | Operating System: Unknown/Multiple allocator spill | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The native codegen and llvm both produce ineffecient code for functions using structures with many strict fields or unboxed values. Consider the following program: {{{ {-# LANGUAGE BangPatterns #-} module Spill where import GHC.Exts data S = S !Int !Int !Int !Int !Int !Int !Int !Int !Int spill :: S -> S -> S -> S spill (S !a !b !c !d !e !f !g !h !i) (S !j !k !l !m !n !o !p !q !r) (S !s !t !u !v !w !x !y !z _) = S (a + j + s) (b + c) (k + r) (a + b + c + d + e + f + g + h + i) (j + k + l + m + n + o + p + q + r) (s + t + u + v + w + x + y + z) (a + b + c) (j + k + l) (s + t + u) }}} Parts of the code produced for this (which is identical regardless of -funbox-strict-fields) looks like: {{{ _cnc: addq $80,%r12 cmpq 144(%r13),%r12 ja _cni movq $Spill.S_con_info,-72(%r12) movq 32(%rbp),%rax movq %rax,-64(%r12) movq 24(%rbp),%rax movq %rax,-56(%r12) movq 16(%rbp),%rax movq %rax,-48(%r12) movq 8(%rbp),%rax movq %rax,-40(%r12) movq 40(%rbp),%rax movq %rax,-32(%r12) movq 48(%rbp),%rax movq %rax,-24(%r12) movq 56(%rbp),%rax movq %rax,-16(%r12) movq 64(%rbp),%rax movq %rax,-8(%r12) movq 7(%rbx),%rax movq %rax,0(%r12) leaq -71(%r12),%rbx addq $72,%rbp jmp *0(%rbp) }}} {{{ _csv: movq 63(%rbx),%rax movq %rax,-56(%rbp) movq 55(%rbx),%rax movq %rax,-48(%rbp) movq 47(%rbx),%rax movq %rax,-40(%rbp) movq 39(%rbx),%rax movq %rax,-32(%rbp) movq 31(%rbx),%rax movq %rax,-24(%rbp) movq 23(%rbx),%rax movq %rax,-16(%rbp) movq 71(%rbx),%rax movq %rax,-8(%rbp) movq 15(%rbx),%rax movq %rax,0(%rbp) }}} And likewise for LLVM: {{{ .LBB10_1: # %coZ movq 7(%rbx), %rcx movq $Spill_S_con_info, 8(%rax) movq 8(%rbp), %rdx movq %rdx, 16(%rax) movq 16(%rbp), %rdx movq %rdx, 24(%rax) movq 24(%rbp), %rdx movq %rdx, 32(%rax) movq 32(%rbp), %rdx movq %rdx, 40(%rax) movq 40(%rbp), %rdx movq %rdx, 48(%rax) movq 48(%rbp), %rdx movq %rdx, 56(%rax) movq 56(%rbp), %rdx movq %rdx, 64(%rax) movq 64(%rbp), %rdx movq %rdx, 72(%rax) movq %rcx, (%r12) movq 72(%rbp), %rax leaq 72(%rbp), %rbp leaq -71(%r12), %rbx jmpq *%rax # TAILCALL }}} Quoting from #ghc "the [register allocator] core algo is '96 vintage". Improvements are needed; * Take into consideration pipelining and handle spills less dramatically, attempting to reduce register contention * Sink memory reads in order to reduce register pressure -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ...
by GHC 21 May '17

21 May '17

#13662: Type inference fails in connection with TypeFamilies, 'let', type equalities ... -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 (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: -------------------------------------+------------------------------------- The following example is a pretty involved use of type equality. It was accepted by GHC-8.0 and before, but GHC-8.2.0.20170505 cannot infer a type. {{{ $ cat MonomorphismEquality.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} module MonomorphismEquality (run) where newtype Value a = Value a type family Repr (f :: * -> *) a :: * type instance Repr f Int = f Int class (Repr Value i ~ Value ir) => Native i ir where instance Native Int Int where fromInt :: (Native i ir) => i -> a fromInt = undefined apply :: (Int -> a -> a) -> a -> a apply weight = id run :: Float -> Float run = let weight = \clip v -> fromInt clip * v in apply weight $ ghc-8.0.2 -Wall MonomorphismEquality.hs [1 of 1] Compiling MonomorphismEquality ( MonomorphismEquality.hs, MonomorphismEquality.o ) MonomorphismEquality.hs:6:19: warning: [-Wunused-top-binds] Defined but not used: data constructor ‘Value’ MonomorphismEquality.hs:20:7: warning: [-Wunused-matches] Defined but not used: ‘weight’ $ ghc-8.2.0.20170505 -Wall MonomorphismEquality.hs [1 of 1] Compiling MonomorphismEquality ( MonomorphismEquality.hs, MonomorphismEquality.o ) MonomorphismEquality.hs:24:28: error: • Ambiguous type variable ‘ir0’ arising from a use of ‘fromInt’ prevents the constraint ‘(Native Int ir0)’ from being solved. Probable fix: use a type annotation to specify what ‘ir0’ should be. These potential instance exist: instance Native Int Int -- Defined at MonomorphismEquality.hs:13:10 • In the first argument of ‘(*)’, namely ‘fromInt clip’ In the expression: fromInt clip * v In the expression: \ clip v -> fromInt clip * v | 24 | let weight = \clip v -> fromInt clip * v | ^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #8025: -fno-code and Template Haskell are incompatible
by GHC 20 May '17

20 May '17

#8025: -fno-code and Template Haskell are incompatible -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3441 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * differential: => Phab:D3441 * resolution: => fixed * milestone: => 8.4.1 Comment: Thanks Duog! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13699: Pretty printing: Strict record fields are not parenthesized properly
by GHC 20 May '17

20 May '17

#13699: Pretty printing: Strict record fields are not parenthesized properly -------------------------------------+------------------------------------- Reporter: zyla | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Keywords: pretty-print | Operating System: Unknown/Multiple bang record | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I type in GHCi: {{{ λ> data Foo = Foo { x :: !(Maybe Int) } λ> :i Foo data Foo = Foo {x :: !Maybe Int} -- Defined at <interactive>:71:1 }}} But this is not legal Haskell syntax: {{{ λ> data Foo = Foo {x :: !Maybe Int} <interactive>:73:22: error: • Unexpected strictness annotation: !Maybe • In the type ‘!Maybe Int’ In the definition of data constructor ‘Foo’ In the data declaration for ‘Foo’ }}} I think it should be pretty printed with parens: {{{ λ> :i Foo data Foo = Foo {x :: !(Maybe Int)} -- Defined at <interactive>:71:1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3