- ghc-tickets - Haskell.org

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 06 Jun '16

06 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"48e9a1f5521fa3185510d144dd28a87e452ce134/ghc" 48e9a1f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48e9a1f5521fa3185510d144dd28a87e452ce134" Implement deterministic CallInfoSet We need CallInfoSet to be deterministic because it determines the order that the binds get generated. Currently it's not deterministic because it's keyed on `CallKey = [Maybe Type]` and `Ord CallKey` is implemented with `cmpType` which is nondeterministic. See Note [CallInfoSet determinism] for more details. Test Plan: ./validate Reviewers: simonpj, bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2242 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 06 Jun '16

06 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"3042a9d8d55b4706d2ce366fee1712c7357d5a00/ghc" 3042a9d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3042a9d8d55b4706d2ce366fee1712c7357d5a00" Use UniqDFM for HomePackageTable This isn't strictly necessary for deterministic ABIs. The results of eltsHpt are consumed in two ways: 1) they determine the order of linking 2) if you track the data flow all the family instances get put in FamInstEnvs, so the nondeterministic order is forgotten. 3) same for VectInfo stuff 4) same for Annotations The problem is that I haven't found a nice way to do 2. in a local way and 1. is nice to have if we went for deterministic object files. Besides these maps are keyed on ModuleNames so they should be small relative to other things and the overhead should be negligible. As a bonus we also get more specific names. Test Plan: ./validate Reviewers: bgamari, austin, hvr, ezyang, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2300 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12135: Failure to recompile when #include file is created earlier on include path
by GHC 06 Jun '16

06 Jun '16

#12135: Failure to recompile when #include file is created earlier on include path -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | 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: -------------------------------------+------------------------------------- Originally discovered when trying to improve Hadrian, for context see: https://github.com/snowleopard/hadrian/issues/247#issuecomment-222317602 If you create a file {{{Test.hs}}} {{{#!hs #include "a/Test.hs" main = print message }}} And a file {{{a/Test.h}}} {{{#!hs message = 1 }}} Then run and compile with {{{ghc --make -XCPP -Ib;a Main.hs}}} it compiles and runs properly, printing 1. Changing {{{a/Test.h}}} to {{{message = 2}}} then running {{{ghc}}} rebuilds and prints 2. Creating a fresh {{{b/Test.h}}} with {{{message = 3}}} does not cause {{{ghc}}} to recompile, and thus incorrectly still prints 2. Touching {{{Main.hs}}} causes recompilation, and then the correct header file is picked up, resulting in 3 being printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

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

06 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 06 Jun '16

06 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 05 Jun '16

05 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