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

[bugs at busybox.net]

A NOTE has been added to this issue. 
====================================================================== 
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-22-2008 22:18 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.
====================================================================== 

---------------------------------------------------------------------- 
 ambro - 02-17-08 04:54  
---------------------------------------------------------------------- 
I'm attaching the text file describing the format, it got messed up 

---------------------------------------------------------------------- 
 vapier - 02-22-08 22:18  
---------------------------------------------------------------------- 
yes, this will break some combinations as some floating point is big endian
on arm even if the cpu is little endian

try looking in glibc and/or gcc and/or the uClibc/.../arm directory to see
if you can find a good combination 

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                  
 
02-17-08 04:54  ambro          File Added: double-arm                       
02-17-08 04:54  ambro          Note Added: 0004974                          
02-22-08 22:18  vapier         Note Added: 0005264                          
======================================================================