Re: printf_fp.c problem

[Peter Barada <peter at the-baradas dot com>]

>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