December 2015 - ghc-tickets

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

[GHC] #8424: quasi-quotes have carriage returns on Windows
by GHC 16 Dec '15

16 Dec '15

#8424: quasi-quotes have carriage returns on Windows ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 Windows user rerported using Data.Text.IO.writeFile to write out quasi- quoted text. writeFile automatically translates '\r' to "\r\n", so the user ended up writing out "\r\r\n" to a file. Haskell seems to be adopting the policy or removing '\r' from Haskell land. Is there any reason why quasi-quotes should not automatically strip carriage returns? I asked this question on ghc-users and there was no response. I am willing to make this fix if it is deemed appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10820: Provide a way to detect what extensions are enabled via TH
by GHC 15 Dec '15

15 Dec '15

#10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This would be helpful for providing users with intuitive error messages if generated code relies on an extension that the user may not have enabled. Sample specification, to get things started: {{{ enabledExts :: Q [Extension] isExtEnabled :: Extension -> Q Bool data Extension = LiberalTypeSynonyms | RankNTypes | ... -- mirroring ExtensionFlag in DynFlags }}} See #10819 for an example case where this could be of use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9348: "Symbol not found" when using a shared library
by GHC 15 Dec '15

15 Dec '15

#9348: "Symbol not found" when using a shared library -----------------------------------+----------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------------- I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries. What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following: Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib More details: The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows: --- Error in dyn.load("final.dylib") : unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib': dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib --- As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. My Mac OS version is 10.9.4. My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. Command used for compiler: ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11199: Outdated documentation for type operators
by GHC 15 Dec '15

15 Dec '15

#11199: Outdated documentation for type operators -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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: -------------------------------------+------------------------------------- John Leo writes: According to sections 7.4.3 and 7.4.4 of the latest [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data- type-extensions.html GHC documentation] you can define (7.4.3) an infix type constructor as long as it begins with a colon, for example {{{ data a :*: b = Foo a b }}} and furthermore (7.4.4) you can define an infix operator without having to use a colon if you enable the `TypeOperators` extension: {{{ data a * b = Foo a b }}} However if I try the former without using `TypeOperators` I get this compiler error in 7.10.2: {{{ Illegal declaration of a type or class operator ‘:*:’ Use TypeOperators to declare operators in type and declarations }}} Using `TypeOperators` fixes this, but then `*` without colon also works so I don't see the point of using colon anymore. My guess is this was some some kind of historical distinction which is no longer valid and the documentation needs to be updated. Is this true, or am I missing something? ------------------------- Answer: it's just historical and the documentation is wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11208: GHCi doesn't qualify types anymore
by GHC 15 Dec '15

15 Dec '15

#11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `M.hs` contains: {{{#!hs module M where import qualified Prelude as P f n = n P.+ 1 g h (P.Just x) = P.Just (h x) g _ P.Nothing = P.Nothing }}} GHC 7.10.3 behaves as expected: {{{ $ ghci-7.10.3 -ignore-dot-ghci M.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling M ( M.hs, interpreted ) Ok, modules loaded: M. *M> :browse f :: P.Num a => a -> a g :: (t -> a) -> P.Maybe t -> P.Maybe a *M> :t f f :: P.Num a => a -> a *M> :t g g :: (t -> a) -> P.Maybe t -> P.Maybe a }}} However, GHC HEAD drops the module qualifiers {{{ $ ghci-7.11.20151209 -ignore-dot-ghci M.hs GHCi, version 7.11.20151209: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling M ( M.hs, interpreted ) Ok, modules loaded: M. *M> :browse f :: Num a => a -> a g :: (t -> a) -> Maybe t -> Maybe a *M> :t f f :: Num a => a -> a *M> :t g g :: (t -> a) -> Maybe t -> Maybe a *M> Nothing :: Maybe () <interactive>:4:12: error: Not in scope: type constructor or class ‘Maybe’ Perhaps you meant ‘P.Maybe’ (imported from Prelude) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11208> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11178: Documentation bug in Data.List.NonEmpty
by GHC 15 Dec '15

15 Dec '15

#11178: Documentation bug in Data.List.NonEmpty -------------------------------------+------------------------------------- Reporter: audunska | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | 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: -------------------------------------+------------------------------------- (also filed against the semigroups package) The documentation for cycle says that > cycle [1,2,3] = 1 :| [2,3,1,2,3,...] But the argument should be NonEmpty, so it should read > cycle (1 :| [2,3]) = 1 :| [2,3,1,2,3,...] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error
by GHC 15 Dec '15

15 Dec '15

#9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, if I say `{-# LANGUAGE Foo #-}` at the top of my file, it fails to compile. This failure seems unnecessary, especially because any new language feature `Foo` enables will fail to compile later on down the file. Is it possible to have a "stern warning" that is produced even when other parts of the file produce errors? The reason I'm bringing this up is that, when 7.8 came out with its role annotations, users needed CPP in two different places: both to protect the `RoleAnnotations` pragma and to protect the role annotations themselves. This may be unavoidable on the role annotations directly, but I think we can improve the situation around `LANGUAGE` pragmas. Is there a downside to this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7