January 2013 - ghc-tickets

Re: [GHC] #7519: CLK_TCK is not always a constant
by GHC 24 Jan '13

24 Jan '13

#7519: CLK_TCK is not always a constant ---------------------------------+------------------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by kgardas): Hi, as a Solaris user I'd like to add that the patch is not needed for Solaris native compiles. i.e. i386. 7.6.x compiles and runs fine on Solaris. The patch is needed for cross-compiling i386-solaris -> x86_64-solaris. The problem is that hsc2hs is kind of more strict while cross-compiling than while doing native compiles -- that's why the code even before patch run fine and I just fail on it once attempting cross-compiling to x86_64-solaris. So, message is clear, if 7.6.x does not support cross-compilation, I wouldn't bother with merging the patch into 7.6.x branch. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7519#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7519: CLK_TCK is not always a constant
by GHC 24 Jan '13

24 Jan '13

#7519: CLK_TCK is not always a constant ---------------------------------+------------------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by singpolyma): @simonmar oh. What's the state for "is in HEAD now"? Should it just be marked as "fixed"? This patch *might* be useful to people on 7.6 (if they are building native compiles for Solaris, for example), but since most people seem to have run into this while cross-compiling, and 7.6 cannot cross-compile, that's probably not what I meant. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7519#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7587: Kind variables are not renamed
by GHC 24 Jan '13

24 Jan '13

#7587: Kind variables are not renamed -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ ghci -XPolyKinds Prelude> data A x y Prelude> :k A A :: k -> k -> * }}} should be {{{k -> l -> *}}}. The 'k's are allowed to be different, there is just a name collision. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7519: CLK_TCK is not always a constant
by GHC 24 Jan '13

24 Jan '13

#7519: CLK_TCK is not always a constant ---------------------------------+------------------------------------------ Reporter: singpolyma | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Keywords: qnx | Os: Other Architecture: Unknown/Multiple | Failure: Building GHC failed Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: => 7.8.1 Comment: The ticket state "merge" means you want the change in the stable branch (7.6). Will it help to merge it into the 7.6 branch? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7519#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 24 Jan '13

24 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by simonmar): I agree with Simon, I think we already got a lot of the benefit to be had here from pointer tagging. Perhaps for enums larger than the threshold (3 or 7 for 32-bit or 64-bit respectively) we should be unboxing them in worker/wrapper. It wouldn't be hard to write some examples by hand and measure the difference between using enums and `Int#`. I would like to see the simplification I mentioned above - changing the comparison primops to return `Int#` rather than `Bool` - and I believe that would lead to more optimisations later. At the least it would expose the magic `tagToEnum#` that arises from these primops to the simplifier, where it could be optimised away. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 24 Jan '13

24 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 24 Jan '13

24 Jan '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by simonpj): See [wiki:PrimBool]. Janek, great initiative thanks. But I think it would be helpful to articulate a very clear story about the ''goal''. I believe that the goal is to achieve much better performance, without changing the source language. The programmer does not change the program, but they run faster. If so, then can we have (on the wiki page, not here): * A description of ''why'' programs will go faster, with specific examples. * Some example programs that will in fact go faster. Maybe you can code the examples up in Haskell, using inconvenient and messy `Int#` or whatever, to demonstrate that they really do go faster. The sub-text is that I only want to introduce new complexity if it demonstrably buys us something. One reason that things may go faster is this. At the moment, if a function is strict in a `Bool` argument, that argument is still passed boxed. But it could very sensibly be passed unboxed instead, just as we do with pairs, say. So perhaps strictness analysis would work well with unboxed enumerations. But it's not entirely obvious that it will. Unboxing a pair is great because the pair is never allocated. But enumerations are never allocated either! (`True` and `False` are statically allocated.) Moreover, even though passing `True` passes a pointer to a (statically allocated) heap object, the True/False tag is in the ''pointer'' (see [http://research.microsoft.com/en-us/um/people/simonpj/papers/ptr- tag/index.htm Faster laziness using dynamic pointer tagging]), so no memory access is needed when discriminating True/False. So the gains from unboxing may be modest. Pointer tagging only works for data types with a handful of constructors. Big enumerations really do keep the tag in memory. (See the paper.) None of this is to say it's a bad idea. Just that we need clarity about where the gains are going to come from, and measurements that suggest the gains are real. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1522: Make [n..] etc syntax rebindable
by GHC 24 Jan '13

24 Jan '13

#1522: Make [n..] etc syntax rebindable -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonpj Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Yes, it is. So I'll close this ticket. Hurrah. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1522#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5801: Document GHC Optimisation Passes
by GHC 24 Jan '13

24 Jan '13

#5801: Document GHC Optimisation Passes ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.6.2 Component: Documentation | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Documentation bug Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by dterei): * cc: benl (added) Comment: Manuel or Ben are you able to document the DPH flags? Just -vectorise and -void-vect are remaining and then we can close this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5801#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #709: "Fixup too large" error with -fasm on PowerPC
by GHC 24 Jan '13

24 Jan '13

#709: "Fixup too large" error with -fasm on PowerPC ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: low | Milestone: 6.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: powerpc Failure: Building GHC failed | Difficulty: Moderate (less than a day) Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Comment(by simonmar): Ok, I redid your first patch (see above), your other changes are fine except don't forget to take into account the effect of alignment, which could add a further `(word_size - 1)` bytes to the size of the info table. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/709#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0