August 2014 - ghc-tickets

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 18 Aug '14

18 Aug '14

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 6.8.1 Component: Compiler | 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 sweirich): * cc: sweirich@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9448: Clarify documentation of a quasi-quoter form
by GHC 18 Aug '14

18 Aug '14

#9448: Clarify documentation of a quasi-quoter form -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | Documentation bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to http://www.haskell.org/ghc/docs/latest/html/users_guide /template-haskell.html#th-quasiquotation, for quasi-quoter form {{{#!hs [quoter| string |] }}} The quoter must be the (unqualified) name of an imported quoter. But according to #5555 ticket, qualified quoters are allowed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9448> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9452: freeGroup: block size is zero
by GHC 17 Aug '14

17 Aug '14

#9452: freeGroup: block size is zero ----------------------------------+---------------------------------------- Reporter: scott.sadler | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------------- I'm trying to extract pixels from OpenGL and read them into a ForeignPointer, but getting a segfault while doing a peek operation. The fault is on line 240 in `peekArray`. It crashes in different ways depending on the arguments to `readPixelArray`. with `readPixelArray 0 0 100 100`: {{{ (lldb) run Process 26467 launched: '/Users/scott/Code/grids/dist/build/grids/grids' (x86_64) 0x00000001015b3010 Process 26467 stopped * thread #1: tid = 0x23d3cc, 0x0000000100621ead grids`evacuate + 157, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff8) frame #0: 0x0000000100621ead grids`evacuate + 157 grids`evacuate + 157: -> 0x100621ead: movl -0x8(%r12), %esi 0x100621eb2: leal -0x1(%rsi), %ecx 0x100621eb5: cmpl $0x3b, %ecx 0x100621eb8: ja 0x1006222a9 ; evacuate + 1177 }}} with `readPixelArray 0 0 200 200`: (lldb) run Process 26647 launched: '/Users/scott/Code/grids/dist/build/grids/grids' (x86_64) 0x00000001095d8010 grids: internal error: freeGroup: block size is zero (GHC version 7.8.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Process 26647 stopped * thread #1: tid = 0x23f4d4, 0x00007fff8b2cc866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main- thread', stop reason = signal SIGABRT frame #0: 0x00007fff8b2cc866 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill + 10: -> 0x7fff8b2cc866: jae 0x7fff8b2cc870 ; __pthread_kill + 20 0x7fff8b2cc868: movq %rax, %rdi 0x7fff8b2cc86b: jmpq 0x7fff8b2c9175 ; cerror_nocancel 0x7fff8b2cc870: ret The "freeGroup: block size is zero" message appears in the second output. I'm stumped trying to debug this one. I didn't get as far as trying to go backwards in time debugging it because of lack of familiarity with lldb. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9451: Incorrect optimizations involving negative zero
by GHC 17 Aug '14

17 Aug '14

#9451: Incorrect optimizations involving negative zero -------------------------------------+------------------------------------- Reporter: manzyuk | 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: -------------------------------------+------------------------------------- The program {{{#!hs main = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0 where negativeZero = negate 0.0 }}} outputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optimization level -O2. The relevant pieces of Core: {{{ -- GHC 7.6.3 Main.main2 = case GHC.Prim.==## (GHC.Prim.negateDouble# 0.0) 0.0 of _ { GHC.Types.False -> Main.main3 (GHC.Types.[] @ GHC.Types.Char); GHC.Types.True -> case GHC.Prim./## 1.0 (GHC.Prim.negateDouble# 0.0) of wild2_aK6 { __DEFAULT -> GHC.Float.$w$sshowSignedFloat GHC.Float.$fShowDouble_$sshowFloat GHC.Show.shows26 wild2_aK6 (GHC.Types.[] @ GHC.Types.Char) } } }}} {{{ -- GHC 7.8.3 Main.main2 = case GHC.Prim.negateDouble# 0.0 of _ [Occ=Dead] { __DEFAULT -> Main.main3 (GHC.Types.[] @ GHC.Types.Char); 0.0 -> case GHC.Prim./## 1.0 0.0 of wild2_a1NU { __DEFAULT -> GHC.Float.$w$sshowSignedFloat GHC.Float.$fShowDouble_$sshowFloat GHC.Show.shows27 wild2_a1NU (GHC.Types.[] @ GHC.Types.Char) } } }}} I don't think this problem is operating system/architecture dependent, but for the sake of completeness I'm on a 32-bit Linux, and this issue was first discovered on 64-bit Windows running in a virtual machine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7015: Add support for 'static'
by GHC 17 Aug '14

17 Aug '14

#7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | 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: Phab:D119 | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): When trying to do floating in the desugarer I arrived at a point where I need evidence bindings to desugar. For instance, when encountering the expression `static return :: Ref (a -> IO a)`, the desugarer tries to float `return` as {{{ Main.static:0 :: forall a_azE. a_azE -> GHC.Types.IO a_azE Main.static:0 = \ (@ a_azE) -> GHC.Base.return @ GHC.Types.IO $dMonad_azG @ a_azE }}} where `$dMonad_azG` is a variable carrying the `Monad IO` dictionary. As `$dMonad_azG` is not in scope the above code is rejected by the Core Lint pass. When floating is done in the typechecker, the binding of `$dMonad_azG` is produced by `simplifyInfer` in `checkStaticValues` at the place where the floated bindings for static forms are assembled. Further down the processing, desugaring inserts this evidence binding as a core `let` binding in the rhs of `static:0`, subsequently inlined to yield something like: {{{ Main.static:0 :: forall a_azE. a_azE -> GHC.Types.IO a_azE Main.static:0 = \ (@ a_azE) -> GHC.Base.return @ GHC.Types.IO GHC.Base.$fMonadIO @ a_azE }}} Now, to do floating in the desugarer, it looks like evidence bindings need to be communicated to the place in the desugarer (I presume `dsExpr`) where the floating should be implemented. Would there be a preferred way to do it? I couldn't find precedents of similar needs in the ghc code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9446: Segfault when using unsafe vector operations
by GHC 17 Aug '14

17 Aug '14

#9446: Segfault when using unsafe vector operations ----------------------------------+---------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+---------------------------------------- I was working on some benchmarks and I ran into this issue. It's actually very difficult to reproduce; changing the attached file in different ways makes the bug go away quite quickly. But with the attached file, I regularly get a `internal error: evacuate: strange closure type 0` message, though on more complicated versions of the code I was working on, the integer would change for each run. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9446> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 17 Aug '14

17 Aug '14

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Changes (by tejon): * cc: hvr (added) Comment: I am attempting to run the test code for helm, which depends on gtk and sdl2. **As in the main ticket case, compiling with GHC works fine.** I ran into the "GHCi can't find m.dll" issue on the pango dependency, but fixed it using fryguybob's suggestion. Sadly, I run into a similar issue on the sdl2 dependency: {{{ Loading package sdl2-1.1.0 ... <interactive>: mingw32: The specified module could not be found. can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL) }}} Relinking libmingw32.a into a dll was problematic: the .a contains both dllmain.o and a spurious main.o (which I removed), and also a pair of objects crtst.o and tlsmcrt.o which each do nothing but declare the same integer (a threading state flag), leading to a duplicate declaration error; I have tried favoring each, with the same result. Linking the remainder into mingw32.dll, I now get this: {{{ Loading package sdl2-1.1.0 ... <interactive>: Unknown PEi386 section name `.rdata$IID_IBindStatusCallback' (while processing: C:/msys/lib\libSDL2.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-mingw32): loadArchive "C:/msys/lib\\libSDL2.a": failed }}} Perhaps mangling the relink broke everything, but I don't believe it should have gotten that far in the first place: like the m.dll issue this seems to arise from GHCi's inability to identify libfoo.a with foo.dll. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:26> 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 15 Aug '14

15 Aug '14

#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | 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 Lemming): * cc: ghc@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7275#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal"
by GHC 15 Aug '14

15 Aug '14

#9443: Regression from 7.6.3 to 7.8.3: could not coerce because argument "has role Nominal" -------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This file works fine with 7.6.3: <https://github.com/plaimi/plailude/blob/master/src/Data/Time/Units.hs> But with 7.8.3, every newtype has an error message like: {{{ Could not coerce from ‘TimeUnit Integer’ to ‘TimeUnit (Year a)’ || because the first type argument of ‘TimeUnit’ has role Nominal, || but the arguments ‘Integer’ and ‘Year a’ differ || arising from the coercion of the method ‘timeVal’ from type || ‘forall n. (TimeUnit Integer, Num n) => Integer -> n’ to type || ‘forall n. (TimeUnit (Year a), Num n) => Year a -> n’ }}} To make the code work again, I need to remove a redundant type constraint from: {{{#!hs class TimeUnit t where timeVal :: (TimeUnit t, Num n) => t -> n }}} Turning it into: {{{#!hs class TimeUnit t where timeVal :: Num n => t -> n }}} The constraint is redundant because it is already implied by 'class TimeUnit t'. I suspect this is a regression. I would be happy to work on it, but I don't have time right now, so I'm putting it here for visibility, feedback, and to remember it in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 13 Aug '14

13 Aug '14

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: x86 Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dmcclean): * difficulty: => Unknown Comment: I have a similar error on 7.8.3 on Windows. I can't see anything remarkable about the function it complains about. Calls to it seem to work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0