February 2017 - ghc-tickets

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 20 Feb '17

20 Feb '17

#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 7535 Related Tickets: #9839 #13308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #9839 => #9839 #13308 Comment: When parsing arguments to flags ghc treats leading whitespace different depending on the flag. ghc +RTS '-N 2' -s -RTS --version Here '-N 2' is parsed as -N2 ghc +RTS '-s file' -RTS --version Here '-N 2' is parsed as '\ file', a filename starting with a space. If this rework ever happens leading spaces in arguments should either be uniformly ignored or treated as errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13308: Treat leading whitespace in rts flag arguments in a uniform way
by GHC 20 Feb '17

20 Feb '17

#13308: Treat leading whitespace in rts flag arguments in a uniform way -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4243 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When parsing argument flags ghc treats leading whitespace different depending on the flag. * `ghc +RTS '-N 2' -s -RTS --version` Here '-N 2' is parsed as -N2 * `ghc +RTS '-s file' -RTS --version` Here '-N 2' is parsed as '\ file', a filename starting with a space. * `ghc +RTS -N 2 -s -RTS --version` Here `2` is a unexpected argument. The usage info indicates no space is allowed in between flags and arguments making the first point a minor bug. It's never an issue when executing from a shell since it filters out unquoted spaces, however it can trip someone up when passing arguments explicitly via exec. If we remove leading spaces for file names however we make it impossible to use filenames starting with whitespace since we cant tell if the space was included by accident or quoted by the shell. But I also have never seen a file starting with whitespace that was created intentionally so maybe that is a worthwhile tradeoff. If the argument Parser #4243 ever get's rewritten maybe this could be made uniform one way or the other. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13308> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 20 Feb '17

20 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The main difference seems to come from this change... Interesting! There are two changes in that commit: * Making data con wrappers have `ug_unsat_ok = unSaturatedOk`. I buy this. Can you try the effect of this change alone? It's entirely unrelated to nested-CPR. It would be good to isolate that perf bump from the perf changes due to nested CPR. * Making data con wrapper have `ug_boring_ok = boringCxtOk`. I'm not sure I buy this in full. In `Note [Inline data constructor wrappers aggresively]` there's a claim that we get better nested-CPR info. That's true if we have a polymorphic bang argument (e.g. `data T a = MkT !a`) but for a monomorphic one like `data S = MkS !Int` we'll unpack it. So I think the benefit comes only for polymorphic bangs. And there is a cost to aggressive inlining, so we don't want to do it gratuitously. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:65> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 20 Feb '17

20 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): == mandel and gcd The main difference seems to come from [https://github.com/takano- akio/ghc/commit/1edc47406dd2f5da9925978b01a1724028bd576e this change], which makes `integer-gmp` allocate less by inlining wrappers for `S#`, `Jp#` etc. Actually this small change seems to be responsible for the much of the allocation improvement in this branch: {{{ gcd +0.8% -21.4% 0.039 0.040 0.0% integer +1.1% -1.5% +5.0% +5.1% 0.0% mandel +1.1% -24.4% 0.070 0.070 0.0% -------------------------------------------------------------------------------- Min -0.0% -24.4% -38.7% -38.5% 0.0% Max +1.1% 0.0% +13.7% +13.6% +14.4% Geometric Mean +0.3% -0.6% -6.9% -6.9% +0.1% }}} Perhaps I should try go get this change merged, separately from the rest of the nested CPR work. == Binary size increase I had a brief look at `nofib/real/fluid/Jcb_method.hs`, which showed a +60% increase in the binary size, but I wasn't able to figure out why the change happened. !SpecConstr now seems to duplicate a big function, but I don't know what caused this (yet). == Wiki page I think the content under wiki:NestedCPR is mostly valid, because all I have done so far is essentially just to rebase nomeata's branch on top of the join-point commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:64> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13303: Bad pretty printer for let bindings in a do-notation with braces
by GHC 20 Feb '17

20 Feb '17

#13303: Bad pretty printer for let bindings in a do-notation with braces -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: do-notation, | Operating System: Unknown/Multiple let, parse | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let bindings in do-notations with braces like this: {{{#!hs module Thing where thing = do {let {x = 1}; print x} }}} get pretty printed with the braces around the bindings stripped, like this: {{{#!hs module Thing where thing = do {let x = 1; print x} }}} Steps to reproduce: copy the module into Try.hs then call: ghc -ddump-rn Try.hs I traced the code to: https://github.com/ghc/ghc/blob/e28fbbb7c3d5904a88b4743d0d10f212d61d8293/co… which points to the pretty printer for list of declarations: https://github.com/ghc/ghc/blob/95dc6dc070deac733d4a4a63a93e606a2e772a67/co… Indeed there is a comment on the two ways to pretty print binders - without braces in multiple lines and with braces in one line. However the comment does not explain the choice, and as discussed in #13302 the former won't parse in a do-notation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13302: Let in do-notation with braces does not parse
by GHC 20 Feb '17

20 Feb '17

#13302: Let in do-notation with braces does not parse -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: do-notation, | Operating System: MacOS X let, parse | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the the syntax at https://www.haskell.org/onlinereport/haskell2010/haskellch10.html the following do-notation should parse: {{{#!hs do {let x = 4; print x} }}} But it doesn't. {{{#!hs do {let x = 4 in print x} }}} parses OK. Doesn't look like a new bug, I tried with GHC 7.8 and same result. Googling "haskell do {let ds; es} = let ds in do {es}" also shows quite a lot of people taught Haskell that way, so maybe it once worked? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13251: Must perform family consistency check on non-imported identifiers
by GHC 20 Feb '17

20 Feb '17

#13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the family consistency check checks pairs of *imported* modules (and the modules they transitively import) for consistency. However, there are a number of mechanisms by which we can refer to an identifier from a module without explicitly importing it. Here is one example from Template Haskell: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Bool = String g :: F Bool g = "af" -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import A type instance F Bool = Int h :: F Bool -> IO () h = print -- D.hs {-# LANGUAGE TemplateHaskell #-} import C import Language.Haskell.TH.Syntax main = h $( return (VarE (Name (OccName "g") (NameG VarName (PkgName "main") (ModName "B")))) ) }}} This does an unsafe coerce: {{{ ezyang@sabre:~/Dev/labs/T13102$ ghc-head --make B.hs D.hs -fforce-recomp [1 of 4] Compiling A ( A.hs, A.o ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling C ( C.hs, C.o ) [4 of 4] Compiling Main ( D.hs, D.o ) Linking D ... ezyang@sabre:~/Dev/labs/T13102$ ./D 8070450533355229282 }}} Clearly, checking consistency on imports is not enough: we must also check up on original names that come by other mechanisms. (Other ways we can end up with identifiers without imports include overloading, see #13102. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] Trac email verification for user: sukhmel
by GHC 20 Feb '17

20 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=UdTLQgli> Username: sukhmel Verification Token: UdTLQgli -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: blaze
by GHC 19 Feb '17

19 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=sU7Movb5> Username: blaze Verification Token: sU7Movb5 -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #149: missed CSE opportunity
by GHC 18 Feb '17

18 Feb '17

#149: missed CSE opportunity --------------------------------------------+------------------------------ Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | --------------------------------------------+------------------------------ Changes (by AndreasK): * Attachment "CriterionBenchFixed2.hs" added. Updated test -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0