April 2014 - ghc-tickets

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 19 Apr '14

19 Apr '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by simonmar): It looks like they're lacking good use cases for register variables. I'm not on that list so it's difficult to jump into the middle of the conversation, perhaps someone else could point them to this ticket and/or our use of register variables in the GC? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 19 Apr '14

19 Apr '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): there was some recent chatter on the llvm list about adding gcc style global named register support to clang https://groups.google.com/forum/#!msg/llvm-dev/p7GAE_bbDoo/QgJme5LblBkJ and http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-March/071503.html perhaps someone on the ghc team should chime in :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?)
by GHC 19 Apr '14

19 Apr '14

#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: Resolution: | Keywords: thread-local Operating System: MacOS X | state, TLS clang Type of failure: Runtime | Architecture: x86_64 (amd64) performance bug | Difficulty: Unknown Test Case: | Blocked By: 7678 Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by George): * keywords: => thread-local state, TLS clang * failure: None/Unknown => Runtime performance bug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7602#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9008: Data.Function: Add reverse application operator
by GHC 19 Apr '14

19 Apr '14

#9008: Data.Function: Add reverse application operator ------------------------------------+------------------------------------- Reporter: bernalex | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

Re: [GHC] #2659: Add sortOn and other *On functions
by GHC 19 Apr '14

19 Apr '14

#2659: Add sortOn and other *On functions -------------------------------------+--------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.9 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"44512e3c855d8fb36ab6580f4f97f842ebcf4c6c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="44512e3c855d8fb36ab6580f4f97f842ebcf4c6c" Add Data.List.sortOn function (re #9004 and #2659) `sortOn` sorts a list by comparing the results of a key function applied to each element. `sortOn f` is equivalent to `sortBy . comparing f`, but has the performance advantage of only evaluating `f` once for each element in the input list. Historical note: This was already proposed in 2008 as part of http://www.haskell.org/pipermail/libraries/2008-October/010797.html It was, however, the recent re-attempt http://www.haskell.org/pipermail/libraries/2014-April/022489.html that let `sortOn` make it into base at last. Maybe the other functions mentioned in #2659 might be worth reconsidering as well. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2659#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7858: Fix definitions of abs/signum for Floats/Doubles
by GHC 18 Apr '14

18 Apr '14

#7858: Fix definitions of abs/signum for Floats/Doubles -------------------------------------+------------------------------------ Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: floating point Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ekmett): * cc: ekmett@…, hvr (added) * difficulty: => Unknown Comment: This makes sense to me. I'm personally, in favor of fixing it to be correct first, then opening an issue that it could be faster, as what we are doing now is incorrect. It doesn't matter how fast you do your job if you do the wrong job. ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7858#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4413: (^^) is not correct for Double and Float
by GHC 18 Apr '14

18 Apr '14

#4413: (^^) is not correct for Double and Float -------------------------------------+------------------------------------- Reporter: | Owner: tcsavage daniel.is.fischer | Status: new Type: bug | Milestone: 7.6.2 Priority: low | Version: 7.1 Component: libraries/base | Keywords: Double, Float, Resolution: | exponentiation Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Unknown at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett@…, hvr (added) * difficulty: => Unknown Comment: When I first saw this, I was in favor of it, but then I chewed on it some more. The issue is unfortunately more subtle. While Daniel's proposal is sound for 2 and 0.5 which have exact representations in IEEE 754 floating point for both the original number and the reciprocal, this proposal yields worse numeric precision for any floating point number where the inverse isn't exactly representable. Consider 3. {{{ >>> recip 3^600 5.336385165377033e-287 >>> recip (3^600) 5.336385165377108e-287 }}} Now, lets compare these to answers that are more accurate, using my `rounded` library: {{{ >>> :m + Numeric.Rounded >>> :set -XDataKinds >>> recip (3^600) :: Rounded TowardZero 512 5.3363851653771076591089513443334745430695010187597757569958309540684063019552892464056775485633511783044398629355030763271677070438623409480523609685251156e-287 >>> recip 3^600 :: Rounded TowardZero 512 5.3363851653771076591089513443334745430695010187597757569958309540684063019552892464056775485633511783044398629355030763271677070438623409480523609685247316e-287 }}} The inexact version caused us 3 decimal places worth of accuracy. Those 10 bits of lost significand dwarf the error in the subnormal case. If we're stuck choosing, the existing implementation shoots an arrow that consistently winds up closer to the mark except in cases of underflow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4413#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3549: unlit does not follow H98 spec
by GHC 18 Apr '14

18 Apr '14

#3549: unlit does not follow H98 spec -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.4 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 mgsloan1): Figured I'd unearth this ticket to add a few notes, since I was recently looking into how ghc's lhs support behaves. I found some additional quirks: * It's valid to add trailing whitespace after `\begin{code}` or `\end{code}`. I think that's due to this line: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L224 * It's valid to indent `\begin{code}`, but not `\end{code}`. I think the whitespace before `\begin{code}` is consumed by https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L214 . `\end{code}`, on the other hand is recognized by strncmp: https://github.com/ghc/ghc/blob/master/utils/unlit/unlit.c#L276 RE igloo's comment, I agree that unlit should not need to know that `\end{code}` is inside a string literal. It's unreasonable to mix up tokenization and unlit like that, particularly when you consider writing tools external to ghc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3549#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7730: :info and polykinds
by GHC 17 Apr '14

17 Apr '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Comment (by simonpj): Thinking about this some more, I think the best thing is to include the `fam_tc` and `arg_tys` in the `ifAxiom` field, and maybe rename it thus: {{{ ifParent :: IfaceTyConParent }}} where {{{ data IfaceTyConParent = IfNoParent | IfDataInstance IfExtName -- Axiom IfExtName -- Parent TyCon [IfaceType] -- Arg tys }}} That would make `tc_parent` in `TcIface` a lot simpler too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate
by GHC 17 Apr '14

17 Apr '14

#3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4139 -------------------------------------+------------------------------------ Comment (by simonpj): Yes, I think it's the same thing, though this time you have do some type- family rewrites too, to see that the patterns are exhaustive. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3927#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0