Message-ID: <35DFF50D.7F9E4F2B@gmx.net> Date: Sun, 23 Aug 1998 10:55:09 +0000 From: Robert Hoehne Organization: none provided MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: Strange code generated by GCC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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 * * Post: Am Berg 3, D-09573 Dittmannsdorf, Germany * * WWW: http://www.tu-chemnitz.de/~sho/rho * ******************************************************