printf always prints "nan" for double variables on MIPS

Kevin Nicoll blort128 at
Sat Feb 24 00:28:33 UTC 2007

Hello all,

I am using an embedded MIPS processor that is equipped with an MMU,
but no FPU.  However, it does have an FPU emulator built into its
linux kernel (2.6.18).  My MIPS toolchain uses gcc 3.4.5, binutils
2.15.97, and uclibc 0.9.28.  When I use printf to display the value of
a double variable, the value is always displayed to be "nan", even
though stepping through the program with GDB/GDBserver shows that the
double variables have the correct values.

Here is a simple test program I made to demonstrate this issue:

#include <stdio.h>

int main ()
        int i;
	long l;
        double d;
	float fl;

	i = 5;
	printf("\n"); /* for some reason, FPU version gets printed on the first \n */
	printf("Trial number %d\n", i);

	fl = 42;
	printf("Float value: %f\n", fl);

        l = 1234;
        printf("Long value: %ld\n", l);

	d = 12.34;
        printf("Double value: %lg\n", d);

        d /= 2.0;
        printf("Double after dividing by 2.0: %lg\n", d);

	i = (int)d;
	printf("Int after assigning it double: %d\n", i);

        d = (double)l;
        printf("Double after assigning it Long: %lg\n", d);


I compiled it with the following flags: -static -O0 -mhard-float.
When run on my MIPS device, the following output is printed:

Algorithmics/MIPS FPU Emulator v1.5
Trial number 5
Float value: nan
Long value: 1234
Double value: nan
Double after dividing by 2.0: nan
Int after assigning it double: 6
Double after assigning it Long: nan

Notice how even though printf outputs "nan" for the value of the
doubles, casting a double to an integer produces the value you'd
expect: in this case, (int)(12.34/2.0).  Again, when stepping through
the program using GDB, the value of the double is found to always
exist and be correct.

This occurs both when using the -mhard-float compiler flag, and when
using the -msoft-float compiler flag.  However, enabling "Use software
floating point by default" in the toolchain options of the top level
buildroot configuration file and compiling the program using the new
toolchain seems to let printf output the proper double values, for
either compiler flag.

Is this a bug in uClibc?  Or is it more likely to be a problem with my
configuration?  Using software floating point by default sort of makes
sense because of the lack of an FPU, but then why would printf output
"nan" when the value of the actual double is correct?  The FPU
emulator ought to take care of hardware floating point operations,
anyway.  Do you guys smell something fishy here, too?

Any input/ideas are greatly appreciated,

Kevin Nicoll

More information about the uClibc mailing list