[Bug classpath/22800] New: ARM double to ascii conversion issue

[rearnsha at gcc dot gnu dot org]

Hi,



  I've cross compiled CLASSPATH on an S3C2410 ARM920 architecture. I've also 
compiled SableVM on it.

When I run this code :

    float a = 1.5f;

    float b = 26.524f;

    float c = 1.11E11f;

    float d = a + b;

    int   e = (int)d;

  

    System.Out.println("a is "+a);

    System.Out.println("b is "+b);

    System.Out.println("d is "+d);

    System.Out.println("e is "+e);



I get wrong result for float (and double, I've tried them too) output (the 
output is totally garbaged), but the number show as e is correct. 

I think the problem seem to be in _dtoa function in fdlibm.



ARM are very strict on memory alignment, and is little endian.



PS: The same code works on x86.



Output is (This is the input => a=1.5f,b=26.524f,c=1.11E11f):

----------

float test

----------

a=1.000007

b=37.63494

c=1.1100000256E11

(int)a =1

(int)b =26

(int)c =2147483647

a+b=39.034943

a+c=1.1100000256E11

a-b=-36.034943

a-c=-1.1100000256E11

(int)(a+b)=28

(int)(a+c)=2147483647

(int)(a-b)=-25

(int)(a-c)=-2147483648

a*b=4:.89693;

a*c=1.66500007936E11

a/b=0.02

a/c=28.7935:8

(int)(a*b)=39

(int)(a*c)=2147483647

(int)(a/b)=0

(int)(a/c)=17




------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-19 22:53 -------
Unfortunately, most of us don't have an ARM machine to test this on. 



However, looking at the fdlibm code, there's #ifdefs for ARM in ieeefp.h, and 
some more in atoi.c (Pack_32?) so it could be a build issue. I'd try playing 
around with the #ifdefs.



If you find something, please post it here and let us know!


------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-22 08:57 -------
This was originally reported to http://sablevm.org/bugs/74
------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-22 09:18 -------
I'm not entirely sure if this is a general fdlibm problem, or specific to dtoa. 
Could you test this? 



I've attached a little test-case which might be an indicator,  checking the 
output of a fdlibm function with the expected value.
------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-22 13:40 -------
Tested your class, and I've added some other tests too.

\/ Below is Java File \/

import java.io.*;

 

public class Cos {

 

   public static double div(double a, double b){

    return a/b;

   }

 

   public static void main(String[] args){

       double a = Math.cos(Math.PI);

       double b = -1.0;

       System.out.println("a equals b:"+(a == b));

       System.out.println("a:"+a);

       System.out.println("b:"+b);       

       a = 1.002;

       b = 0.;

       System.out.println("a div b:" + div(a,b));

       System.out.println("a:"+a);

       System.out.println("b:"+b);       

    a = 8.8888888E21;

       b = 5.5555555E-21;

       System.out.println("a:"+a);

       System.out.println("b:"+b);

 

   }

}



\/ And this is the output \/

a equals b:true

a:-1.0

b:-1.0

a div b:Infinity

a:2.002:958353678385

b:0.0

a:0.0000000000026E21

b:Q.0E-21
------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-23 06:40 -------
Thanks for the follow-up. Strange. Looks like you're right that this seems to 
be in dtoa.c, and not a general fdlibm thing. Could you provide output of 
Float.floatToRawIntBits() and Double.doubleToRawLongBits() for the different 
input/output values? This would be helpful.




------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-24 11:39 -------
the test class:

---------------



import java.io.*;



public class Cos {



public static double div(double a, double b){

return a/b;

}



public static void main(String[] args){

double a = Math.cos(Math.PI);

double b = -1.0;

System.out.println("a equals b:"+(a == b));

System.out.println("a:"+a);

System.out.println("b:"+b); 

System.out.println("Double.doubleToLongBits(a):"+Double.doubleToLongBits(a));

System.out.println("Double.doubleToLongBits(a):"+Double.doubleToLongBits(a));

System.out.println("Double.doubleToRawLongBits(b):"+Double.doubleToRawLongBits(b));

System.out.println("Double.doubleToRawLongBits(b):"+Double.doubleToRawLongBits(b));

System.out.println("Float.floatToRawIntBits((float)a):"+Float.floatToRawIntBits((float)a));

System.out.println("Float.floatToIntBits((float)a):"+Float.floatToIntBits((float)a));

System.out.println("Float.floatToRawIntBits((float)b):"+Float.floatToRawIntBits((float)b));

System.out.println("Float.floatToIntBits((float)b):"+Float.floatToIntBits((float)b));

a = 1.002;

b = 0.;

System.out.println("a div b:" + div(a,b));

System.out.println("a:"+a);

System.out.println("b:"+b); 

System.out.println("Double.doubleToLongBits(a):"+Double.doubleToLongBits(a));

System.out.println("Double.doubleToLongBits(a):"+Double.doubleToLongBits(a));

System.out.println("Double.doubleToRawLongBits(b):"+Double.doubleToRawLongBits(b));

System.out.println("Double.doubleToRawLongBits(b):"+Double.doubleToRawLongBits(b));

System.out.println("Float.floatToRawIntBits((float)a):"+Float.floatToRawIntBits((float)a));

System.out.println("Float.floatToIntBits((float)a):"+Float.floatToIntBits((float)a));

System.out.println("Float.floatToRawIntBits((float)b):"+Float.floatToRawIntBits((float)b));

System.out.println("Float.floatToIntBits((float)b):"+Float.floatToIntBits((float)b));

a = 8.8888888E21;

b = 5.5555555E-21;

System.out.println("a:"+a);

System.out.println("b:"+b);

System.out.println("Double.doubleToLongBits(a):"+Double.doubleToLongBits(a));

System.out.println("Double.doubleToLongBits(a):"+Double.doubleToLongBits(a));

System.out.println("Double.doubleToRawLongBits(b):"+Double.doubleToRawLongBits(b));

System.out.println("Double.doubleToRawLongBits(b):"+Double.doubleToRawLongBits(b));

System.out.println("Float.floatToRawIntBits((float)a):"+Float.floatToRawIntBits((float)a));

System.out.println("Float.floatToIntBits((float)a):"+Float.floatToIntBits((float)a));

System.out.println("Float.floatToRawIntBits((float)b):"+Float.floatToRawIntBits((float)b));

System.out.println("Float.floatToIntBits((float)b):"+Float.floatToIntBits((float)b));



}

}



Result :

--------



a equals b:true

a:-1.0

b:-1.0

Double.doubleToLongBits(a):3220176896

Double.doubleToLongBits(a):3220176896

Double.doubleToRawLongBits(b):3220176896

Double.doubleToRawLongBits(b):3220176896

Float.floatToRawIntBits((float)a):-1082130432

Float.floatToIntBits((float)a):-1082130432

Float.floatToRawIntBits((float)b):-1082130432

Float.floatToIntBits((float)b):-1082130432

a div b:Infinity

a:2.002:958353678385

b:0.0

Double.doubleToLongBits(a):1072695345

Double.doubleToLongBits(a):1072695345

Double.doubleToRawLongBits(b):0

Double.doubleToRawLongBits(b):0

Float.floatToRawIntBits((float)a):1065369993

Float.floatToIntBits((float)a):1065369993

Float.floatToRawIntBits((float)b):0

Float.floatToIntBits((float)b):0

a:0.0000000000026E21

b:Q.0E-21

Double.doubleToLongBits(a):1149115873

Double.doubleToLongBits(a):1149115873

Double.doubleToRawLongBits(b):1002060865

Double.doubleToRawLongBits(b):1002060865

Float.floatToRawIntBits((float)a):1676734222

Float.floatToIntBits((float)a):1676734222

Float.floatToRawIntBits((float)b):500294153

Float.floatToIntBits((float)b):500294153



----------

I hope this will be helpful !
------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-11-29 14:55 -------
Well.. looking at your values here, it seems like the top and bottom dwords of 
the Double are getting exchanged, and that the top one is getting set to zero. 



This could be due to dword ordering, or alignment or both. In any case, I'm not 
entirely sure the problem is in the Double->ASCII conversion alone. It could be 
that the SableVM double-arithmetic on this architecture is broken. Or both 
could be broken. 




------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-12-01 11:43 -------
Okay, this could explain why double are not converted correctly. However float 
are on a single DWORD, hence it should work with float (which, I guess, are 
corrects)



However, even with float _dtoa doesn't work. Is there a _ftoa method ?



Thanks
------- Additional Comments From from-classpath at savannah dot gnu dot org  
2004-12-02 07:42 -------
We have seen somthing similar before. The problem for us was that doubles in 
tha Java class are stored as big endian. And the conversion did not correctly 
take into account that the arm has what we call a cross-endianess (i.e the 
dwords are exchanged). 



You could check if the bits differ when you store a float value in the class 
file and if you let it compute at run-time.
------- Additional Comments From rearnsha at gcc dot gnu dot org  2005-08-19 
13:41 -------
This may well be a duplicate of gcc PR 16132.  However, to be sure we would need
to know:

The version of gcc used to compile the code
The configuration of gcc
The options passed to the compiler.

-- 
           Summary: ARM double to ascii conversion issue
           Product: classpath
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: classpath
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: from-classpath at savannah dot gnu dot org
                CC: bug-classpath at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22800