- ghc-tickets - Haskell.org

[GHC] #13406: IO hack in demand analyzer can miss I/O
by GHC 10 Mar '17

10 Mar '17

#13406: IO hack in demand analyzer can miss I/O -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- If someone digs into the `IO` type, they could (with good reason, even!) decide that they want to produce something other than an unboxed pair. Here's an example, imitating `StateT st IO a` in a way that's sure to be unboxed well: {{{#!hs newtype IOState st a = IOState { unIOState :: State# RealWorld -> st -> (# State# RealWorld, st, a #) } }}} This won't trip `io_hack_reqd`, so demand analysis won't see it as I/O, and everything will be wrong. Urk. Furthermore, in the future, we may allow newtypes around unlifted types, in which case this stuff gets even messier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4083: Generalized newtype deriving fails for newtypes that are type family instances
by GHC 10 Mar '17

10 Mar '17

#4083: Generalized newtype deriving fails for newtypes that are type family instances -------------------------------------+------------------------------------- Reporter: RANDY Ruler of | Owner: (none) Zexernet | Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): For type families see #13404 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4083#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13402: GHC .prof tabular output glues columns together
by GHC 10 Mar '17

10 Mar '17

#13402: GHC .prof tabular output glues columns together -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After profiling an application i can see output like this: {{{ mkFareSegment Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150 88315 0.1 0.0 0.2 0.1 }}} Columns are glued together in this particular part: `Amadeus.Semantic.MasterPricer.Conversion.Offer.FareSegments204150` It's a work project, so i won't attach the whole .prof file, but it seems that the issue occurs when the fully qualified name is too long. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1106: During install, network's Typeable.h clobbers base's copy
by GHC 10 Mar '17

10 Mar '17

#1106: During install, network's Typeable.h clobbers base's copy -------------------------------------+--------------------------------- Reporter: bos | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: -------------------------------------+--------------------------------- Changes (by Joachim Breitner <mail@…>): * failure: => None/Unknown Comment: In [changeset:"712c45d035797a392e33bba3f8ec4293af61ecab/ghc" 712c45d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="712c45d035797a392e33bba3f8ec4293af61ecab" integerConstantFolding: no longer broken with -DDEBUG (#1106) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1106#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13177: Give Data.Functor.* its lifted unit and void
by GHC 09 Mar '17

09 Mar '17

#13177: Give Data.Functor.* its lifted unit and void -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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.Generics` has {{{#!hs data U1 a = U1 data V1 a }}} They are simple but why are they not present in the `Data.Functor` hierarchy along with functions like (from [https://hackage.haskell.org/package/one-liner-0.7/docs/src/Generics- OneLiner-Internal.html one-liner]) {{{#!hs absurd :: V1 a -> b absurd = \case }}} Packages like [https://hackage.haskell.org/package/linear linear] provide basically the same lifted functors {{{#!hs data V0 a = V0 newtype V1 a = V1 a }}} if they or those from `GHC.Generics` should be preferred it could be added to the documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals
by GHC 09 Mar '17

09 Mar '17

#13395: 3x slowdown on GHC HEAD with file containing lots of overloaded string literals -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- I just noticed that compiling `xmlhtml-0.2.3.5` from Hackage takes an extraordinarily long time on GHC HEAD. The slowdown can be attributed to the `Text.XmlHtml.HTML.Meta` module. I've extracted it and tweaked it so that it requires no dependencies to build (I now use `ByteString` instead of `Text`, but the slowdowns for both types were about the same.) On GHC 8.0.2, it takes about 3 seconds to compile the attached module: {{{ $ /usr/bin/time /opt/ghc/8.0.2/bin/ghc -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 3.44user 0.07system 0:03.51elapsed 99%CPU (0avgtext+0avgdata 208480maxresident)k 0inputs+21688outputs (0major+43934minor)pagefaults 0swaps }}} But on GHC HEAD, it takes about 10 seconds: {{{ $ /usr/bin/time ~/Software/ghc2/inplace/bin/ghc-stage2 -fforce-recomp TextXmlHtmlHTMLMeta.hs [1 of 1] Compiling Text.XmlHtml.HTML.Meta ( TextXmlHtmlHTMLMeta.hs, TextXmlHtmlHTMLMeta.o ) 9.93user 0.11system 0:10.03elapsed 100%CPU (0avgtext+0avgdata 233656maxresident)k 0inputs+21464outputs (0major+54853minor)pagefaults 0swaps }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13341: Lift constraint products
by GHC 09 Mar '17

09 Mar '17

#13341: Lift constraint products -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- I want to get a discussion going, could we lift constraint products automatically. Although not partially applicable, we can consider `(,)` as having kind {{{#!hs (,) :: Constraint -> Constraint -> Constraint }}} I propose also giving it kinds {{{#!hs (,) :: (k -> Constraint) -> (k -> Constraint) -> (k -> Constraint) (,) :: (k -> k' -> Constraint) -> (k -> k' -> Constraint) -> (k -> k' -> Constraint) -- etc. }}} == Translation {{{#!hs (Eq, Num, Show) (Monad, Foldable) (Category, Profunctor) }}} gets turned into something like {{{#!hs class (c a, d a) => (c :&: d) a instance (c a, d a) => (c :&: d) a infixl 7 :&: Eq:&:Num:&:Show Monad:&:Foldable Category:&:Profunctor }}} == Uses Very often I need to be able to combine constraints. A small modification of [https://hackage.haskell.org/package/free- functors-0.7.2/docs/Data-Constraint-Class1.html SuperClasses] {{{#!hs type c :~ d = forall xx. c x :- d xx class HasSuperClasses (c :: k -> Constraint) where type SuperClasses c :: k -> Constraint type SuperClasses c = c superClasses :: c :~ SuperClasses c containsSelf :: SuperClasses c :~ c instance HasSuperClasses Functor where superClasses :: Functor :~ Functor superClasses = Sub Dict containsSelf :: Functor :~ Functor containsSelf = Sub Dict instance HasSuperClasses Foldable where superClasses :: Foldable :~ Foldable superClasses = Sub Dict containsSelf :: Foldable :~ Foldable containsSelf = Sub Dict }}} I want to be able to write {{{#!hs instance HasSuperClasses Traversable where type Traversable = (Traversable, Functor, Foldable) superClasses :: Traversable :~ (Traversable, Functor, Foldable) superClasses = Sub Dict containsSelf :: (Traversable, Functor, Foldable) :~ Traversable containsSelf = Sub Dict }}} If this doesn't pose any difficulties I'll open a GHC proposal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13341> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 08 Mar '17

08 Mar '17

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Just a quick update, I've gone through about 4 rewrite of the core parts of this patch. The biggest issue is with how GHC accesses const data. This forces me to essentially write a unix like dynamic loader in the binaries because of how closures and info tables are accessed. Or use bounded imports and forgo the ability to use ASLR with GHC applications, which is a heavy price. Also `dlltool` is very slow, too slow to be usable at the scale required. GHC has managed to bloat up to a size where it has to be split into 3 DLLs (nearing a 4th). The automatic splitting works fine, but the resulting import libraries require `dlltool` to process 3x ~65k symbols. Which it takes half an hour to do and generates huge file sizes. This is because the way import libraries are implemented in binutils is a hack. Microsoft's own `lib.exe` tool does this in seconds and creates a much much smaller file. This means I also have to write a tool to generate import libraries in their short format for use by GHC. I still expect to finish by `8.4.1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: Forec
by GHC 08 Mar '17

08 Mar '17

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

1 0

[GHC] #8255: GC Less Operation
by GHC 08 Mar '17

08 Mar '17

#8255: GC Less Operation ------------------------------+-------------------------------------------- Reporter: sirinath | Owner: Type: feature | Status: new request | Milestone: Priority: highest | 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: | ------------------------------+-------------------------------------------- Hi, Is it possible to eliminated GC through Automatic Reference Counting (ARC) like in Objective C / Clang. S -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13