June 2016 - ghc-tickets

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 05 Jun '16

05 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D2304 Comment: I've found a little trick to help reduce the constant factors in deriving `Generic`. (See Phab:D2304 for more details.) One can factor out the topmost `M1` from the derived definitions of `to` and `from` to reduce the number of times GHC has to typecheck an application of `M1`. This in turn leads to a reduction in the number of coercions, which lowers allocation. I tested this trick against basvandijk's 300-constructor datatype, and it saves almost 3 seconds of compilation time and uses ~6.4 times fewer coercions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #365: GHC dies silently with faulty preprocessor
by GHC 05 Jun '16

05 Jun '16

#365: GHC dies silently with faulty preprocessor ---------------------------------+---------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1256 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by NeilMitchell): Using ShellExecute would probably be the wrong thing to do in this instance. ShellExecute is the right thing to "execute" (or Open) a file in the same way as the "Shell" (e.g. Windows Explorer) would do. In other words, its a generic "open this file" mechanism, not something to run command line tools, which is what you really want here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/365#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12154: GHC 8.0.1 x64 Windows installer doesn't honor custom install location
by GHC 05 Jun '16

05 Jun '16

#12154: GHC 8.0.1 x64 Windows installer doesn't honor custom install location -------------------------------------+------------------------------------- Reporter: scs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The GHC Windows installer has (thankfully!) the option for a preferred custom install location, in my case 'c:\devel\Haskell\8' (beside 'c:\devel\Haskell\WinHugs' etc.) However, it obstinately installs into 'c:\Program Files\Haskell Platform\yada yada...' The _uninstaller_ operates with the custom location, and the uninstallation therefore fails. Potential triggers: disallowing the installer to muck with the environment path and registry (I set these myself, thank you very much). Workaround: GHC is thankfully still self contained, and moving the installation to the preferred location suffices. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2
by GHC 05 Jun '16

05 Jun '16

#10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2 -----------------------------------------+--------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- When compiling with the RC for Stackage, I get: {{{ [1 of 1] Compiling Main ( examples/Rg.hs, dist/build/Rg/Rg- tmp/Main.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150619 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone bindIO To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 19573 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12153: Bug in pattern synonyms with template haskell
by GHC 05 Jun '16

05 Jun '16

#12153: Bug in pattern synonyms with template haskell -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- #8761 added template haskell support for pattern synonyms, but I believe the implementation has a bug. If I create the following template Haskell syntax trees: {{{ PatSynD AST_sin (RecordPatSyn [a0]) Unidir (ConP HomFree [ViewP (VarE embedSig) (ConP HomSig_sin [VarP a0])]) PatSynD AST_cos (RecordPatSyn [a0]) Unidir (ConP HomFree [ViewP (VarE embedSig) (ConP HomSig_cos [VarP a0])]) }}} the compiler complains that `a0` is being redefined. Of course, this should be allowed because `a0` is local to each pattern synonym. A temporary workaround is to rename each variable to be unique to the pattern. The following template haskell compiles just fine. {{{ PatSynD AST_sin (RecordPatSyn [a0_sin]) Unidir (ConP HomFree [ViewP (VarE embedSig) (ConP HomSig_sin [VarP a0_sin])]) PatSynD AST_cos (RecordPatSyn [a0_cos]) Unidir (ConP HomFree [ViewP (VarE embedSig) (ConP HomSig_cos [VarP a0_cos])]) }}} This is with GHC 8.1.20160518 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12139: Add TUI (text-based user interface) for GHCi
by GHC 04 Jun '16

04 Jun '16

#12139: Add TUI (text-based user interface) for GHCi -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- GDB has a really nice TUI mode: https://upload.wikimedia.org/wikipedia/commons/4/47/GDB_TUI.png It's a curses interface which highlights the line number you're on, and also shows the surrounding lines. GHCi currently allows stepping through with the `:step` command, which displays line and column numbers. It would be nice to have some visual indication along with these numbers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11816: Refactor SymbolInfo out of Linker.c
by GHC 04 Jun '16

04 Jun '16

#11816: Refactor SymbolInfo out of Linker.c -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11223 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #11223 added a type `SymbolInfo` to `ObjectCode`. This is adding a larger memory overhead to the RTS then need by. `SymbolInfo` is used to determine if a symbol is weak or not. This information can be moved into it's own structure inside `ObjectCode` like a map. Since the majority of the symbols will not be weak this map should be fairly small. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12138: Simplifier ticks exhausted at compiling svg-builder
by GHC 04 Jun '16

04 Jun '16

#12138: Simplifier ticks exhausted at compiling svg-builder -------------------------------------+------------------------------------- Reporter: JanUlrich | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to install svg-builder by "cabal install svg-builder"and got the following error: Resolving dependencies... Configuring svg-builder-0.1.0.1... Building svg-builder-0.1.0.1... Preprocessing library svg-builder-0.1.0.1... [1 of 5] Compiling Graphics.Svg.Path ( src/Graphics/Svg/Path.hs, dist/build/Graphics/Svg/Path.o ) [2 of 5] Compiling Graphics.Svg.Core ( src/Graphics/Svg/Core.hs, dist/build/Graphics/Svg/Core.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableWord21{v r2cT} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 34200 I tried again with ghc -fsimpl-tick-factor=300 and it worked. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7437: peculiar behaviour with default instances and type variables
by GHC 04 Jun '16

04 Jun '16

#7437: peculiar behaviour with default instances and type variables -------------------------------------+------------------------------------- Reporter: bos | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #12151 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #12151 Comment: I wished I had added that test already, because now this issue has regressed. See #12151. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7437#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12129: Optimize the implementation of minusInteger in the integer-gmp package
by GHC 04 Jun '16

04 Jun '16

#12129: Optimize the implementation of minusInteger in the integer-gmp package -------------------------------------+------------------------------------- Reporter: admock | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As mentioned in [https://www.fpcomplete.com/blog/2016/05/weigh-package] the current implementation of `minusInteger` is {{{#!hs minusInteger x y = inline plusInteger x (inline negateInteger y) }}} which always allocates an additional integer. This could be improved by not always calling `negateInteger` and instead having an implementation more like `plusInteger`'s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5