RE: issues with doubles and -fno-schedule-insns2

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: gcc-owner On Behalf Of Matthew J Fletcher
> Sent: 26 November 2004 15:25

> however i forgot to mention that i am targeting (march=i486) 
> for my embedded 
> sc520, dont know if its relivant to the following. i dont 
> understand what 
> 'schedule-insns2' is doing, but it seems to be doing the 
> wrong thing, again i 
> could be very wrong.
> 
> int main()
> {
>         unsigned int Value[2] = { 0x7FF00000, 0x7FF00000 };
>         double *ValueD = (double *)&Value[0];
> 
>         //(*ValueD) == nan(0x07ff00000)
>         printf("Value = %g\n",(*ValueD));
> 
>         return 0;
> }

>  // gcc 3.3.4 -O3 -march=486
>  // produces wrong result
>  08048370 <main>:
>  8048370:       55                      push   %ebp
>  8048371:       89 e5                   mov    %esp,%ebp
>  8048373:       83 ec 08                sub    $0x8,%esp
>  8048376:       83 e4 f0                and    $0xfffffff0,%esp
>  8048379:       8b 45 fc                mov    0xfffffffc(%ebp),%eax
>  804837c:       51                      push   %ecx
>  804837d:       50                      push   %eax
>  804837e:       8b 55 f8                mov    0xfffffff8(%ebp),%edx
>  8048381:       52                      push   %edx
>  8048382:       68 84 84 04 08          push   $0x8048484
>  8048387:       c7 45 f8 00 00 f0 7f    movl   
> $0x7ff00000,0xfffffff8(%ebp)
>  804838e:       c7 45 fc 00 00 f0 7f    movl   
> $0x7ff00000,0xfffffffc(%ebp)
>  8048395:       e8 ee fe ff ff          call   8048288 <_init+0x38>
> 
>  note, movl's after push's which, i think just pushed crap 
> onto the stack.

  The thing is, that the compiler has scheduled the two instructions that
initialise the Value[2] _array_ after the code that accesses it and prints
it out.

  Normally that would be a very very bad bug of the compiler indeed.

  But this time, it's fair enough.

  The compiler had every right to defer the initialisation of those unsigned
ints, because it thought they weren't being accessed yet, and the reason it
thought that is because it looks at the type of the pointer that you're
dereferencing in the printf and says to itself "Oh, that's a pointer to a
double - it can't possibly be the same thing as those two unsigned ints
because they're different types, so I needn't worry about it affecting or
being affected by those two unsigned ints, so I can assume those two
unsigned ints haven't been referenced by anything yet, so I can defer
initialising them for as long as I like."

  By accessing those variables through a pointer of the wrong type, you are
effectively lying to the compiler; and because it trusts what you tell it,
it gets completely fooled.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....