- ghc-tickets - Haskell.org

[GHC] #9304: Floating point woes; Different behavior on Mac vs Linux
by GHC 16 Dec '15

16 Dec '15

#9304: Floating point woes; Different behavior on Mac vs Linux ------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: floating point | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've the following snippet: {{{ x, y, r :: Double x = -4.4 y = 2.4999999999999956 r = x * y }}} Using GHC 7.8.3, on a Mac, I get the following response from ghci: {{{ *Main> decodeFloat r (-6192449487634421,-49) }}} Using GHC 7.8.3, on a Linux machine, I get the following response: {{{ *Main> decodeFloat r (-6192449487634422,-49) }}} Note that off-by-one difference in the first component of the output. I'm not 100% sure as to which one is actually correct; but the point is that these are IEEE floating point numbers running on the same architecture (Intel X86), and thus should decode in precisely the same way. While I observed this with 7.8.3; I don't think this is a new regression; I suspect it'll show up in older versions as well. Also, for full disclosure: I ran the Mac version naively; but the Linux version on top of a VirtualBox image. I'd very much doubt that would make a difference, but there might be 32/64-bit concerns. So, if someone can validate the Linux output on a true 64-bit Linux machine, that would really help track down the issue further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 32

[GHC] #9306: Crash when shifting Integers too much
by GHC 16 Dec '15

16 Dec '15

#9306: Crash when shifting Integers too much ------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When shifting an Integer by `fromIntegral (maxBound::Int) + 2` or more, the RTS crashes. The attached program gives the following output (on x86_64, at least): [dfeuer@lemur src]$ ./shiftcrash Okay 0 gmp: overflow in mpz type Aborted I found the bug in 7.6.3, but it's been verified to be present also in 7.8.3. The crash also occurs when running similar code in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags
by GHC 16 Dec '15

16 Dec '15

#11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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: Design/Warnings -------------------------------------+------------------------------------- TODO: description -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11164: No way to import a data instance
by GHC 16 Dec '15

16 Dec '15

#11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import Foreign.R.Type as R (SComplex) }}} results in {{{ In module ‘Foreign.R.Type’: ‘SComplex’ is a data constructor of ‘Sing’ To import it use ‘import’ Foreign.R.Type( Sing( SComplex ) ) or ‘import’ Foreign.R.Type( Sing(..) ) }}} But if I try the suggested {{{#!hs import Foreign.R.Type as R (Sing(SComplex)) }}} I get {{{ Module ‘Foreign.R.Type’ does not export ‘Sing(SComplex)’ }}} So, when a module defines a data instance but does not export the family, there appears to be no way to bring that instance in scope (short of importing the whole module). Here's the module itself http://haddock.stackage.org/nightly-2015-10-19/inline-r-0.7.1.2/Foreign-R-T…. It doesn't have an explicit export list; that's how it manages to export instances without the family itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported
by GHC 16 Dec '15

16 Dec '15

#11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: Differential Rev(s): phab:D1484 | Wiki Page: -------------------------------------+------------------------------------- Currently GHC advertises `TemplateHaskell` even though it's statically known to fail: {{{ $ ghc --supported-extensions | grep Template TemplateHaskell NoTemplateHaskell # `NoTemplateHaskell` works: $ ghc -XNoTemplateHaskell -c hello.hs # `TemplateHaskell` however fails even though advertised: $ ghc -XTemplateHaskell -c hello.hs ghc: on the commandline: Template Haskell requires GHC with interpreter support Perhaps you are using a stage-1 compiler? Usage: For basic information, try the `--help' option. }}} Having properly advertised extensions is particularly useful in combination with [[https://github.com/haskell/cabal/issues/2644|Cabal#2644]] allowing the solver to toggle flags depending on the availability of `-XTemplateHaskell`. For instance, cross-compilers and/or unregisterised GHC builds often don't have TemplateHaskell support. Having support for toggling flags based on availability of `-XTemplateHaskell` allows `cabal` to support such environments with less manual intervention. (See also https://github.com/haskell/cabal/pull/2930 for pre-GHC8 emulation of this feature) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf
by GHC 16 Dec '15

16 Dec '15

#11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: Data.List, | Operating System: Unknown/Multiple isSubsequenceOf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In order to clarify the difference between isInfixOf and isSubsequenceOf, I submit a patch which changes the wording from "The 'isSubsequenceOf' function takes two lists and returns 'True' if the first list is a subsequence of the second list." to "The 'isSubsequenceOf' function takes two lists and returns 'True' if all the elements of the first list occur, in order, in the second. The elements do not have to occur consecutively." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8347: Add a Strict LANGUAGE pragma
by GHC 16 Dec '15

16 Dec '15

#8347: Add a Strict LANGUAGE pragma ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A `Strict` `LANGUAGE` pragma would allow us to experiment with writing in a strict sub-language. Since this pragma works on a per module basis, it needs to be modular. I propose the following semantics: * Patterns are strict at the top-level, as if they had a top-level bang, unless an explicit ~ is used to make the pattern lazy. * Functions evaluate their parameters to WHNF. * Data type fields are strict (as if they had a bang-pattern). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5775: Inconsistency in demand analysis
by GHC 16 Dec '15

16 Dec '15

#5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * owner: => bgamari * milestone: 8.0.1 => 8.2.1 Old description: > A small program: > > {{{ > {-# LANGUAGE MagicHash, UnboxedTuples #-} > module U where > import GHC.Prim > import GHC.Types > > idx :: Addr# -> Int -> Int > {-# INLINE idx #-} > idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y > > f :: Int -> Int -> Int > {-# INLINE f #-} > f x y = y + x > > foo :: Addr# -> Int -> Int > foo a n = n `seq` loop (idx a 0) 1 > where > loop x i = case i >= n of > False -> loop (f x (idx a i)) (i+1) > True -> x > }}} > > GHC infers the demand `LU(L)` for `loop`, only unboxes the second > argument, ultimately generates a loop of type `Int -> Int# -> Int` and > always allocates a thunk for the first argument: > > {{{ > $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int > [LclId, Arity=2, Str=DmdType LL] > $wloop_si9 = > \ (w1_shU :: Int) (ww1_shX :: Int#) -> > case >=# ww1_shX ww_si5 of _ { > False -> > $wloop_si9 > (case readIntOffAddr# @ RealWorld w_si2 ww1_shX > realWorld# > of _ { (# _, y_a9S #) -> > case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) } > }) > (+# ww1_shX 1); > True -> w1_shU > }; } > }}} > > But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` > gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as > well as the result, producing a nice tight loop: > > {{{ > $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int# > [LclId, Arity=2, Str=DmdType LL] > $wloop_sii = > \ (ww1_shW :: Int#) (ww2_si0 :: Int#) -> > case >=# ww2_si0 ww_sib of _ { > False -> > case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld# > of _ { (# _, y1_Xac #) -> > case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin -> > $wloop_sii ww3_Xin (+# ww2_si0 1) > } > }; > True -> ww1_shW > }; } > }}} > > It would be nice if this happened in both cases. New description: A small program: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} module U where import GHC.Prim import GHC.Types idx :: Addr# -> Int -> Int {-# INLINE idx #-} idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y f :: Int -> Int -> Int {-# INLINE f #-} f x y = y + x foo :: Addr# -> Int -> Int foo a n = n `seq` loop (idx a 0) 1 where loop x i = case i >= n of False -> loop (f x (idx a i)) (i+1) True -> x }}} GHC infers the demand `LU(L)` for `loop`, only unboxes the second argument, ultimately generates a loop of type `Int -> Int# -> Int` and always allocates a thunk for the first argument: {{{#!hs $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int [LclId, Arity=2, Str=DmdType LL] $wloop_si9 = \ (w1_shU :: Int) (ww1_shX :: Int#) -> case >=# ww1_shX ww_si5 of _ { False -> $wloop_si9 (case readIntOffAddr# @ RealWorld w_si2 ww1_shX realWorld# of _ { (# _, y_a9S #) -> case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) } }) (+# ww1_shX 1); True -> w1_shU }; } }}} But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as well as the result, producing a nice tight loop: {{{#!hs $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId, Arity=2, Str=DmdType LL] $wloop_sii = \ (ww1_shW :: Int#) (ww2_si0 :: Int#) -> case >=# ww2_si0 ww_sib of _ { False -> case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld# of _ { (# _, y1_Xac #) -> case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin -> $wloop_sii ww3_Xin (+# ww2_si0 1) } }; True -> ww1_shW }; } }}} It would be nice if this happened in both cases. -- Comment: For the record this is still reproducible with GHC 7.10.3. It sounds like this ought to be revisited (if for no other reason than to ensure that the fragility really is only exposed with `unsafePerformIO`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5775#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10639: Optimization changes concurrent program's behaviour
by GHC 16 Dec '15

16 Dec '15

#10639: Optimization changes concurrent program's behaviour -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here is a program that spawns a thread from the main thread, which tries to constantly write out a message to the console. {{{#!hs module Main where import Control.Concurrent (forkIO) main :: IO () main = do _ <- forkIO $ runForever $ putStrLn "Hey" runForever $ return () runForever :: IO () -> IO () runForever action = action >> runForever action }}} If you compile it with 'ghc main', it works correctly - it prints out the message continuously, and you can terminate it by pressing Ctrl-C. However, if you compile it with 'ghc -O main' (or -O2, or -O3...), it doesn't print out anything, and the only way to exit is to kill the process from Task Manager. This was reproducable with GHC 7.10.1, on a Windows 7 x64 machine, with an AMD A4-5300 APU. ''(Disclaimer: this is my first bugreport, and I'm not sure what else can I do to investigate this issue.)'' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11229: splitLHsForAllTy not exported from HsTypes
by GHC 16 Dec '15

16 Dec '15

#11229: splitLHsForAllTy not exported from HsTypes -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.10.3 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: -------------------------------------+------------------------------------- Currently if one wants to get the contextless instance declaration type, needs to call splitLHsInstDeclTy_maybe, then undo some of the splitting it did. If splitLHsForAllTy were exported, it could be used directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1