commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[commit-cp] [bugs #11058] ARM double to ascii conversion issue


From: Sven de Marothy
Subject: [commit-cp] [bugs #11058] ARM double to ascii conversion issue
Date: Fri, 19 Nov 2004 17:59:23 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922

This mail is an automated notification from the bugs tracker
 of the project: classpath.

/**************************************************************************/
[bugs #11058] Latest Modifications:

Changes by: 
                Sven de Marothy <address@hidden>
'Date: 
                Fri 11/19/2004 at 22:53 (Europe/Stockholm)

------------------ Additional Follow-up Comments ----------------------------
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!







/**************************************************************************/
[bugs #11058] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11058>
Project: classpath
Submitted by: 0
On: Fri 11/19/2004 at 17:56

Category:  classpath
Severity:  5 - Average
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open
Platform Version:  None


Summary:  ARM double to ascii conversion issue

Original Submission:  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



Follow-up Comments
------------------


-------------------------------------------------------
Date: Fri 11/19/2004 at 22:53       By: Sven de Marothy <smarothy>
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!













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=11058>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/







reply via email to

[Prev in Thread] Current Thread [Next in Thread]