March 2014 - ghc-tickets

[GHC] #8649: Disambiguate Repeated Identifiers for data types in error messages
by GHC 23 Mar '14

23 Mar '14

#8649: Disambiguate Repeated Identifiers for data types in error messages ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- If, in an interactive context, you redefine a type, but then try to use functions for the previous definition, it will (as expected) give you an error message. The following code would trigger this in an interactive context: {{{ data X = Y Int f (Y i) = i data X = Y Int | Z String f (Y 3) }}} However the error message is not very good: {{{ Couldn't match expected type `:Interactive.X' with actual type `:Interactive.X' }}} This is very uninformative to the user if they do not understand what's going on. The following GHC API code can replicate this: {{{ runDeclsWithLocation "Interactive.hs" 1 "data X = Y Int" runDeclsWithLocation "Asdf.hs" 2 "f (Y i) = i" runDeclsWithLocation "Bloop.hs" 3 "data X = Y Int | Z String" runStmtWithLocation "Test.hs" 4 "f (Y 3)" RunToCompletion }}} Note that varying the location given to `runStmt` and `runDecls` (the string as well as the line number) seems to have no effect upon anything. I started out with just "<interactive>" but varied it to check - no effect on anything as far as I can tell. How can I make this error message more informative? I would ideally like something like {{{ Couldn't match expected type `:Interactive1.X' with actual type `:Interactive5.X' }}} or really anything that caused these types to be visibly different. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1721: Make GHCi print the entire result of an interactive 'bind' statement
by GHC 23 Mar '14

23 Mar '14

#1721: Make GHCi print the entire result of an interactive 'bind' statement -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"8f26728a44be395a41d9dd9cb933e8006f5a6dc4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f26728a44be395a41d9dd9cb933e8006f5a6dc4" ghc-cabal: force use of UTF8 when writing out `haddock-prologue.txt` This unbreaks the GHC build if a non-UTF8 locale such as LANG=C is active See also haskell/cabal#1721 and haskell/haddock#286 Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1721#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #286: GADTs Syntax Infelicity with {;}
by GHC 23 Mar '14

23 Mar '14

#286: GADTs Syntax Infelicity with {;} --------------------------------+-------------------- Reporter: ashley-y | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.4 Resolution: Fixed | Keywords: --------------------------------+-------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"8f26728a44be395a41d9dd9cb933e8006f5a6dc4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f26728a44be395a41d9dd9cb933e8006f5a6dc4" ghc-cabal: force use of UTF8 when writing out `haddock-prologue.txt` This unbreaks the GHC build if a non-UTF8 locale such as LANG=C is active See also haskell/cabal#1721 and haskell/haddock#286 Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/286#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8351: Arrays are always allocated out-of-line
by GHC 23 Mar '14

23 Mar '14

#8351: Arrays are always allocated out-of-line ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- unordered-containers uses lots of small arrays (length <= 16). These arrays are always allocated out-of-line by a call to `allocate`. I suspect this is bad for performance. We should look into supporting inline- allocation, perhaps by using a new `newSmallArray#` primop and/or by spotting calls to `newArray#` with a small, statically-known size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8922: GHC unnecessarily sign/zero-extends C call arguments
by GHC 23 Mar '14

23 Mar '14

#8922: GHC unnecessarily sign/zero-extends C call arguments ----------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (NCG) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7684 | ----------------------------------+------------------------------------- Ticket created following discussion in [https://ghc.haskell.org/trac/ghc/ticket/7684#comment:58] It seems the zero/sign-extension that we're doing in the NCG for arguments less than a word in size is unnecessary, since the ABI doesn't specify any extension. There's some clarification of the spec in this thread: [http://gcc.gnu.org/ml/gcc/2013-01/msg00448.html] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7684: cgrun071 segfaults
by GHC 23 Mar '14

23 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): Ok, that means we can remove the extension behaviour from GHC then. I've created a ticket: #8922. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8885: Add inline versions of clone array primops
by GHC 23 Mar '14

23 Mar '14

#8885: Add inline versions of clone array primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've changed the clone array primops (i.e. `cloneArray#`, `cloneMutableArray#`, `freezeArray#`, and `thawArray#`) to use the new inline allocation optimization for statically known array sizes. Furthermore, I've moved the implementation for the non-statically known case out-of-line, which should reduce code size. The numbers are very encouraging, with the new implementation being 74% (i.e. almost 4x) faster than the old one. I measured this by looking at the total time reported by `+RTS -s` for the attached `InlineCloneArrayAlloc` benchmark. Here are the stats from the best out of three runs of the old implementation: {{{ 1,600,041,120 bytes allocated in the heap 6,504 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 21,352 bytes maximum slop 1588 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1 colls, 0 par 0.01s 0.01s 0.0082s 0.0082s Gen 1 1 colls, 0 par 0.00s 0.11s 0.1062s 0.1062s INIT time 0.00s ( 0.00s elapsed) MUT time 0.29s ( 0.57s elapsed) GC time 0.01s ( 0.11s elapsed) EXIT time 0.01s ( 0.11s elapsed) Total time 0.31s ( 0.80s elapsed) %GC time 2.7% (14.2% elapsed) Alloc rate 5,497,251,856 bytes per MUT second Productivity 97.3% of total user, 37.4% of total elapsed }}} Here are the same for the new implementation: {{{ 1,600,041,120 bytes allocated in the heap 57,224 bytes copied during GC 35,992 bytes maximum residency (1 sample(s)) 21,352 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 3125 colls, 0 par 0.01s 0.01s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.00s 0.00s 0.0003s 0.0003s INIT time 0.00s ( 0.00s elapsed) MUT time 0.08s ( 0.08s elapsed) GC time 0.01s ( 0.01s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.08s ( 0.09s elapsed) %GC time 6.4% (8.8% elapsed) Alloc rate 21,260,179,643 bytes per MUT second Productivity 93.5% of total user, 88.8% of total elapsed }}} The performance ratio between the new and old implementation gets worse for the old implementation as the iteration count is increased. There's also an interesting difference in the Gen 1 collection times between the two implementations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #7684: cgrun071 segfaults
by GHC 23 Mar '14

23 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by tibbe): Replying to [comment:57 simonmar]: > FWIW I think gcc probably should be zero-extending in the caller, not the callee, for an 8-bit argument (i.e. gcc 4.2 is correct, 4.9 is wrong). This is what we assume in GHC. I couldn't see anything about this in the ABI spec, but there's a gcc bug open: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 According to [http://gcc.gnu.org/ml/gcc/2013-01/msg00447.html the discussion with an editor of the System V x86_64 ABI] rwbarton linked to above, it's incorrect for the callee to assume that the register has been zero extended. Accessing bits outside the specified argument size is intentionally undefined behavior (which means that the callee has to zero extend). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7684: cgrun071 segfaults
by GHC 23 Mar '14

23 Mar '14

#7684: cgrun071 segfaults ----------------------------------+---------------------------------- Reporter: tibbe | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Difficulty: Unknown Test Case: cgrun071 | Blocked By: Blocking: | Related Tickets: ----------------------------------+---------------------------------- Comment (by simonmar): So I think this fix is ok - it avoids the question of whether the ABI requires the caller to sign/zero-extend or not. My suggestion to cast the argument was based on the type of `hs_popcnt8` taking an `HsInt8`, but I see that wasn't what you intended. FWIW I think gcc probably should be zero-extending in the caller, not the callee, for an 8-bit argument (i.e. gcc 4.2 is correct, 4.9 is wrong). This is what we assume in GHC. I couldn't see anything about this in the ABI spec, but there's a gcc bug open: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7684#comment:57> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8765: Add --with-ar and --with-ranlib configure params.
by GHC 23 Mar '14

23 Mar '14

#8765: Add --with-ar and --with-ranlib configure params. ------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | 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: | ------------------------------------+------------------------------------- I've found that I usually miss --with-ar and/or --with-ranlib on Solaris while building GHC. Attached patch fixes that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2