August 2015 - ghc-tickets

[GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points
by GHC 21 Aug '15

21 Aug '15

#10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab: | D1007 | -------------------------------------+------------------------------------- Currently the type of the two mentioned entry points is {{{#!hs parseDeclaration :: P (OrdList (LHsDecl RdrName)) }}} and {{{#!hs parseTypeSignature :: P (Located (OrdList (LHsDecl RdrName))) }}} It turns out that in both cases, OrdList is always a singleton so the additional wrapping is redundant. I propose that the parser is modified in order to reflect this so that this is clearer to end users. The end result being that both entry points have type `P (LHsDecl RdrName)` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10567: Redundant parser entry point
by GHC 21 Aug '15

21 Aug '15

#10567: Redundant parser entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `stmt` parser is exposed under two different names. (`parseFullStmt` and `parseStatement`) It would be better to remove one of them (I would say `parseFullStmt`) in order to avoid confusion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1851: "make install-strip" should work
by GHC 21 Aug '15

21 Aug '15

#1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"47493e60fa2f8f520297969472dde01931530707/ghc" 47493e60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="47493e60fa2f8f520297969472dde01931530707" Build system: simplify install.mk.in This will allow fixing #1851 more easily ("make install-strip" should work). This reverts 57e2a81c589103b50da80a9e378b1a11285bd521: "On Cygwin, use a Cygwin-style path for /bin/install's destination" Update submodule haddock and hsc2hs. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1851#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC
by GHC 21 Aug '15

21 Aug '15

#1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"3452473b4bb180ba327520067b8c6f2a8d6c4f4b/ghc" 3452473b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3452473b4bb180ba327520067b8c6f2a8d6c4f4b" Delete FastBool This reverses some of the work done in Trac #1405, and assumes GHC is smart enough to do its own unboxing of booleans now. I would like to do some more performance measurements, but the code changes can be reviewed already. Test Plan: With a perf build: ./inplace/bin/ghc-stage2 nofib/spectral/simple/Main.hs -fforce-recomp +RTS -t --machine-readable before: ``` [("bytes allocated", "1300744864") ,("num_GCs", "302") ,("average_bytes_used", "8811118") ,("max_bytes_used", "24477464") ,("num_byte_usage_samples", "9") ,("peak_megabytes_allocated", "64") ,("init_cpu_seconds", "0.001") ,("init_wall_seconds", "0.001") ,("mutator_cpu_seconds", "2.833") ,("mutator_wall_seconds", "4.283") ,("GC_cpu_seconds", "0.960") ,("GC_wall_seconds", "0.961") ] ``` after: ``` [("bytes allocated", "1301088064") ,("num_GCs", "310") ,("average_bytes_used", "8820253") ,("max_bytes_used", "24539904") ,("num_byte_usage_samples", "9") ,("peak_megabytes_allocated", "64") ,("init_cpu_seconds", "0.001") ,("init_wall_seconds", "0.001") ,("mutator_cpu_seconds", "2.876") ,("mutator_wall_seconds", "4.474") ,("GC_cpu_seconds", "0.965") ,("GC_wall_seconds", "0.979") ] ``` CPU time seems to be up a bit, but I'm not sure. Unfortunately CPU time measurements are rather noisy. Reviewers: austin, bgamari, rwbarton Subscribers: nomeata Differential Revision: https://phabricator.haskell.org/D1143 GHC Trac Issues: #1405 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1405#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC
by GHC 21 Aug '15

21 Aug '15

#1405: Make ghc (stage1) be compilable by non-GHC -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2f29ebbb6f8c914f2bba624f3edcc259274df8af/ghc" 2f29ebb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f29ebbb6f8c914f2bba624f3edcc259274df8af" Refactor: delete most of the module FastTypes This reverses some of the work done in #1405, and goes back to the assumption that the bootstrap compiler understands GHC-haskell. In particular: * use MagicHash instead of _ILIT and _CLIT * pattern matching on I# if possible, instead of using iUnbox unnecessarily * use Int#/Char#/Addr# instead of the following type synonyms: - type FastInt = Int# - type FastChar = Char# - type FastPtr a = Addr# * inline the following functions: - iBox = I# - cBox = C# - fastChr = chr# - fastOrd = ord# - eqFastChar = eqChar# - shiftLFastInt = uncheckedIShiftL# - shiftR_FastInt = uncheckedIShiftRL# - shiftRLFastInt = uncheckedIShiftRL# * delete the following unused functions: - minFastInt - maxFastInt - uncheckedIShiftRA# - castFastPtr - panicDocFastInt and pprPanicFastInt * rename panicFastInt back to panic# These functions remain, since they actually do something: * iUnbox * bitAndFastInt * bitOrFastInt Test Plan: validate Reviewers: austin, bgamari Subscribers: rwbarton Differential Revision: https://phabricator.haskell.org/D1141 GHC Trac Issues: #1405 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1405#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10759: don't throw BlockedIndefinitelyOn... in main thread
by GHC 21 Aug '15

21 Aug '15

#10759: don't throw BlockedIndefinitelyOn... in main thread -------------------------------------+------------------------------------- Reporter: yokto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In the main thread UserInterrupt can be thrown to unblock a thread. So the following program should wait for such an interrupt instead of throwing a BlockedIndefinitelyOnMVar exception {{{ main = do var <- newEmptyMVar takeMVar var `catch` (const $ putStrLn "UserInterrupt caught" :: AsyncException -> IO ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10784: ghci crashed when ``-with-rtsopts=-A64m'' is specified
by GHC 21 Aug '15

21 Aug '15

#10784: ghci crashed when ``-with-rtsopts=-A64m'' is specified -------------------------------------------+------------------------------- Reporter: wangbj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- $ cat /tmp/t1.hs {-# OPTIONS -O2 -with-rtsopts=-A64m #-} main = putStrLn "hello, world!" wangbj@nuc ~/hs $ runghc /tmp/t1.hs ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<0>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8484: Compile-time panic
by GHC 20 Aug '15

20 Aug '15

#8484: Compile-time panic ----------------------------------+--------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I attempted to build a program (using make) and got the following output: {{{ ghc -odir binaries -hidir binaries --make Main.hs -optl-w ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): While parsing "/home/taymonbeal/.ghc/x86_64-linux-7.6.3/package.conf.d/package.cache": too few bytes. Failed reading at byte position 8 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [build] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10780: Weak reference is still alive if key is alive, but weak reference itself not reachable
by GHC 20 Aug '15

20 Aug '15

#10780: Weak reference is still alive if key is alive, but weak reference itself not reachable -------------------------------------+------------------------------------- Reporter: atze | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We've been running into some unexpected behavior with weak references. The use case it hackage package HMap, which is a (heterogenous, but that is besides the point) map from keys to values. Since there is no way to enumerate all elements in the map, there is no way to obtain a value for a key if the key is dead. As an optimization, I therefore used weak references to the values in the map, such that if the key dies, then the value is also dead. I was under the impression that a weak reference is alive if: (1): The key is still alive AND (2): The weak reference itself is alive (i.e. reachable from root set) However, the actual behavior is that a weak reference is alive if (1), (2) does not matter. Hence, the weak references here actually create a space leak, because an alive key will keep all values in all maps that it was ever used in alive. I think it would be desirable, to change the behavior to (1) AND (2), instead of just (1). This would prevent space leaks in this use case instead of creating them. Or would this cause problems in other use cases? See also: https://github.com/atzeus/HMap/issues/5#issuecomment-132538324 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4243: Make a proper options parser for the RTS
by GHC 19 Aug '15

19 Aug '15

#4243: Make a proper options parser for the RTS -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 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 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by carlostome): * owner: carlostome => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4243#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0