- ghc-tickets - Haskell.org

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

18 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 18 Aug '14

18 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 16 Aug '14

16 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 14 Aug '14

14 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

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

13 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): Design notes are available [https://ghc.haskell.org/trac/ghc/wiki/StaticValues here]. Please, feel free to comment or ask for refinements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7015#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow)
by GHC 13 Aug '14

13 Aug '14

#9416: newArray# incorrectly inlines big arrays (overflow1.hs SIGSEGVS on ./validate --slow) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Found by ./validate: '''testsuite/tests/rts/overflow1.hs''' SIGSEGVs due to integer overflow somewhere around [https://git.haskell.org/ghc.git/blob/c88559b3304cc5e142ab9c2655d48e570f81af… shouldInlinePrimOp] {{{#!hs ... shouldInlinePrimOp dflags NewByteArrayOp_Char [(CmmLit (CmmInt n _))] | fromInteger n <= maxInlineAllocSize dflags = ... }}} '''maxInlineAllocSize''' has ''':: Int''' type: {{{#!hs fromInteger (2^64 - 10) < (128 :: Int) True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles
by GHC 12 Aug '14

12 Aug '14

#7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------- Reporter: lerkok | Owner: bernalex Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: floating point Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9238 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D145 | -------------------------------------+------------------------------------- Changes (by bernalex): * owner: => bernalex Comment: I'm going to write a patch using rwbarton's suggestion for signum, and test it with ghci and with various ghc optimisations tonight or tomorrow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7858#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0