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.
140-float-arm.patch [^] (402 bytes) 02-17-08 04:51 double-arm [^] (553 bytes) 02-17-08 04:54 
