[GHC] #186: Bad sparc Int64 code via NCG with -O

GHC trac at galois.com
Thu Dec 8 10:06:16 EST 2005


#186: Bad sparc Int64 code via NCG with -O
-------------------------------+--------------------------------------------
    Reporter:  nobody          |        Owner:  nobody  
        Type:  bug             |       Status:  assigned
    Priority:  low             |    Milestone:          
   Component:  Compiler (NCG)  |      Version:  6.0.1   
    Severity:  normal          |   Resolution:  None    
    Keywords:                  |           Os:  Unknown 
Architecture:  sparc           |  
-------------------------------+--------------------------------------------
Changes (by simonmar):

  * architecture:  => sparc
  * os:  => Unknown

Old description:

> {{{
> On sparc machines ( sparc-sun-solaris2.6,
> sparc-unknown-openbsd ) testsuite tests exercising
> Int64 code are broken when compiled the optasm way.
> This includes the arith011 test and the enum02 test,
> possibly others. Trivial Int64 code will produce
> erroneous results. Turning off optimisation, or
> compiling via C, will generate correct code.
>
> Some examples..
>
> This one comes from enum02:
>
>   import Int
>   main = do print $ pred (1 :: Int64)
>
> $ ./a.out
>   4294967295
>
> which is UINT_MAX...
> And from arith011, this generates incorrect results:
>
>   import Int
>   main = do print $ take 10 [ (0::Int64), toEnum 2 .. ]
>
> on x86:
>    [0,2,4]
> on sparc:
>    [0,8589934592,17179869184]
>
> which is 2 * (UNIT_MAX + 1), and then twice that.
> This erroneously generates an infinte sequence, filling
> up /usr on my system before I realised what happened:
>
>   import Int
>   main = do print [ (0::Int64) .. toEnum 2 ]
>
> -- Don Stewart
> }}}

New description:

 {{{
 On sparc machines ( sparc-sun-solaris2.6,
 sparc-unknown-openbsd ) testsuite tests exercising
 Int64 code are broken when compiled the optasm way.
 This includes the arith011 test and the enum02 test,
 possibly others. Trivial Int64 code will produce
 erroneous results. Turning off optimisation, or
 compiling via C, will generate correct code.

 Some examples..

 This one comes from enum02:

   import Int
   main = do print $ pred (1 :: Int64)

 $ ./a.out
   4294967295

 which is UINT_MAX...
 And from arith011, this generates incorrect results:

   import Int
   main = do print $ take 10 [ (0::Int64), toEnum 2 .. ]

 on x86:
    [0,2,4]
 on sparc:
    [0,8589934592,17179869184]

 which is 2 * (UNIT_MAX + 1), and then twice that.
 This erroneously generates an infinte sequence, filling
 up /usr on my system before I realised what happened:

   import Int
   main = do print [ (0::Int64) .. toEnum 2 ]

 -- Don Stewart
 }}}

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


More information about the Glasgow-haskell-bugs mailing list