March 2018 - ghc-tickets

[GHC] #12619: Allow users guide to be built independently from GHC
by GHC 19 Mar '18

19 Mar '18

#12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new 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: -------------------------------------+------------------------------------- At HIW 2016 it was suggested that this would greatly reduce the friction to contributing users guide fixes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14886: Add max GC pause to GHC.Stats/-t --machine-readable
by GHC 19 Mar '18

19 Mar '18

#14886: Add max GC pause to GHC.Stats/-t --machine-readable -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Sometimes we're interested in latency of our programs. Often the upper highest percentiles are by garbage collector pauses due to stop-the-world implementation. It seems that currently the only way to see the highest pause is to use the {{{-s}}} flag or alternatively {{{-S}}}. This is problematic in two scenarios: 1. You don't have a human at the monitor parsing the {{{-s}}} output. 2. You are unable to get the maximum pause statistic programmatically inside the program itself. We do have {{{-t -machine-readable}}} which is nearly what I'd want but missing the actual pause information. Either that should include all the extra info from {{{-s}}} or {{{-s}}} should have machine-readable output format too. There is the {{{-S}}} option which will print garbage collections as they happen. We could parse and manually track the highest pause time but it requires an external process and a parser. If you want to get that information back into the process then you have to do even more work. {{{GHC.Stats}}} is of no help. It does not track or expose pause values. Even the "last GC info" APIs don't provide this (and they are not a solution anyway as you can only get info on last GC). I would therefore like to request two similar features: * Add relevant information from {{{-s}}} to {{{-t}}} machine readable output or add machine readable format option to {{{-s}}}. * Add maximum pause information to GHC.Stats interface. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14886> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14910: Bump required autoconf version
by GHC 19 Mar '18

19 Mar '18

#14910: Bump required autoconf version -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Autoconf should be set to a minimum of 2.69, to avoid this bug https://bugs.ruby-lang.org/issues/8179 specifically if using e.g. autoconf 2.64 things will fail with: {{{ configure:1510: error: possibly undefined macro: _m4_text_wrap_word If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14910> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12389: Limit duplicate export warnings for datatypes
by GHC 19 Mar '18

19 Mar '18

#12389: Limit duplicate export warnings for datatypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11959 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `containers` sometimes exports data constructors/patterns conditionally (depending on GHC version and whether `TESTING` is defined). Presently, to avoid a duplicate export warning, it's necessary to write a separate export line for each combination of exported constructors, which is horrible: {{{#!hs module Foo ( #ifdef TESTING #ifdef USE_PATTERN_SYNONYMS Foo (Foo, Pat1, Pat2) #else Foo (Foo) #endif #elif USE_PATTERN_SYNONYMS Foo (Pat1, Pat2) #else Foo #endif }}} or to break up the lines with CPP, which is so horrible I can't even bring myself to write it. I'd much rather be able to write {{{#!hs module Foo ( Foo #ifdef TESTING ,Foo(Foo) #endif #ifdef USE_PATTERN_SYNONYMS ,Foo(Pat1, Pat2) #endif ) }}} The trouble here is that GHC warns about duplicate export of the type `Foo`. I think there's a pretty simple partial solution: only warn about a type export that is *completely* redundant, adding neither type constructor nor pattern. And offer a way to turn off the redundant export warning entirely for types and classes without turning it off for bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #7398: RULES don't apply to a newtype constructor
by GHC 19 Mar '18

19 Mar '18

#7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6082, #10418, | Differential Rev(s): #13290 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: It doesn't look like this will happen for 8.6. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7398#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13386: Poor compiler performance with type families
by GHC 19 Mar '18

19 Mar '18

#13386: Poor compiler performance with type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs {-# LANGUAGE DataKinds, TypeApplications, TypeFamilies, TypeOperators, UndecidableInstances #-} {-# OPTIONS_GHC -freduction-depth=0 #-} module TypeFamilyPerf where import GHC.TypeLits type DivisibleBy x y = Help x y 0 (CmpNat x 0) type family Help x y z b where Help x y z EQ = True Help x y z LT = False Help x y z GT = Help x y (z+y) (CmpNat x z) foo :: DivisibleBy y 3 ~ True => proxy y -> () foo _ = () type N = 1002 k = foo @N undefined }}} On my machine `ghc-8.0.2 -O0` takes 4-5s to compile this module, with the time increasing as `N` increases (but note that it must be a multiple of 3, otherwise typechecking fails quickly). The problem seems to be that desugaring creates an enormous number of coercions in the representation of `k`. Perhaps this isn't terribly surprising, but I think we can do better. It should be possible to represent a proof of `DivisibleBy 1002 3 ~ True` compactly: the only information required should be the LHS and the number of reduction steps to take (and perhaps caching the RHS might be worthwhile). {{{ [1 of 1] Compiling TypeFamilyPerf ( TypeFamilyPerf.hs, TypeFamilyPerf.o ) *** Parser [TypeFamilyPerf]: !!! Parser [TypeFamilyPerf]: finished in 0.50 milliseconds, allocated 0.655 megabytes *** Renamer/typechecker [TypeFamilyPerf]: !!! Renamer/typechecker [TypeFamilyPerf]: finished in 91.70 milliseconds, allocated 58.617 megabytes *** Desugar [TypeFamilyPerf]: Result size of Desugar (after optimization) = {terms: 44, types: 70, coercions: 6,058} !!! Desugar [TypeFamilyPerf]: finished in 3781.83 milliseconds, allocated 8775.375 megabytes *** Simplifier [TypeFamilyPerf]: Result size of Simplifier iteration=1 = {terms: 27, types: 62, coercions: 6,060} Result size of Simplifier = {terms: 27, types: 62, coercions: 6,053} !!! Simplifier [TypeFamilyPerf]: finished in 42.93 milliseconds, allocated 68.321 megabytes *** CoreTidy [TypeFamilyPerf]: Result size of Tidy Core = {terms: 27, types: 62, coercions: 6,053} !!! CoreTidy [TypeFamilyPerf]: finished in 0.52 milliseconds, allocated 0.766 megabytes Created temporary directory: /tmp/ghc5526_0 *** CorePrep [TypeFamilyPerf]: Result size of CorePrep = {terms: 32, types: 74, coercions: 6,053} !!! CorePrep [TypeFamilyPerf]: finished in 0.37 milliseconds, allocated 0.160 megabytes *** Stg2Stg: *** CodeGen [TypeFamilyPerf]: !!! CodeGen [TypeFamilyPerf]: finished in 0.00 milliseconds, allocated 1.310 megabytes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5129: "evaluate" optimized away
by GHC 19 Mar '18

19 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615, Wiki Page: | Phab:D4514 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D615 => Phab:D615, Phab:D4514 Comment: Submitted a patch for this. Assuming we want to keep `seq#` pure (e.g. `has_side_effects = False` in the primop definition) I think hiding evaluate from the simplifier makes sense. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14940: GHC doesn't accept url specifying output file that is in a directory that is created by the -outputdir flag
by GHC 19 Mar '18

19 Mar '18

#14940: GHC doesn't accept url specifying output file that is in a directory that is created by the -outputdir flag --------------------------------------+--------------------------- Reporter: ntj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Command: {{{ ghc p.hs -outputdir simple -o simple/po }}} Output: {{{ <command line>: error: directory portion of "simple/po" does not exist (used with "-o" option.) }}} Directory "simple" does not exist before the time of compilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 19 Mar '18

19 Mar '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by bgamari): I think (1) is the best option given the amount of effort we have available to expend on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types
by GHC 19 Mar '18

19 Mar '18

#13776: -ddump-splices produces unnecessarily qualified names for tuple and list types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH f :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int) f = (1,2) g :: $(conT ''[] `appT` conT ''Int) g = [] }}} You'll get some unsavory output: {{{ Bug.hs:10:8-34: Splicing type conT ''[] `appT` conT ''Int ======> GHC.Types.[] Int Bug.hs:7:8-53: Splicing type conT ''(,) `appT` conT ''Int `appT` conT ''Int ======> GHC.Tuple.(,) Int Int }}} It's unsavory because if you actually try to use the spliced output in Haskell code: {{{#!hs module Bug2 where f :: GHC.Tuple.(,) Int Int f = (1,2) g :: GHC.Types.[] Int g = [] }}} Then it won't parse. Expressions have the same problem: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug3 where import Language.Haskell.TH f :: (Int, Int) f = $(conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1)) g :: [Int] g = $(conE '[]) }}} {{{ Bug3.hs:8:7-65: Splicing expression conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1) ======> (GHC.Tuple.(,) 1) 1 Bug3.hs:11:7-14: Splicing expression conE '[] ======> GHC.Types.[] }}} And patterns: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug4 where import Language.Haskell.TH f :: (Int, Int) -> () f $(conP '(,) [litP (integerL 1), litP (integerL 1)]) = () g :: [Int] -> () g $(conP '[] []) = () }}} {{{ Bug4.hs:8:5-52: Splicing pattern conP '(,) [litP (integerL 1), litP (integerL 1)] ======> GHC.Tuple.(,) 1 1 Bug4.hs:11:5-15: Splicing pattern conP '[] [] ======> GHC.Types.[] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9