June 2016 - ghc-tickets

[GHC] #10106: GHC doesn't warn on typos in language pragmas
by GHC 11 Aug '16

11 Aug '16

#10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In particular, I was struggling with the QuasiQuotes language extension. I had - {{{#!hs {-# LANGAUGE QuasiQuotes #-} site = [shamelet|Hello World!|] }}} Notice the transposed A and U in `LANGUAGE` The error that ghc was emitting was - `Main.hs:23:47: parse error on input ‘]’` It took me a long time and a lot of head-banging to figure out that it was a typo in the language pragma, especially because the language pragma was surrounded by other language pragmas and it was at the top of the file. I would think that this should at least emit a warning when there is a typo in a pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12172: User's Guide patches
by GHC 07 Aug '16

07 Aug '16

#12172: User's Guide patches -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 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: -------------------------------------+------------------------------------- If you want your User's Guide patches to be merged to the 8.0 branch, please mention this ticket in the commit message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12007: Pattern families regression
by GHC 07 Aug '16

07 Aug '16

#12007: Pattern families regression -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- The following code compiles fine for me in GHC 7.10.1, but fails in GHC 8.1.20160502 {{{ {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} data Foo a = Foo a a pattern A a1 a2 = Foo a1 a2 pattern B a1 a2 = A a1 a2 }}} The problem is the nested pattern. Compiling gives: {{{ [1 of 1] Compiling Main ( Bug1.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160502 for x86_64-unknown-linux): kindPrimRep.go rep_a85f Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9517: hp2ps generates invalid postscript file
by GHC 07 Aug '16

07 Aug '16

#9517: hp2ps generates invalid postscript file -----------------------------+---------------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+---------------------------------- Some of the outputs have a name such as foo(...). However, the postscript generation does not add an extra closing parenthesis after the foo(...). Example from attachment on line 410. ((447)modifyEdge.newEdges.(...) show This should presumably be: ((447)modifyEdge.newEdges.$...$) show Output from ps2pdf: Error: /syntaxerror in -file- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1163/1684(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 40721 GPL Ghostscript 9.07: Unrecoverable error, exit code 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes
by GHC 07 Aug '16

07 Aug '16

#12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7437 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module compiles with GHC 8: {{{ {-# LANGUAGE DefaultSignatures #-} -- {-# LANGUAGE AllowAmbiguousTypes #-} -- Not required with GHC 8.0.1. module T12151 where class Put a where put :: a default put :: t -- This should be `a` instead of `t` put = undefined }}} GHC 7.10 required `AllowAmbiguousTypes`, to defer the ambiguity check to use sites. (Example extracted from the description of #7437) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code
by GHC 06 Aug '16

06 Aug '16

#9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: -------------------------------------+------------------------------------- In an attempt to close #4210 the LLVM code generator's mangler was modified in ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables. Unfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `"@function"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `"@object"` in the produced object. Hilarity ensues. This can be demonstrated by the simple test `main = putStrLn "@function"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining
by GHC 04 Aug '16

04 Aug '16

#8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining ------------------------------------+------------------------------------- Reporter: jberryman | 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: | ------------------------------------+------------------------------------- I just remembered an old idea I put to the GHC user's list [http://www .mail-archive.com/glasgow-haskell-users(a)haskell.org/msg22119.html here], and thought I should present it here. As I understand it GHC inlines inlines only after a function is fully applied with respect to the syntactic left-hand side, so in order to control inlining and sharing, we sometimes see strange things like: {{{ {-# INLINE foo #-} foo :: a -> b -> c foo a = \b -> ... }}} It would be nice to be able to define the function syntactically in the way that's the most clear (e.g. in pointfree style, etc.) and specify at what point to inline something like this: {{{ foo :: a -> {-# INLINE #-} b -> c foo a b = ... -- or: foo = ... }}} ...which tells the compiler to inline after applying the arguments to the left of the pragma, and GHC would do whatever trivial (I assume?) eta- conversion was required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE
by GHC 04 Aug '16

04 Aug '16

#8589: Bad choice of loop breaker with INLINABLE/INLINE ------------------------------+-------------------------------------------- Reporter: | Owner: NickSmallbone | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Take the following program, which defines a pair of lists recursively: {{{ module Test(xs, ys) where pair :: ([Bool], [Bool]) pair = (False:xs, True:ys) where (xs, ys) = pair (xs, ys) = pair }}} GHC is clever enough to disentangle {{{xs}}} from {{{ys}}} and with {{{-ddump-simpl -O}}} I get: {{{ Rec { xs [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] xs = : False xs end Rec } Rec { ys [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] ys = : True ys end Rec } }}} However, if I mark {{{pair}}} as {{{INLINABLE}}} or {{{INLINE}}} (it doesn't matter which), I get much worse code where {{{xs}}} and {{{ys}}} go through {{{pair}}}: {{{ Rec { pair [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: ([Bool], [Bool]) [GblId, Str=DmdType m, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 50 30 Tmpl= (: False (case pair of _ { (xs1_Xf6 [Occ=Once], _) -> xs1_Xf6 }), : True (case pair of _ { (_, ys1_Xf6 [Occ=Once]) -> ys1_Xf6 }))}] pair = (a1_rgo, a_rgn) ys_ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] ys_ys = case pair of _ { (xs1_XeW, ys1_Xf7) -> ys1_Xf7 } a_rgn :: [Bool] [GblId, Str=DmdType] a_rgn = : True ys_ys xs_xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] xs_xs = case pair of _ { (xs1_XeW, ys1_XeS) -> xs1_XeW } a1_rgo :: [Bool] [GblId, Str=DmdType] a1_rgo = : False xs_xs end Rec } ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] ys = ys_ys xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] xs = xs_xs }}} It seems that GHC chooses {{{pair}}} as the loop breaker, which stops the simplifier in its tracks. It might seem a bit silly to mark {{{pair}}} as {{{INLINE}}}, since it's not mutually recursive. The function I really had was polymorphic with a typeclass constraint, and I wrote {{{INLINABLE}}} to get it specialised at its call site. (Also, {{{pair}}} is mutually recursive in the Core, so you would expect GHC to avoid using it as a loop breaker if I mark it {{{INLINE}}}.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8662: GHC does not inline cheap inner loop when used in two places
by GHC 04 Aug '16

04 Aug '16

#8662: GHC does not inline cheap inner loop when used in two places ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When I made a Criterion benchmark of Neil Michell's "Tight Inner Loop" blog post (http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell- for-tight-inner-loop.html), I noticed that GHC 7.6.3 will not inline the performance-critical function when it's called from two different places (inside the same module). {{{ break0_2pleaseinline :: (Char -> Bool) -> ByteString0 -> (ByteString, ByteString0) break0_2pleaseinline f (BS0 bs) = (BS.unsafeTake i bs, BS0 $ BS.unsafeDrop i bs) where i = Internal.inlinePerformIO $ BS.unsafeUseAsCString bs $ \ptr -> do let start = castPtr ptr :: Ptr Word8 let end = go start return $! Ptr end `minusPtr` start go s@(Ptr a) | c == '\0' || f c = a | otherwise = go $ inc s where c = chr s versionInl1 :: ByteString0 -> (ByteString, ByteString0) versionInl1 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') versionInl2 :: ByteString0 -> (ByteString, ByteString0) versionInl2 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') }}} Full code here: https://github.com/nh2/inner-loop- benchmarks/blob/6715d1e9946d6b5e6d9bb53203982ed3d2ed32ff/Bench.hs#L166. {{{break0_2pleaseinline}}} does not get inlined, which makes {{{versionInl1}}} and {{{versionInl2}}} over 4 times slower than when inlined. The inlining doens't happen, not even with {{{-O2}}} and {{{-O3}}}, only an {{{INLINE}}} pragma will move GHC to do it. If I was a compiler, I would so inline that function! I am surprised that GHC doesn't decide to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8814: 7.8 optimizes attoparsec improperly
by GHC 04 Aug '16

04 Aug '16

#8814: 7.8 optimizes attoparsec improperly ------------------------------+-------------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import qualified Data.Attoparsec.Text as A import Data.Text (Text) import qualified Data.Text as T testParser :: Text -> Either String Int testParser f = fmap length . A.parseOnly (many (A.char 'b' <|> A.anyChar)) $ f main :: IO () main = print . testParser $ T.replicate 50000 "a" }}} On GHC 7.6.3 with `-O2`: {{{ real 0m0.062s user 0m0.022s sys 0m0.007s }}} On GHC 7.8 tip with `-O2`: {{{ real 0m12.700s user 0m12.504s sys 0m0.165s }}} On GHC 7.6.3 with `-O0`: {{{ real 0m0.077s user 0m0.025s sys 0m0.007s }}} On GHC 7.8 tip with `-O0`: {{{ real 0m0.055s user 0m0.026s sys 0m0.007s }}} This seems to be related to the use of `<|>`; if I change the program so that the second branch (`A.anyChar`) is never taken, 7.8 behavior is roughly the same as 7.6 under any optimization level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20