printf_fp.c problem
Peter Barada
peter@the-baradas.com
Mon Aug 22 19:25:00 GMT 2005
>Sorry I didn't mention this before - I'm sure this is not a
>problem with the generic printf() software. I was hoping
>somebody would recognize the symptom and direct my search to
>a CPU specific file like __mpn_lshift().
>
>My system is a Coldfire v4e core and the CPU is a Freescale
>M5485. Glibc version is 2.3.2.
Yup, seen this behavior before.
I'll bet you that the problem is that the compiler loads the constant
65536.0 into a register and uses that instead of reloading the
register(%fp2 probably) across the printf calls, and that %f2 isn't
being saved/restored properly by the prologue/epilogue code.
Try the following:
void dump_double (double val)
{
union {
double d;
unsigned long ul[2];
} un;
un.d = val;
printf("%08x %08x\n", un.ul[0], un.ul[1]);
}
main()
{
double f;
f = 65535.0;
dump_double(f);
printf("%f\n",f);
f = 65536.0;
dump_double(f);
printf("%f\n",f);
}
Compile with '-O -mcfv4e'. If what I think is happening, then
the first hex value should look like:
40f00000 00000000
And then the first printf for the '%f' *may* be messed up, but the second
output from dump_double will *definitely* be messed up.
If so, then its the save/restore of the FP values that is broken.
Looc in gcc/config/m68k/m68k.c, and pour over
m68_output_function_prologue, especially where the mask is calculated
for the FP registers, and I think you'll find that its reversed for
the ColdFire...
--
Peter Barada
peter@the-baradas.com
More information about the Libc-alpha
mailing list