Re: [GHC] #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64

#1717: ghc-6.8 configure does not recognise 32bit userland on ppc64
-------------------------------------+--------------------------------------
    Reporter:  kahl <at> cas.mcmaster.ca  |        Owner:              
        Type:  bug                   |       Status:  new         
    Priority:  low                   |    Milestone:  6.8 branch  
   Component:  Build System          |      Version:  6.8         
    Severity:  normal                |   Resolution:              
    Keywords:                        |   Difficulty:  Unknown     
          Os:  Linux                 |     Testcase:  normal build
Architecture:  powerpc64             |  
-------------------------------------+--------------------------------------
Comment (by guest):

 > This clearly isn't a serious problem

 agreed.

 > `uname -m` on your system claims `ppc64`, so that's what GHC uses as its
 target by default

 I would argue that `uname -m` is the the wrong source of information for
 determining the target.
 Since GHC produces assembly code (either directly or via C) that is
 intended to link against at least certain libraries, it should take care
 that it is compatible with those.

 For example, compiling some floating-point primitives cbits together with
 some dummy `main()` will link against `libm`; then one could use `ldd` to
 find out which `libm` is used, and `file` to find out more about that:

RE: [Haskell] Image manipulation

[Redirecting to ghc-bugs]

| > I'm not sure if the GC hack proposed by Wadler¹ that lets the garbage
| > collector replace "fst (a,b)" with "a" (and similar for other unchecked
| > selectors) counts as optimistic evaluation, but I wonder what the
| > status of this is.  GHC doesn't seem to do it, and I wonder if there
| > is any particular reason?  Too specific?
|
| GHC nominally does do it (look for 'selector thunks' in the RTS and
| commentary), but it doesn't work and we don't know why.
|
| http://hackage.haskell.org/trac/ghc/ticket/1038

That bug is alleged to be fixed.  Do you think it isn't?

Simon

Re: [Haskell] Image manipulation

Simon Peyton-Jones <simonpj <at> microsoft.com> writes:

> | GHC nominally does do it (look for 'selector thunks' in the RTS and
> | commentary), but it doesn't work and we don't know why.
> |
> | http://hackage.haskell.org/trac/ghc/ticket/1038

> That bug is alleged to be fixed.  Do you think it isn't?

I'm not sure to what extent the fix should cover my case, but if I may
restate it, what I certainly found was that by replacing my
partitioning function

  breaks p = groupBy (const (not.p))

by

  breaks :: (a -> Bool) -> [a] -> [[a]]
  breaks p (x:xs) = let first = x : takeWhile (not.p) xs
                        rest  = dropWhile (not.p) xs
                    in  rest `par` first : if null rest then [] else breaks p rest
  breaks _ []     = []

space consumption was drastically reduced -- as long as I compile with
-smp.  Previous space consumption appeared to be linear in the largest
partition (although I made no accurate measurements).

-k
--

-- 

Re: [GHC] #1811: liberate case needs an independent threshold

#1811: liberate case needs an independent threshold
-------------------------+--------------------------------------------------
    Reporter:  simonmar  |        Owner:            
        Type:  bug       |       Status:  new       
    Priority:  normal    |    Milestone:  6.8 branch
   Component:  Compiler  |      Version:  6.8       
    Severity:  normal    |   Resolution:            
    Keywords:            |   Difficulty:  Unknown   
          Os:  Unknown   |     Testcase:            
Architecture:  Unknown   |  
-------------------------+--------------------------------------------------
Changes (by simonmar):

  * owner:  simonmar =>
  * summary:  liberate case causes code duplication => liberate case needs
              an independent threshold

Comment:

 I re-did the measurements and got roughly consistent results for x86 and
 x86_64.

   * This patch did fix the particular case of code explosing I noticed,
 but
     it seems to have had little effect on anything else.  Code size for
 nofib
     dropped by <1%.
   * Turning off liberate-case for the libraries reduces code size for
 nofib by 5%.

[GHC] #1818: Code size increase vs. 6.6.1

#1818: Code size increase vs. 6.6.1
-------------------------+--------------------------------------------------
    Reporter:  simonmar  |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:  6.8.2  
   Component:  Compiler  |     Version:  6.8.1  
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 Code size for 6.8.1 has increased around 20% compared to 6.6.1.  Find out
 why, and fix it.  Measurements taken for nofib compiled with -O, libraries
 compiled with -O2.

 Possibly relevant tickets: #1811

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1818>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #1819: x86 native codegen implements float2int# incorrectly

#1819: x86 native codegen implements float2int# incorrectly
-------------------------------+--------------------------------------------
    Reporter:  simonmar        |       Owner:                            
        Type:  bug             |      Status:  new                       
    Priority:  normal          |   Milestone:  6.8 branch                
   Component:  Compiler (NCG)  |     Version:  6.8.1                     
    Severity:  normal          |    Keywords:                            
  Difficulty:  Unknown         |    Testcase:  arith005 (see description)
Architecture:  x86             |          Os:  Unknown                   
-------------------------------+--------------------------------------------
 `float2Int#` is supposed to truncate towards zero, but the x86 native
 codegen implements it as rounding (or rather, whatever rounding mode the
 x87 FPU is set to, which is normally rounding).  The right thing appears
 to be to save/restore the x87 control word around the conversion
 operation, and temporarily set it to truncation.  This is what gcc does.
 Code generated by gcc for truncation:

 {{{
         fnstcw  -2(%ebp)
         movw    -2(%ebp), %ax
         movb    $12, %ah
         movw    %ax, -4(%ebp)
         flds    8(%ebp)
         fldcw   -4(%ebp)
         fistpl  -8(%ebp)
         fldcw   -2(%ebp)
         movl    -8(%ebp), %eax
 }}}

 Test case:

[GHC] #1820: Windows segfault-catching only works for the main thread

#1820: Windows segfault-catching only works for the main thread
-------------------------------+--------------------------------------------
    Reporter:  simonmar        |       Owner:                                  
        Type:  bug             |      Status:  new                             
    Priority:  normal          |   Milestone:  6.8 branch                      
   Component:  Runtime System  |     Version:  6.8.1                           
    Severity:  normal          |    Keywords:                                  
  Difficulty:  Unknown         |    Testcase:  derefnull(ghci), divbyzero(ghci)
Architecture:  Unknown         |          Os:  Windows                         
-------------------------------+--------------------------------------------
 On Windows, the RTS tries to catch segmentation faults and divide-by-zero
 exceptions using structured exception handling in `rts/Main.c`.
 Unfortunately this only works for the main thread, so if the exception
 occurs in another thread it won't be caught.  GHCi runs all its
 computations in a separate thread, hence `derefnull(ghci)` and
 `divbyzero(ghci)` are failing.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1820>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1226: Add flags --full-flag-help and --print-docdir

#1226: Add flags --full-flag-help and --print-docdir
-----------------------------+----------------------------------------------
 Reporter:  igloo            |          Owner:  igloo     
     Type:  feature request  |         Status:  new       
 Priority:  normal           |      Milestone:  6.8 branch
Component:  Driver           |        Version:  6.6       
 Severity:  normal           |     Resolution:            
 Keywords:                   |     Difficulty:  Unknown   
 Testcase:                   |   Architecture:  Unknown   
       Os:  Unknown          |  
-----------------------------+----------------------------------------------
Comment (by guest):

 Replying to [comment:5 guest]:
 > just so that this doesn't get lost: there's a simple xslt file to
 extract text for a --full-flag-help option here
 >
 > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038560.html


 a patch implementing flag reference command line help with simple search,
 close to what was suggested in comment:5, was sent to cvs-ghc:

 http://www.haskell.org/pipermail/cvs-ghc/2007-October/039184.html


 here is the patch description:
 {{{
 add flag --flags (FIX #1226)

  Ticket #1226 calls for a '--full-flag-help' flag, presenting the
  users guide's flag reference or man page in text format. Since a

Re: [GHC] #1791: -M option does not work

#1791: -M option does not work
----------------------------+-----------------------------------------------
 Reporter:  guest           |          Owner:  igloo     
     Type:  bug             |         Status:  reopened  
 Priority:  normal          |      Milestone:  6.8 branch
Component:  Runtime System  |        Version:  6.8       
 Severity:  blocker         |     Resolution:            
 Keywords:                  |     Difficulty:  Unknown   
 Testcase:  outofmem2       |   Architecture:  Unknown   
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Changes (by guest):

  * status:  closed => reopened
  * type:  merge => bug
  * resolution:  fixed =>

Comment:

 I actually expected to get an exception stating "out of heap", like it
 also works for stack overflows. I have a catch all exception catcher, but
 this one isn't triggered. Also the actual output doesn't state it's an
 exception, so I guess it really is not. So, I am reopening it again.
 Again, to be clear: I want that

 {{{
 Control.Exception.catch
          action
          (\exception -> do
            appendFile "/home/me/exception" (show exception)

[GHC] #1821: Parser or lexer mess-up

#1821: Parser or lexer mess-up
-------------------------+--------------------------------------------------
    Reporter:  simonpj   |       Owner:         
        Type:  bug       |      Status:  new    
    Priority:  normal    |   Milestone:         
   Component:  Compiler  |     Version:  6.9    
    Severity:  normal    |    Keywords:         
  Difficulty:  Unknown   |    Testcase:         
Architecture:  Unknown   |          Os:  Unknown
-------------------------+--------------------------------------------------
 This program gives a parse error:
 {{{
 module Par where

 f x = x
   where
 -- ######### x86_64 machine code:
     g y = y
     h y = y
 }}}
 With the HEAD we get:
 {{{
 Par.hs:7:8: parse error on input `='
 }}}
 This is killing the stage2 build of the HEAD, in `ByteCodeFFI`:
 {{{
 ghci/ByteCodeFFI.lhs:444:26: parse error on input `='
 }}}

 The problem is something to do with the comment (!).  Remove it, and all