June 2015 - ghc-tickets

[GHC] #8363: Order matters for unused import warnings when reexporting identifiers
by GHC 01 Jul '15

01 Jul '15

#8363: Order matters for unused import warnings when reexporting identifiers ------------------------------------+------------------------------------- Reporter: bergmark | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Import order seem to change whether unused import warnings trigger when a module re-exports an identifier, with another module importing it and another module exporting the same identifier. Reproduction: {{{ module Foo ( (<$>) , g ) where import Control.Applicative g :: Int g = 1 }}} {{{ module Main where import Control.Applicative import Foo main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ $ ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} If Main is not using `g` then this gives a warning that the import of `Foo` is redundant. If we switch the order of the imports we do get the warning: {{{ module Main where import Foo import Control.Applicative main :: IO () main = print =<< ((+2) <$> return g) }}} {{{ > ghc -fwarn-unused-imports Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:4:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() Linking Main ... }}} I expected both versions of Main to produce the same warning. Tested on GHC 7.7.20130824 and 7.4.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8222: CTYPE pragma on newtype is ignored
by GHC 01 Jul '15

01 Jul '15

#8222: CTYPE pragma on newtype is ignored --------------------------+------------------------------------------------ Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 Compiler | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ User's guide includes an example where a CTYPE pragma is used for a newtype. {{{ newtype {-# CTYPE "useconds_t" #-} T = ... }}} However, in the following program, the CTYPE pragma seems to be ignored: {{{ {-# LANGUAGE CApiFFI #-} import Foreign.Ptr foreign import capi unsafe "sys/socket.h CMSG_DATA" c_CMSG_DATA :: Ptr Cmsg -> Ptr a newtype {-# CTYPE "sys/socket.h" "struct cmsghdr" #-} Cmsg = Cmsg () main = return () }}} Save this as {{{capi.hs}}}, then compile it like: {{{ ghc capi.hs -fforce-recomp -keep-tmp-files -tmpdir . }}} Then GHC creates a C file: {{{ #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include <sys/socket.h> void* ghczuwrapperZC0ZCmainZCMainZCCMSGzuDATA(void* a1) {return CMSG_DATA(a1);} #ifdef __cplusplus } #endif }}} The argument type of the wrapper function is {{{void *}}}, but it should be {{{struct cmsghdr *}}}. If I replace {{{newtype}}} with {{{data}}} in capi.hs, the wrapper function gets the correct type. I can see this problem in HEAD and in 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10591: repeated field name allowed in constructor
by GHC 30 Jun '15

30 Jun '15

#10591: repeated field name allowed in constructor -------------------------------------+------------------------------------- Reporter: gladstein | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs data Foo = Bar {x :: Int} | Baz {x :: Int, x :: String } main = do let a = Bar 1 b = Baz 2 "3" print $ x a print $ x b }}} :load "p:/DSFP/sandbox/bug1.hs" GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> [1 of 1] Compiling Main ( P:\DSFP\sandbox\bug1.hs, interpreted ) Ok, modules loaded: Main. *Main> main 1 1729382256910738103 *Main> -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8
by GHC 30 Jun '15

30 Jun '15

#10562: GHC 7.10.2 RC cannot build boolsimplifier-0.1.8 -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In running a Stackage Nightly build with GHC 7.10.2 (via Herbert's PPA), I discovered the following regression: http://lpaste.net/135057 Note that boolsimplifier-0.1.8 compiles just fine with GHC 7.10.1, but not with 7.10.2. I am still running the rest of the Stackage build. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150619 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10588: BangPat gets wrong SrcSpan.
by GHC 30 Jun '15

30 Jun '15

#10588: BangPat gets wrong SrcSpan. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In this simple file {{{#!hs {-# LANGUAGE BangPatterns #-} baz !"a" = bang }}} It can be seen that on line 28 the `BangPat` has the wrong `SrcSpan`. {{{#!hs annotations=lineno ({ typetest.hs:1:1 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnEofPos),DP (1,0))]) (HsModule (Nothing) (Nothing) [] [ ({ typetest.hs:3:1-15 } Just (Ann (DP (2,1)) (ColDelta 1) DP (2,1) [(Comment {commentPos = DP (0,29), commentContents = "{-# LANGUAGE BangPatterns #-}", commentIdentifier = RealSrcSpan SrcSpanOneLine "typetest.hs" 1 1 30, commentOrigin = Nothing},DP (0,0))] []) (ValD (FunBind ({ typetest.hs:3:1-3 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnVal),DP (0,0))]) (Unqual {OccName: baz})) (False) (MG [ ({ typetest.hs:3:1-15 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnEqual),DP (0,1)),((AnnList <no location info> NotNeeded),DP (0,0))]) (Match (Just ((,) ({ typetest.hs:3:1-3 } Just (Ann (DP (0,0)) (ColDelta 1) DP (0,0) [] [((G AnnVal),DP (0,0))]) (Unqual {OccName: baz})) (False))) [ ({ typetest.hs:3:1-8 } Just (Ann (DP (0,-3)) (ColDelta 1) DP (0,-3) [] [((G AnnBang),DP (0,1))]) (BangPat ({ typetest.hs:3:6-8 } Just (Ann (DP (0,0)) (ColDelta 6) DP (0,0) [] [((G AnnVal),DP (0,0))]) (LitPat (HsString "\"a\"" {FastString: "a"})))))] (Nothing) (GRHSs [ ({ typetest.hs:3:10-15 } Just (Ann (DP (0,-1)) (ColDelta 10) DP (0,-1) [] []) (GRHS [] ({ typetest.hs:3:12-15 } Just (Ann (DP (0,1)) (ColDelta 12) DP (0,1) [] [((G AnnVal),DP (0,0))]) (HsVar (Unqual {OccName: bang})))))] (EmptyLocalBinds))))] [] (PlaceHolder) (FromSource)) (WpHole) (PlaceHolder) [])))] (Nothing) (Nothing))) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10588> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 30 Jun '15

30 Jun '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Comment (by simonpj): OK so it's now looking roughly linear, which is great. It still seems like a lot for what started life as a pretty small program. What does the profile show now? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10482: Not enough unboxing happens on data-family function argument
by GHC 30 Jun '15

30 Jun '15

#10482: Not enough unboxing happens on data-family function argument -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In the following code, `foo` and `foo'` have isomorphic types, but the worker-wrapper pass does less unboxing for `foo`: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE TypeFamilies #-} module Foo where data family Foo a data instance Foo (a, b) = FooPair !(Foo a) !(Foo b) newtype instance Foo Int = Foo Int foo :: Foo ((Int, Int), Int) -> Int -> Int foo !f k = if k == 0 then 0 else if even k then foo f (k-1) else case f of FooPair (FooPair (Foo n) _) _ -> n data Foo0 a b c = Foo0 !(Foo1 a b) !c data Foo1 a b = Foo1 !a !b foo' :: Foo0 Int Int Int -> Int -> Int foo' !f k = if k == 0 then 0 else if even k then foo' f (k-1) else case f of Foo0 (Foo1 n _) _ -> n }}} The core generated by `ghc -ddump-simpl -O2 ww.hs` contains the following functions: {{{ Foo.foo_$s$wfoo [Occ=LoopBreaker] :: Foo Int -> Foo Int -> Foo.R:Foo(,) Int Int ~R# Foo (Int, Int) -> Foo Int -> GHC.Prim.Int# -> Int Foo.$wfoo [InlPrag=[0]] :: Foo (Int, Int) -> Foo Int -> GHC.Prim.Int# -> Int Foo.$wfoo' [InlPrag=[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> Int -> GHC.Prim.Int# -> Int }}} The first argument of `Foo.foo_$s$wfoo` could be `Int#`, but it takes a boxed value. In practice this happens with unboxed vectors from the `vector` package. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 29 Jun '15

29 Jun '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 29 Jun '15

29 Jun '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Comment (by bgamari): Phab:D1012 appears to give a moderate improvement in compile time in this case. Take, for instance, a 1000-constructor testcase, {{{#!hs module Mod(F(..)) where data F = F0 { fldF0 :: ()} | F1 { fldF1 :: ()} ... | F1023 {fldF1023 :: ()} deriving (Read) }}} With 7.11 prior to the change `ghc -O` runs for about 140 seconds. After the change it runs for about 100 seconds. Moreover, one sees a substantial reduction in heap allocations. The previously non-linear performance degradation can be seen in the table below. ||= Number of constructors =||||||= allocated (MBytes) =||||||= time (seconds) =|| ||= n =||= Pre-D1012 =||= Post-D1012 =||= Delta (%) =||= Post-D1012 =||= Post-D1012 =||= Delta (%) =|| || 16|| 1.75 ± 0.03 || 1.69 ± 0.02 || -3%|| 1484.58 ± 0.75 || 1470.53 ± 0.77 || -1%|| || 64|| 6.62 ± 0.25 || 5.96 ± 0.06 || -10%|| 5466.96 ± 1.53 || 5248.22 ± 1.64 || -4%|| || 128|| 13.33 ± 0.82 || 12.00 ± 0.63 || -10%|| 11282.75 ± 1.55 || 10406.51 ± 1.99 || -8%|| || 256|| 26.68 ± 0.53 || 23.69 ± 0.81 || -11%|| 24680.84 ± 2.32 || 21137.36 ± 2.36 || -14%|| || 512|| 67.61 ± 2.69 || 47.99 ± 0.67 || -29%|| 58628.48 ± 30.32 || 44412.63 ± 0.36 || -24%|| || 1024|| 144.91 ± 4.07 || 102.19 ± 0.60 || -29%|| 156753.21 ± 374.40 || 99523.84 ± 121.99 || -37%|| || 2048|| 379.93 ± 6.77 || 236.63 ± 3.51 || -38%|| 478481.02 ± 287.23 || 248791.64 ± 233.84 || -48%|| || 4096|| 1379.47 ± 0.00 || 650.83 ± 5.65 || -53%|| 1690084.72 ± 0.00 || 759242.66 ± 42.84 || -55%|| -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used
by GHC 29 Jun '15

29 Jun '15

#10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1-rc1 System | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9423 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this: {{{#!hs import Control.Concurrent import System.Posix.Signals main :: IO () main = do _ <- flip (installHandler sig) Nothing $ Catch $ putStrLn $ "Received signal " ++ show sig raiseSignal sig threadDelay 100000 where sig = sigUSR2 }}} If you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output: {{{ Received signal 12 Received signal 12 Received signal 12 Received signal 12 Received signal 12 }}} In general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals. This regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later [changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted] but then [changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re- added]), a commit addressing #9423. The cause of the problem is [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L256 this] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L183 here])? Removing the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9