[MiNT] possible gcc bug ???

[Alan Hourihane <alanh@fairlite.co.uk>]

Hi Vincent,

I'm not sure whether this is a bug or not, but very different outputs
for long double output here.

If I compile this code....

/* "before" is 16 bytes to ensure there's no padding between it and "x".
   We're not expecting any "long double" bigger than 16 bytes or with
   alignment requirements stricter than 16 bytes.  */
struct {
  char         before[16];
  long double  x;
  char         after[8];
} foo = {
  { '\0', '\0', '\0', '\0', '\0', '\0', '\0', '\0',
    '\001', '\043', '\105', '\147', '\211', '\253', '\315', '\357' },
  -123456789.0,
  { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' }
};

with gcc -c db.c, and then run "od -b db.o" on it I get....

0000000 000 002 001 007 000 000 000 000 000 000 000 044 000 000 000 000
0000020 000 000 000 014 000 000 000 000 000 000 000 000 000 000 000 000
0000040 000 000 000 000 000 000 000 000 001 043 105 147 211 253 315 357
0000060 300 031 000 000 353 171 242 240 000 000 000 000 376 334 272 230
0000100 166 124 062 020 000 000 000 004 007 000 000 000 000 000 000 000
0000120 000 000 000 011 137 146 157 157 000

But with gcc -mcpu=5475 -c db.c, and then run "od -b db.o" on it I get....

0000000 000 002 001 007 000 000 000 000 000 000 000 040 000 000 000 000
0000020 000 000 000 014 000 000 000 000 000 000 000 000 000 000 000 000
0000040 000 000 000 000 000 000 000 000 001 043 105 147 211 253 315 357
0000060 301 235 157 064 124 000 000 000 376 334 272 230 166 124 062 020
0000100 000 000 000 004 007 000 000 000 000 000 000 000 000 000 000 011
0000120 137 146 157 157 000

Notice the line that starts 0000060, which is the part I'm interested
in, in how the compiler shows "long doubles". It's obviously different,
and I'm not sure what format our m68k target is storing "long doubles"
in, but the coldfire it seems it's IEEE double, big endian.

Thanks,

Alan.