Closed GoogleCodeExporter closed 8 years ago
It turns out that the problem is in the SuperUX's implementation of "strtof"
function. Although it is defined as "extern float strtof(const char *, char **)"
(which means it should return a 32-bit floating point number), it actually
return a
64-bit floating point number (i.e. a double). Let's examine the strtof's
assembly code:
0x4000156f0 : 1f1b9b00 cvs $s27,$s27
0x4000156f4 : 0f1a9b00 cvd $s26,$s27
0x4000156f8 : 457c009a or $s124,0,$s26
0x4000156fc : 0e012081 00000000 ldm $s1,32,0(,$s1)
0x400015704 : 193f00a0 00000000 b> 0,0(,$s32)
we can see that before the result is returned, the function converts it to
64-bit
floating point, using the "cvd" instruction.
On the other hand, the calling function assumes "strtof" returned 32-bit
floating
point number. This is why we get incorrect results. For example: when invoking
strtof("1.0") function, it returns the 3ff0000000000000 value which 64-bit
hexadecimal representation for 1.0 number. This value should be converted to
32-bit
floating point number. Unfortunately, the calling function doesn't perform this
conversion, but incorrectly assumes that 32-bit "3ff00000" value was returned.
This
value corresponds to the 1.875 floating point value.
Original comment by nou...@gmail.com
on 19 Jun 2009 at 11:20
is this a superux header issue (i.e. is the float strtof()) declaration part of
sys-include/*)?
in this case, use fixincludes machinery to fix the headers.
Original comment by jmoc...@gmail.com
on 19 Jun 2009 at 11:25
Jaka, excellent suggestion! I also considered solving this issue by modifying
the
"strtof"'s signature with fixincludes script.
This issue is fixed in the r300 revision of sx-gcc.
Original comment by nou...@gmail.com
on 30 Jun 2009 at 10:14
Original issue reported on code.google.com by
nou...@gmail.com
on 19 Jun 2009 at 10:03