Mail Archives: djgpp-workers/1998/08/23/05:15:46
Eli Zaretskii wrote :
>
> I can solve the problem by using memcpy instead of the last assignment in
> SET_FLOAT_WORD macro, but I'd like to understand why is GCC generate such
> code, and why optimizations change that.
In my opinion this is a bug in gcc. If you look at the generated asm
code you will see, that the macros are totally optimized out and then
there is only the following for the three lines generated:
> SET_FLOAT_WORD(fv, 0x7fc00000U);
> GET_FLOAT_WORD(iv, fv);
> printf ("SET_FLOAT_WORD: %f, GET_FLOAT_WORD: %x\n", fv, iv);
(output from as -ahl test.s -o test.o
39:test.c **** SET_FLOAT_WORD(fv, 0x7fc00000U);
68 .stabn 68,0,39,LM3-_main
69 LM3:
70 003a 83C408 addl $8,%esp
40:test.c **** GET_FLOAT_WORD(iv, fv);
41:test.c **** printf ("SET_FLOAT_WORD: %f, GET_FLOAT_WORD:
%x\n", fv, iv);
71 .stabn 68,0,41,LM4-_main
72 LM4:
73 003d 680000C0 pushl $-4194304
73 FF
74 0042 680000F8 pushl $-524288
74 FF
75 0047 6A00 pushl $0
76 0049 68000000 pushl $LC0
76 00
77 004e E8ADFFFF call _printf
As you can see, the lines starting with 73 show, that gcc pushes
there already 0xffc00000 on the stack, which means it is already
wrong calculated by the optimizing internals of gcc.
If you use the trick with the memcpy in the macros, gcc will not
be able to completely optimizing out the macros and it will work
correct.
Robert
--
******************************************************
* email: Robert Hoehne <robert DOT hoehne AT gmx DOT net> *
* Post: Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW: http://www.tu-chemnitz.de/~sho/rho *
******************************************************
- Raw text -