September 2015 - ghc-tickets

[GHC] #10568: Loading GLUT into GHCI fails on the Mac, probably a regression
by GHC 29 Sep '15

29 Sep '15

#10568: Loading GLUT into GHCI fails on the Mac, probably a regression -----------------------------------------+------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- ghci -V The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 ghci -package GLUT GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help <command line>: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib Expected in: flat namespace in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) This may be related to the fix for #10322. The GLUT people are aware of this. They believe it is platform scpecific, a regression and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 49

Re: [GHC] #7275: Give more detailed information about PINNED data in a heap profile
by GHC 29 Sep '15

29 Sep '15

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Profiling -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7275: Give more detailed information about PINNED data in a heap profile
by GHC 29 Sep '15

29 Sep '15

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * component: Profiling => Compiler Comment: We discussed this during this week's GHC meeting. Simon Marlow confirmed that Ian's suggestion would likely be feasible given a few days of effort. There is, however, the possibility that we would need to be more careful about zeroing out slots that we might accidentally dereference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7275: Give more detailed information about PINNED data in a heap profile
by GHC 29 Sep '15

29 Sep '15

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling Comment: Also reported as #10455. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS
by GHC 29 Sep '15

29 Sep '15

#10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using ghc's heap profiling, some allocations are treated specially in such a way that we get no useful information for them. * For +RTS -hc "cost centre stack", the allocations are classed as PINNED, which means we cannot see which cost centre allocated them. * For +RTS -hm "module", the allocations are classed as SYSTEM, which means we cannot see which module allocated them. * For +RTS -hy "type description" and +RTS -hd "closure description", the allocations are classed as ARR_WORDS, which means we cannot see what type they are (ByteArray#?). So none of these modes help us see what these allocations are or where they come from. Do these allocations have to be treated in this special way such that we loose all useful information? Presumably they are pinned ByteArray#s, but surely we can still track which cost centre to assign them to, and hence the module, and shouldn't the type/closure description be "ByteArray#" or "pinned ByteArray#" or something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10891: `reify` doesn't find associated type families
by GHC 29 Sep '15

29 Sep '15

#10891: `reify` doesn't find associated type families -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: template | Operating System: Unknown/Multiple haskell; type families | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Template Haskell's `reify` doesn't find the the associated type families of a type class. Consider the following two classes: {{{#!hs class C a where f :: a -> Int class C' a where type F a :: * f' :: a -> Int }}} These produce identical, up to renaming, output when passed to `reify`: {{{#!hs -- putStrLn $(stringE . show =<< reify ''C) ClassI (ClassD [] Ghci1.C [PlainTV a_1627398388] [] [SigD Ghci1.f (ForallT [PlainTV a_1627398388] [ClassP Ghci1.C [VarT a_1627398388]] (AppT (AppT ArrowT (VarT a_1627398388)) (ConT GHC.Types.Int)))]) [] -- putStrLn $(stringE . show =<< reify ''C') ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] [SigD Ghci3.f' (ForallT [PlainTV a_1627405973] [ClassP Ghci3.C' [VarT a_1627405973]] (AppT (AppT ArrowT (VarT a_1627405973)) (ConT GHC.Types.Int)))]) [] }}} If I know the name of `F`, I can look up information about it: {{{!#hs -- putStrLn $(stringE . show =<< reify ''F) FamilyI (FamilyD TypeFam Ghci3.F [PlainTV a_1627405973] (Just StarT)) [] }}} But I can't find the name of `F` in the first place. Even if I add an instance of the type class, the `InstanceD` has none of the information about the definition. Given {{{#!hs instance C' [a] where type F [a] = a f' = length }}} we get {{{#!hs -- putStrLn $(stringE . show =<< reify ''C') ClassI (ClassD [] Ghci3.C' [PlainTV a_1627405973] [] [SigD Ghci3.f' (ForallT [PlainTV a_1627405973] [ClassP Ghci3.C' [VarT a_1627405973]] (AppT (AppT ArrowT (VarT a_1627405973)) (ConT GHC.Types.Int)))]) [InstanceD [] (AppT (ConT Ghci3.C') (AppT ListT (VarT a_1627406161))) []] }}} This problem was confirmed to exist in the following configurations: * GHC 7.10.2 with version 2.10.0.0 of the template-haskell package. * GHC 7.8.3 with version 2.9.0.0 of the template-haskell package. * GHC 7.4.2 with version 2.7.0.0 of the template-haskell package. (I also posted this on Stack Overflow in //2013//, where it has been languishing ever since: http://stackoverflow.com/q/17247880/237428.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10891> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set.
by GHC 29 Sep '15

29 Sep '15

#10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X PartialTypeSignatures TypedHoles | Architecture: x86_64 | Type of failure: Incorrect (amd64) | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Maybe this should be one bug report and one feature request, but for now, I'll report them together. Consider the following program: {{{#!hs {-#LANGUAGE PartialTypeSignatures #-} {-#LANGUAGE NamedWildCards #-} {-#LANGUAGE NoMonomorphismRestriction #-} foo :: _ => _outer foo x = round $ (undefined::_inner) (1 + x) }}} This produces the following output in GHCi: {{{ Foo.hs:5:8: Warning: Found hole ‘_’ with inferred constraints: (Integral b, Num a) In the type signature for ‘foo’: _ => _outer Foo.hs:5:13: Warning: Found hole ‘_outer’ with type: a -> b Where: ‘b’ is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 ‘a’ is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 In the type signature for ‘foo’: _ => _outer Foo.hs:6:29: Warning: Found hole ‘_inner’ with type: a -> Double Where: ‘a’ is a rigid type variable bound by the inferred type of foo :: (Integral b, Num a) => a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In an expression type signature: _inner In the expression: undefined :: _inner In the second argument of ‘($)’, namely ‘(undefined :: _inner) (1 + x)’ Ok, modules loaded: Main. }}} The inferred constraints for `_` (which I can't give a name, unfortunately) and the type reported in place of `_outer` are exactly what I expected. The type for `_inner` surprises me. Okay, the type is ambiguous, so for anything as general as `undefined`, arguably, it would need to default to something. Let's use a typed hole instead of `undefined`: {{{#!hs foo :: _ => _outer foo x = round $ _hole (1 + x) }}} gives {{{ Foo.hs:6:17: Found hole ‘_hole’ with type: a -> Double Where: ‘a’ is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In the expression: _hole In the second argument of ‘($)’, namely ‘_hole (1 + x)’ In the expression: round $ _hole (1 + x) Failed, modules loaded: none. }}} Holy Guacamole, it still defaults to `Double`. I would consider this a bug, because GHC is telling me, that whatever I put there must result in a `Double`, which is too restrictive to be true. However, I seem to recall from the OutsideIn paper that there were some cases, even without GADTs, where principality was difficult. Was this one of them? Moving on, I was actually trying to get all my holes typed for me in one compiler execution. GHC behaves according to spec; typed holes produce errors by default and when something breaks on an error, it doesn't produce the warnings for partial type signatures. Let's `-fdefer-typed- holes` and compile again: {{{ Prelude> :set -fdefer-typed-holes Prelude> :r [1 of 1] Compiling Main ( Foo.hs, interpreted ) Foo.hs:5:8: Warning: Found hole ‘_’ with inferred constraints: () In the type signature for ‘foo’: _ => _outer Foo.hs:5:13: Warning: Found hole ‘_outer’ with type: a -> b Where: ‘b’ is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 ‘a’ is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 In the type signature for ‘foo’: _ => _outer Foo.hs:6:17: Warning: Found hole ‘_hole’ with type: a -> Double Where: ‘a’ is a rigid type variable bound by the inferred type of foo :: a -> b at Foo.hs:6:1 Relevant bindings include x :: a (bound at Foo.hs:6:5) foo :: a -> b (bound at Foo.hs:6:1) In the expression: _hole In the second argument of ‘($)’, namely ‘_hole (1 + x)’ In the expression: round $ _hole (1 + x) Ok, modules loaded: Main. }}} Surely, this must be wrong. Suddenly `()` is the inferred set of constraints and an unconstrained `a -> b` will do for `_outer`. I would argue that the `1 +` still demainds `Num a`, even if `round`'s `RealFrac` constraint is satisfied by `_hole` producing a `Double`. As said, maybe the erroneous types reported when `-fdefer-typed-holes` are a separate issue from the type of `_hole` not being the principal type, but I'm unsure, so I reported them together. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9342: Branchless arithmetic operations
by GHC 28 Sep '15

28 Sep '15

#9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- While working on #9281 I noticed sub-optimal code generation for common arithmetic operations on `Int`. Below are some examples of code generation, where the branchless versions may be desirable on modern CPUs: = `abs` {{{#!hs -- base version absI# :: Int# -> Int# absI# i# = i'# where !(I# i'#) = abs (I# i#) -- optimized version optAbsI# :: Int# -> Int# optAbsI# i# = (i# `xorI#` nsign) -# nsign where -- nsign = i# <# 0# nsign = uncheckedIShiftRA# i# (WORD_SIZE_IN_BITS# -# 1#) }}} results in {{{#!asm absI#_info: _c1To: testq %r14,%r14 jge _c1Tx _c1Ty: movq %r14,%rbx negq %rbx jmp *(%rbp) _c1Tx: movq %r14,%rbx jmp *(%rbp) optAbsI#_info: _c1SX: movq %r14,%rax sarq $63,%rax movq %r14,%rbx xorq %rax,%rbx subq %rax,%rbx jmp *(%rbp) }}} = `signum` {{{#!hs sgnI# :: Int# -> Int# sgnI# i# = i'# where !(I# i'#) = signum (I# i#) optSgnI# :: Int# -> Int# optSgnI# x# = (x# ># 0#) -# (x# <# 0#) }}} {{{#!asm sgnI#_info: _c27W: testq %r14,%r14 jl _c283 _c284: testq %r14,%r14 jne _c28a _c28b: xorl %ebx,%ebx jmp *(%rbp) _c283: movq $-1,%rbx jmp *(%rbp) _c28a: movl $1,%ebx jmp *(%rbp) optSgnI#_info: _c26P: testq %r14,%r14 setl %al movzbl %al,%eax testq %r14,%r14 setg %bl movzbl %bl,%ebx subq %rax,%rbx jmp *(%rbp) }}} = `compare` {{{#!hs cmpI# :: Int# -> Int# -> Int# cmpI# x# y# = dataToTag# (compare (I# x#) (I# y#)) -- returns 0, 1 or 2, can be fed to tagToEnum# :: Ordering optCmpI# :: Int# -> Int# -> Int# optCmpI# x# y# = 1# +# (x# ># y#) -# (x# <# y#) }}} {{{#!asm cmpI#_info: _c25s: cmpq %rsi,%r14 jl _c25z _c25A: cmpq %rsi,%r14 je _c25M _c25N: movl $2,%ebx jmp *(%rbp) _c25z: xorl %ebx,%ebx jmp *(%rbp) _c25M: movl $1,%ebx jmp *(%rbp) optCmpI#_info: _c24N: cmpq %rsi,%r14 setl %al movzbl %al,%eax movl $1,%ebx subq %rax,%rbx cmpq %rsi,%r14 setg %al movq %rbx,%rcx movzbl %al,%ebx addq %rcx,%rbx jmp *(%rbp) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10916: PATH in Windows corrupt after 2nd install og GHC
by GHC 28 Sep '15

28 Sep '15

#10916: PATH in Windows corrupt after 2nd install og GHC ------------------------------------+--------------------------------- Reporter: ambusy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.2 Keywords: installation | Operating System: Windows Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | ------------------------------------+--------------------------------- Installed (absolute beginner!) Haskell default on windows X64: on the C:\ disk. Leads to problems with UAC rights when starting a tutorial with ghci. Disinstalled, and reinstalled on F:. In the path one reference to C:\Program Files\Haskell\bin remains, and ghci does not start. Below the output of my PATH. F:\>path PATH=C:\Program Files\Haskell\bin;F:\Haskell\lib\extralibs\bin;F:\Haskell\bin;C: \Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86) \Common Files\Microsoft Shared\Windows Live;C:\Windows\system32;C:\Windows;C:\Wi ndows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\ ;F:\Haskell\mingw\bin;C:\Users\ambusy\AppData\Roaming\cabal\bin -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10842: "Reactive" Template Haskell
by GHC 28 Sep '15

28 Sep '15

#10842: "Reactive" Template Haskell -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 9699 Differential Revisions: | -------------------------------------+------------------------------------- When metaprogramming, I often encounter the situation where I want GHC to do something for every definition in scope. For example, I recently posted a simple library called [https://github.com/mikeizbicki/ifcxt/ ifcxt] that relies on defining `instance IfCxt cxt` for every `instance cxt` that gets defined (where `cxt` is an arbitrary class instance). Currently, the library has a TH function that generates these `IfCxt cxt` instances, but it can only work for instances that already exist at the time the TH function is called. Any instances created afterward get silently ignored. To solve this problem, I would like to be able to register TH functions with the compiler that get executed everytime the compiler adds a definition. This might take the form of a function like: {{{ registerTH :: (Dec -> Q [Dec]) -> Q () }}} When `regesterTH` is called, it would add the argument function to an internal list. Then, whenever the compiler defines a new declaration, it calls each function in the list on that declaration to see what new declarations should be added to the code. AFAICT, there are two main drawbacks to this proposal. One, end users do not have to specifically invoke a TH function to get TH code to run. This would allow library authors to take over people's programs in possibly unexpected ways. So this might justify an additional extension beyond just `-XTemplateHaskell` to signal the potentially dangerous nature of the code, or implementing this feature by extending the compiler plugin interface. Second, it would be very easy to accidentally send the compiler into infinite loops if two registered functions don't take care to behave properly with each other. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7