GHC | 1 Feb 05:39 2011

Re: #4895: hGetBufSome returns 0 when it should not

#4895: hGetBufSome returns 0 when it should not
---------------------------------+------------------------------------------
    Reporter:  guest             |        Owner:  simonmar                   
        Type:  bug               |       Status:  merge                      
    Priority:  high              |    Milestone:  7.0.2                      
   Component:  libraries/base    |      Version:  7.0.1                      
    Keywords:                    |     Testcase:                             
   Blockedby:                    |   Difficulty:                             
          Os:  Linux             |     Blocking:                             
Architecture:  Unknown/Multiple  |      Failure:  Incorrect result at runtime
---------------------------------+------------------------------------------

Comment(by kazu-yamamoto):

 It seems to me that this patch have not been marged to ghc-7.0 yet. Please
 merge this.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4895#comment:6>
GHC | 1 Feb 07:34 2011

Re: #4902: Create a primop for getting the size of an Array#

#4902: Create a primop for getting the size of an Array#
---------------------------------+------------------------------------------
    Reporter:  tibbe             |        Owner:              
        Type:  feature request   |       Status:  patch       
    Priority:  normal            |    Milestone:              
   Component:  Runtime System    |      Version:  7.0.1       
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by pumpkin):

 I'm using the correct offset now. It currently makes no difference because
 it happens to be 0, but it makes us more future-proof. Still no tests, but
 I probably won't have a chance to write any for a little bit, so if anyone
 else wants to in the mean time I certainly won't be offended!

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4902#comment:5>
GHC | 1 Feb 07:42 2011

Re: #4928: Add primops for copying/cloning an array

#4928: Add primops for copying/cloning an array
---------------------------------+------------------------------------------
    Reporter:  tibbe             |       Owner:                
        Type:  feature request   |      Status:  new           
    Priority:  normal            |   Component:  Runtime System
     Version:  7.0.1             |    Keywords:                
    Testcase:                    |   Blockedby:                
          Os:  Unknown/Multiple  |    Blocking:                
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown  
---------------------------------+------------------------------------------

Comment(by pumpkin):

 The new patch has all the primops listed above, but apart from some
 trivial testing I did in ghci, it still needs some testing love.

 Current issues with the implementation lie mostly in the card copying
 logic. Since we allow different source and destination offsets to be
 specified in the primop call, and these offsets may not be aligned mod 128
 (or whatever the card width is), a single source card may overlap two
 destination cards. So the current logic simply optimizes for the current
 case, and if the two offsets are aligned mod 128, it uses a
 memcpy/memmove, and otherwise it simply memsets the cards all to 1 (so the
 GC may do some extra work).

 For future work, it's worth seeing how expensive the cmm loop would be
 that does the "right" thing for copying the subcard-shifted cards would
 be. Also, for tibbe's common case, we're cloning 32-element arrays, which
 only have one card. Calling out to memcpy for a single word (it gets
 rounded up to a multiple of a word) seems silly, but only profiling can
(Continue reading)

GHC | 1 Feb 08:59 2011

Re: #4936: Unbox sum types without fields

#4936: Unbox sum types without fields
---------------------------------+------------------------------------------
    Reporter:  tibbe             |        Owner:              
        Type:  feature request   |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  7.0.1       
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by simonpj):

 Can you give a small program that doesn't optimise as well as you'd like,
 and a hand-optimised version that does better?

 Concerning #2289, unboxing a pure enumeration (as you propose here) is
 much easier than unboing a general sum type such as lists (which is what
 Don's comment in #2289 asked for). In any case, #2289 is largly about
 another issue (nested CPR).

 simon

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4936#comment:2>
GHC | 1 Feb 09:45 2011

Re: #4935: New type error in GHC 7.1 with TypeFamilies, Rank2Types

#4935: New type error in GHC 7.1 with TypeFamilies, Rank2Types
----------------------------------------+-----------------------------------
    Reporter:  patrick_premont          |        Owner:              
        Type:  bug                      |       Status:  new         
    Priority:  normal                   |    Milestone:              
   Component:  Compiler (Type checker)  |      Version:  7.1         
    Keywords:                           |     Testcase:              
   Blockedby:                           |   Difficulty:              
          Os:  Windows                  |     Blocking:              
Architecture:  x86                      |      Failure:  None/Unknown
----------------------------------------+-----------------------------------

Comment(by simonpj):

 Yes this is a definite bug; thank you!  Should not be hard to fix.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4935#comment:1>
GHC | 1 Feb 10:43 2011

Re: #4936: Unbox sum types without fields

#4936: Unbox sum types without fields
------------------------------+---------------------------------------------
  Reporter:  tibbe            |          Owner:                  
      Type:  feature request  |         Status:  closed          
  Priority:  normal           |      Milestone:                  
 Component:  Compiler         |        Version:  7.0.1           
Resolution:  duplicate        |       Keywords:                  
  Testcase:                   |      Blockedby:                  
Difficulty:                   |             Os:  Unknown/Multiple
  Blocking:                   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown     |  
------------------------------+---------------------------------------------
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => duplicate

Comment:

 Duplicate of #605.

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4936#comment:3>
GHC | 1 Feb 10:43 2011

Re: #605: Optimisation: strict enumerations

#605: Optimisation: strict enumerations
--------------------------------------+-------------------------------------
  Reporter:  simonmar                 |          Owner:                  
      Type:  task                     |         Status:  new             
  Priority:  normal                   |      Milestone:  _|_             
 Component:  Compiler                 |        Version:  None            
Resolution:  None                     |       Keywords:                  
  Testcase:  N/A                      |      Blockedby:                  
Difficulty:  Difficult (2-5 days)     |             Os:  Unknown/Multiple
  Blocking:                           |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------

Comment(by simonmar):

 Also requested in #4936

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/605#comment:12>
GHC | 1 Feb 10:49 2011

Re: #605: Optimisation: strict enumerations

#605: Optimisation: strict enumerations
--------------------------------------+-------------------------------------
  Reporter:  simonmar                 |          Owner:                  
      Type:  task                     |         Status:  new             
  Priority:  normal                   |      Milestone:  _|_             
 Component:  Compiler                 |        Version:  None            
Resolution:  None                     |       Keywords:                  
  Testcase:  N/A                      |      Blockedby:                  
Difficulty:  Difficult (2-5 days)     |             Os:  Unknown/Multiple
  Blocking:                           |   Architecture:  Unknown/Multiple
   Failure:  Runtime performance bug  |  
--------------------------------------+-------------------------------------
Changes (by simonpj):

 * cc: tibbe (added)

Comment:

 I'd still like to see a test program showing the existing setup, compared
 what you get with manual unboxing of enumerations.  That would give us an
 idea of whether there's a real perf win here.

 Simon

--

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/605#comment:13>
GHC | 1 Feb 10:53 2011

#4939: Panic in parsing a stmt

#4939: Panic in parsing a stmt
---------------------------------+------------------------------------------
    Reporter:  simonpj           |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  7.0.1       
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------
 Daniel Gorin (dgorin <at> dc.uba.ar) reports:
 I'm trying to make the hint library work also with ghc 7 and I'm having
 problems with some test-cases that are now raising exceptions. I've been
 able to reduce the problem to a small example. The program below runs ghc
 in interpreter-mode and attempts to parse an statement using ghc's
 parseStmt function; the particular statement is a let-expression with a \n
 in the middle. The observed behaviour is:
 {{{
 $ ghc-6.12.1 -fforce-recomp --make -package ghc -cpp -Wall d.hs && ./d
 [1 of 1] Compiling Main             ( d.hs, d.o )
 Linking d ...
 let {e = let x = ()
 in x ;} in e
 Ok
 $ ghc-7.0.1 -fforce-recomp --make -package ghc -cpp -Wall d.hs && ./d
 [1 of 1] Compiling Main             ( d.hs, d.o )
 Linking d ...
 let {e = let x = ()
 in x ;} in e
(Continue reading)

GHC | 1 Feb 11:02 2011

#4940: Bad error message using poly pat bind with MonoPatBinds

#4940: Bad error message using poly pat bind with MonoPatBinds
---------------------------------+------------------------------------------
    Reporter:  batterseapower    |       Owner:                                   
        Type:  feature request   |      Status:  new                              
    Priority:  normal            |   Component:  Compiler (Type checker)          
     Version:  7.0.1             |    Keywords:                                   
    Testcase:                    |   Blockedby:                                   
          Os:  Unknown/Multiple  |    Blocking:                                   
Architecture:  Unknown/Multiple  |     Failure:  Incorrect warning at compile-time
---------------------------------+------------------------------------------
 This program:

 {{{
 foo :: a -> a
 bar :: a -> a
 (foo, bar) = (\x -> x, \y -> y)

 main = print $ foo $ bar 1
 }}}

 Is trying to pattern-bind a polymorphic function. The error message is
 dreadful:

 {{{
 /Users/mbolingbroke/Junk/PolyPatBinds.hs:5:15:
     Couldn't match expected type `t -> t1'
                 with actual type `forall a. a -> a'
     The lambda expression `\ x -> x' has one argument one argument,
     but its type `forall a. a -> a' has none
     In the expression: \ x -> x
(Continue reading)


Gmane