[uClibc 0002204]: fpclassify and similar functions assume wrong double format

[bugs at busybox.net]

The following issue has been SUBMITTED. 
====================================================================== 
http://busybox.net/bugs/view.php?id=2204 
====================================================================== 
Reported By:                ambro
Assigned To:                uClibc
====================================================================== 
Project:                    uClibc
Issue ID:                   2204
Category:                   Math Library
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             02-17-2008 04:51 PST
Last Modified:              02-17-2008 04:51 PST
====================================================================== 
Summary:                    fpclassify and similar functions assume wrong double
format
Description: 
On ARM, little endian, softfloat, OABI,
the __fpclassify function assumes wrong double format, the regular little
endian format also used on x86. However the actual float format (at least
on my system) is different. This leads to fpclassify and related macros
failing miserably. E.g. valid values like 6250.47070227514860000 are being
reported as NAN by isnan().

I've been looking into this hard and found out what double format is in
use on my system and what uClibc expects:

s = sign bit
e1,e2 = exponent
m1,m2,m3 = mantissa

uClibc code expets:
<        LOW PART                 > <       HIGH PART                 >
-------- -------- -------- -------- -------- -------- -------- --------
<               m3                > <      m2       > <e2><m1> s< e1  >

REALITY in softfloat ARM little endian, OABI:
<         LOW PART                > <       HIGH PART                 >
-------- -------- -------- -------- -------- -------- -------- --------
<      m2       > <e2><m1> s< e1  > <               m3                >

meaning that low and high part are reversed. I've come across this bug
quite some time in the past but now I've tracked it down.

I've attached a workaround that seems to work, however I do not know the
exact circumstances when the format is reversed.
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-17-08 04:51  ambro          New Issue                                    
02-17-08 04:51  ambro          Status                   new => assigned     
02-17-08 04:51  ambro          Assigned To               => uClibc          
02-17-08 04:51  ambro          File Added: 140-float-arm.patch                  
 
======================================================================