September 2017 - ghc-tickets

[GHC] #14003: Allow more worker arguments in SpecConstr
by GHC 11 Oct '17

11 Oct '17

#14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Keywords: JoinPoints, | Operating System: Unknown/Multiple Fusion | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting with GHC 8.2 (rc1 -- head) I noticed that the SpecConstr pass does not always optimize completely with SpecConstr-heavy code. Setting ```-fmax-worker-args=100``` leads to complete specialization again. However, given that code annotated with ```SPEC``` should be optimized until no more ```SPEC``` arguments are alive, shouldn't ```callToNewPats``` in ```compiler/specialise/SpecConstr.hs``` specialize *irrespective* of the size of the worker argument list? Code that actually fails to specialize is fairly large, hence no test case -- though I have some files with core output showing insufficient specialization. (I'd be willing to write a patch for this) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14289: Pretty-printing of derived multi-parameter classes omits necessary parentheses
by GHC 11 Oct '17

11 Oct '17

#14289: Pretty-printing of derived multi-parameter classes omits necessary parentheses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Parser) | 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: -------------------------------------+------------------------------------- Take this file: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} import Language.Haskell.TH class C a b main :: IO () main = putStrLn $([d| data Foo a = Foo a deriving (C a) |] >>= stringE . show) }}} When this is compiled, `-ddump-splices` does not faithfully print back what was written by the user: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:19-77: Splicing expression [d| data Foo_a4l1 a_a4l3 = Foo_a4l2 a_a4l3 deriving C a_a4l3 |] >>= stringE . show ======> "[DataD [] Foo_6989586621679026555 [PlainTV a_6989586621679026557] Nothing [NormalC Foo_6989586621679026556 [(Bang NoSourceUnpackedness NoSourceStrictness,VarT a_6989586621679026557)]] [DerivClause Nothing [AppT (ConT Main.C) (VarT a_6989586621679026557)]]]" }}} In particular, this pretty-prints `deriving C a_a4l3`, which doesn't even parse correctly. It should print `deriving (C a_a4l3)`. Ultimately, there is an off-by-one error in the number of parentheses being printed, since if you tweak the original example by adding another set of parentheses: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} import Language.Haskell.TH class C a b main :: IO () main = putStrLn $([d| data Foo a = Foo a deriving ((C a)) |] >>= stringE . show) }}} Then it pretty-prints exactly one set of parentheses (as opposed to two): {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:19-79: Splicing expression [d| data Foo_a1zI a_a1zK = Foo_a1zJ a_a1zK deriving (C a_a1zK) |] >>= stringE . show ======> "[DataD [] Foo_6989586621679026522 [PlainTV a_6989586621679026524] Nothing [NormalC Foo_6989586621679026523 [(Bang NoSourceUnpackedness NoSourceStrictness,VarT a_6989586621679026524)]] [DerivClause Nothing [AppT (ConT Main.C) (VarT a_6989586621679026524)]]]" }}} There are two suspicious parts of the GHC codebase that contribute to this bug: * This parser production: http://git.haskell.org/ghc.git/blob/4364f1e7543b6803cfaef321105d253e0bdf08a… This recognizes singleton derived classes that are surrounded by a set of parentheses, and "strips off" the parentheses. * This `Outputable` instance: http://git.haskell.org/ghc.git/blob/4364f1e7543b6803cfaef321105d253e0bdf08a… This code detects lists of two or more derived classes and surrounds them with extra parentheses to make up for the set that was removed during parsing. But this fails to detect the case of `deriving (C a)`, since this only contains a single class. Indeed, trying to distinguish between, say, `deriving T` and `deriving (T)` at this level would be quite tricky. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10816: Fixity declaration for associated type rejected
by GHC 11 Oct '17

11 Oct '17

#10816: Fixity declaration for associated type rejected -------------------------------------+------------------------------------- Reporter: goldfire | 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 Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} module Bug where class C a where type a # b infix 4 # }}} I get {{{ Bug.hs:7:11: ‘#’ is not a (visible) method of class ‘C’ }}} But it really should just assign a fixity to the type `#`. It works if the fixity declaration is outside of the class. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO
by GHC 09 Oct '17

09 Oct '17

#14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When ghc 8.2.1 compiled using DYNAMIC_GHC_PROGRAMS=NO attemps at using TH results in all sorts of exciting errors: source files: {{{ % cat A.hs {-# LANGUAGE TemplateHaskell #-} module Numeric.Sum where import B b }}} this file makes little sense, but it was segfaulting when it had more code as well {{{ % cat B.hs {-# LANGUAGE TemplateHaskellQuotes #-} module B where import Language.Haskell.TH b :: DecsQ b = return [ InstanceD Nothing [] (ConT ''Show `AppT` undefined) [] ] }}} Let's try running it a few times - note illegal hardware instruction {{{ % ghc -O2 A.hs [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: illegal hardware instruction ghc -O2 A.hs % ghc -O2 A.hs [2 of 2] Compiling Numeric.Sum ( A.hs, A.o ) zsh: segmentation fault ghc -O2 A.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #13652: Add integer division to GHC.TypeLits
by GHC 08 Oct '17

08 Oct '17

#13652: Add integer division to GHC.TypeLits -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- GHC.TypeLits currently lacks integer division type families and I can't see why. What is the reason for not having these methods of the `Integral` class at type level: {{{#!hs quot rem div mod quotRem divMod }}} ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14256: GHCi is faster than compiled code
by GHC 06 Oct '17

06 Oct '17

#14256: GHCi is faster than compiled code -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- A stackoverflow user Milad Zahedi reports that running his code in GHCi is 50x faster than compiling it and running the compiled binary. > Today I did little benchmarking on my local machine to compare plain text speed of different Haskell web frameworks, and I noticed something strange. Almost all the frameworks that I tested, performed better when they were run from GHCi compared to compiled version. here are my results > {{{ +------------------------------------ |framework| GHCi rpm | compiled rpm +---------+------------+------------- |snap | 8000 | 150 +---------+------------+------------- |yesod | 6000 | 2500 +---------+------------+------------- |scotty | 22000 | 9500 +---------+------------+------------- |servant | 17000 | 8500 +---------+------------+------------- |spock | 3300 | 2700 +---------+------------+------------- }}} > I know that these numbers do not reflect on these frameworks speed, since they are not well tuned or optimized, but my question is why are these frameworks performing better when launched from GHCi. Am I doing something wrong ? > > in order to build them I simply run stack build The benchmarks are from https://github.com/miladz68/haskell-webframework- comparison This ticket is to verify and investigate these claims. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14300: FreeBSD 10.3 toolchain is terribly broken
by GHC 05 Oct '17

05 Oct '17

#14300: FreeBSD 10.3 toolchain is terribly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13974 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == `ld.bfd` with `SplitSections=NO` Fails in the final bindist test with, {{{ /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben /bin- dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" [1 of 1] Compiling Main ( /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.o ) Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) ... }}} == `ld.bfd` with `SplitSections=YES` fails with, {{{ ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14279: Type families interfere with specialisation rewrite rules
by GHC 05 Oct '17

05 Oct '17

#14279: Type families interfere with specialisation rewrite rules -------------------------------------+------------------------------------- Reporter: IvanTimokhin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the attached file, in particular the function {{{#!hs vinr :: Length as -> VSum bs -> VSum (as ++ bs) }}} its specialised version {{{#!hs vinr0 :: Length '[] -> VSum as -> VSum as }}} and the rewrite rule {{{#!hs {-# RULES "vinr/0" vinr = vinr0 #-} }}} According to [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… the relevant section of GHC user guide], `vinr` should be replaced with `vinr0` whenever the types match. However, the resulting Core for `test` contains the following (compiled with `ghc -O2`): {{{#!hs Test.test1 = case extractIdx @ 'Z @ '[Int] @ Int (Test.$WIZ @ Int @ '[]) Test.test2 of { Left other_aZf -> Test.$wvinl @ Length @ '[Int] @ (Remove 'Z '[Int]) other_aZf; Right x_aZg -> vinr @ (Remove 'Z '[Int]) @ '[Int] (Test.$WLZ `cast` ((Length (Sym (Test.D:R:Remove[0] <Int>_N <'[]>_N)))_R :: (Length '[] :: *) ~R# (Length (Remove 'Z '[Int]) :: *))) (Test.VInL @ '[Int] @ Int @ '[] @~ (<'[Int]>_N :: ('[Int] :: [*]) GHC.Prim.~# ('[Int] :: [*])) x_aZg) } }}} So the rule never fires, and `vinr` is still there, even though it is directly applied to `LZ :: Length '[]`. My dilettante analysis is that, for some reason, GHC keeps the `Remove 'Z '[Int]` as-is, not evaluating it to `'[]`, and, since the types don't match //syntactically//, doesn't apply the rule. In particular, if I replace type families with classes with functional dependencies, the rule fires as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14222: Simple text fusion example results in rather duplicative code
by GHC 05 Oct '17

05 Oct '17

#14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Consider this program, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} Compiling with `-O` results in over 1 kilobyte of assembler. After looking at the simplified Core the issue becomes apparent: the case analysis of `isNumeric'` is duplicated six times, {{{#!hs case ww4_X2zB of { __DEFAULT -> GHC.Types.False; '+'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '-'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '.'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'E'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'e'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#) }; }}} It seems to me that we would ideally try to share this bit. Of course, this may be quite tricky to do in practice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14292: Coercing between constraints of newtypes
by GHC 04 Oct '17

04 Oct '17

#14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- This doesn't work {{{#!hs {-# Language ConstraintKinds #-} {-# Language GADTs #-} import Data.Coerce newtype USD = USD Int data Dict c where Dict :: c => Dict c num :: Dict (Num Int) -> Dict (Num USD) num = coerce }}} but this does {{{#!hs data NUM a = NUM (a -> a -> a) num' :: NUM Int -> NUM USD num' = coerce }}} is this a fundamental limitation? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11