November 2014 - ghc-tickets

Re: [GHC] #4900: DEPENDS pragma
by GHC 18 Nov '14

18 Nov '14

#4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: Phab:D481 | -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"0515055abfcf5957d7a957607b4785320627fd65/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0515055abfcf5957d7a957607b4785320627fd65" document addDependentFile uses contents, not mtime Reviewers: austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D481 GHC Trac Issues: #4900 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4900#comment:74> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7653: incorrect handling of StackOverflow exception in the event manager
by GHC 18 Nov '14

18 Nov '14

#7653: incorrect handling of StackOverflow exception in the event manager -----------------------------------+------------------------------------ Reporter: nus | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+------------------------------------ Comment (by Austin Seipp <austin@…>): In [changeset:"a520761d065a84838896e8dd09d8aaec77480d60/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a520761d065a84838896e8dd09d8aaec77480d60" Remove outdated TODO in TimeManager Summary: It describes a work around Trac #3838, but it is already fixed and the workaround removed, Trac #7653 Test Plan: not needed Reviewers: hvr, Mikolaj, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D478 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7653#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4900: DEPENDS pragma
by GHC 17 Nov '14

17 Nov '14

#4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: Phab:D481 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D481 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4900#comment:73> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3134: encodeFloat . decodeFloat
by GHC 17 Nov '14

17 Nov '14

#3134: encodeFloat . decodeFloat -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3134#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4900: DEPENDS pragma
by GHC 17 Nov '14

17 Nov '14

#4900: DEPENDS pragma -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: TH_Depends | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:71 GregWeber]: > I added the documentation: https://phabricator.haskell.org/D481 Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4900#comment:72> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment
by GHC 17 Nov '14

17 Nov '14

#8627: mallocForeignPtrBytes documentation unobvious regarding memory alignment ------------------------------------+------------------------------------- Reporter: schernichkin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- According to the current documentation: mallocForeignPtr - is equivalent to do { p <- malloc; newForeignPtr finalizerFree p }. It's ok since we can read that the "block of memory is sufficiently aligned" if the mallocBytes function descriprion and newAlignedPinnedByteArray in the function implementation. mallocForeignPtrBytes - "similar to mallocForeignPtr" but will it alloc aligned memory? Internally it uses newPinnedByteArray which implies memory will not be aligned, but does it really makes any sense? Plz correct documentation to make it more obvious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 17 Nov '14

17 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Comment (by dreixel): I need to update that page. On it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 17 Nov '14

17 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Comment (by simonpj): Wiki page https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#U… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9804: Layering: Suspicious dependency from Parser to TcEvidence
by GHC 17 Nov '14

17 Nov '14

#9804: Layering: Suspicious dependency from Parser to TcEvidence -------------------------------------+------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There is an import from Parser to TcEvidence module. Why does the parser need to know about type checking? The parser should produce an AST and through the AST (and global modules) be isolated from the rest of the compiler pipeline. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9804> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8647: Reduce allocations in `integer-gmp`
by GHC 17 Nov '14

17 Nov '14

#8647: Reduce allocations in `integer-gmp` ------------------------------+-------------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.6.3 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8638 | ------------------------------+-------------------------------------------- I've added `printf(3)`s to `integer-gmp`s GMP allocation/reallocation functions, and noticed there to a significant amount of allocations going on. This is due to the fact that the CMM wrappers call `gmpz_init()` to initialize the result, and this already allocates a 1-limb `StgArray`. But the actual GMP operations perform a reallocate-call (which by contract also needs `memcpy` the untouched limb over to the newly allocated structure) based on the type of operation and the involved operands, causing the optimistically allocated 1-limb structure to become garbage right away w/o even being written to. I've been able to get rid of most such superfluous allocations by replacing {{{#!c ccall __gmpz_init(mp_result1 "ptr"); }}} by {{{#!c MP_INT__mp_alloc(mp_result1) = 0; MP_INT__mp_size(mp_result1) = 0; MP_INT__mp_d(mp_result1) = 0; // (1) }}} which is handled properly by all GMP operations we make use of currently. This elegantly lets the very first allocation be performed within the GMP operation (which has better knowledge with respect to how many limbs the result will require) I've got working proof-of-concept code, which reduces the allocations the big-num heavy `nofib` programs (I've omitted the benchmarks which had a 0% allocation change): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ... bernouilli -0.1% -5.2% 0.12 0.12 +0.0% kahan -0.1% -10.5% 0.17 0.17 +0.0% primetest -0.1% -12.8% 0.07 0.07 +0.0% rsa -0.1% -13.8% 0.02 0.02 +0.0% symalg -0.1% -2.3% 0.01 0.01 +0.0% ... -------------------------------------------------------------------------------- Min -0.1% -13.8% -3.1% -3.1% -6.5% Max -0.0% +0.4% +4.0% +4.0% +1.5% Geometric Mean -0.1% -0.5% +0.5% +0.4% -0.1% }}} `(1)` This should actually point to a proper static closure I didn't need this for the proof-of-concept ---- Another place which helps avoiding temporarily allocating 1-limb `StgArrays` which live only for the duration of GMP FFI calls are those caused by the `toBig`-casts, which I'm also experimenting by making use of GMP's big-int/small-int add/sub/mul primitives (the deltas shown above are actually measured on top of this optimization), here's what to expect from such an optimization by itself (i.e. w/o the realloc-optimization from above): {{{ bernouilli +0.1% -4.2% 0.12 0.12 +0.0% kahan +0.1% -12.6% 0.17 0.17 +0.0% power +0.1% -2.7% +2.2% +2.2% +0.0% rsa +0.1% -4.1% 0.02 0.02 +0.0% scs +0.1% -2.6% -1.6% -1.6% +0.0% }}} Thus, the `kahan` benchmark benefits from this optimization by -12.6%, and on top of that another -10.5% by also avoiding the GMP-reallocations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20