jkmcnk / sx-gcc

The GNU Compiler Collection port to NEC SX CPU architecture.
GNU General Public License v2.0
0 stars 2 forks source link

incorrect conversion of strngs to floating point number when using "strtof" function #137

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The test below fails if compiled with sx-gcc:

{{{

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    float f;
    char* __sanity;
    f = strtof("1e", &__sanity);

    if (f != 1.0) {
        abort();
    }
    return 0;
}

}}}

The problem is in "strtof" function which converts "1e" to 1.875 instead of
1.0.

As a consequence, a number of tests fail (e.g.
"22_locale/num_get/get/char/10.cc").

Original issue reported on code.google.com by nou...@gmail.com on 19 Jun 2009 at 10:03

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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