issues with doubles and -fno-schedule-insns2

issues with doubles and -fno-schedule-insns2

[Matthew J Fletcher]

Hi

i have a C code snipit that causes problems with gcc 3.3.4 and 3.4.1, i have 
not tried the v4 snapshots, in all cases are am hosted and targeting on i386.

void test(void)
{	
	unsigned int Value[2] = { 0x7FF00000, 0x7FF00000 };
	double *ValueD = (double *)&Value[0];
	
	// (*ValueD) should be "nan"
}

i've did some elimination and got the following results, seems 
-fno-schedule-insns2 is breaking things.

// gcc-3.3.4 -O3 -fno-schedule-insns2 (works)
// gcc-3.3.4 -O3 (fail) '(*ValueD) = 2.15833'
// gcc-3.3.4 -O2 -fno-schedule-insns2 (works)
// gcc-3.3.4 -O2 (fail) '(*ValueD) = 2.15833'
// gcc-3.3.4 -O1 (works)
// gcc-3.3.4 -O0 (works)

// gcc-3.4.1 -O3 -fno-schedule-insns2 (works)
// gcc-3.4.1 -O3 (fail) '(*ValueD) = 2.122e-314'
// gcc-3.4.1 -O2 -fno-schedule-insns2 (works)
// gcc-3.4.1 -O2 (fail) '(*ValueD) = 2.122e-314'
// gcc-3.4.1 -O1 (works)
// gcc-3.4.1 -O0 (works)


a small modification to the code to,..

unsigned int Value[2] = { 0x7FF00000, 0x7FF00000 };

void test(void)
{	
	double *ValueD = (double *)&Value[0];
	
	// (*ValueD) should be "nan"
}

and all the above compiler combinations work.

am i doing something wrong ?

regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050   Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com  Admin: post@serck-controls.co.uk
A subsidiary of Serck Controls Pty. Ltd. Reg. in England No. 4353634
**********************************************************************
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.


This message has been checked by MessageLabs
******************************************************************

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

[Dave Korn]

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

> in all cases are am hosted and targeting on i386.

> void test(void)
> {	
> 	unsigned int Value[2] = { 0x7FF00000, 0x7FF00000 };
> 	double *ValueD = (double *)&Value[0];
> 	
> 	// (*ValueD) should be "nan"
> }

> a small modification to the code to,..
> 
> unsigned int Value[2] = { 0x7FF00000, 0x7FF00000 };
> 
> void test(void)
> {	
> 	double *ValueD = (double *)&Value[0];
> 	
> 	// (*ValueD) should be "nan"
> }
> 
> and all the above compiler combinations work.
> 
> am i doing something wrong ?


  What's the natural alignment required for a double type on i386?

  My guess would be that the static array gets aligned correctly and the one
on the stack doesn't.  That's (just one of) the (many) reason(s) why
type-punning is bad.

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

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

[Nathan Sidwell]

Matthew J Fletcher wrote:
> Hi
> 
> i have a C code snipit that causes problems with gcc 3.3.4 and 3.4.1, i have 
> not tried the v4 snapshots, in all cases are am hosted and targeting on i386.

> 
> am i doing something wrong ?
yes. You are breaking the type based aliasing rules.  Your second example
'happens' to work, but don't rely on it doing so for later releases
or other slightly different uses.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

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

[Matthew J Fletcher]

On Friday 26 Nov 2004 2:27 pm, Nathan Sidwell wrote:
> Matthew J Fletcher wrote:
> > Hi
> >
> > i have a C code snipit that causes problems with gcc 3.3.4 and 3.4.1, i
> > have not tried the v4 snapshots, in all cases are am hosted and targeting
> > on i386.
> >
> >
> > am i doing something wrong ?
>
> yes. You are breaking the type based aliasing rules.  Your second example
> 'happens' to work, but don't rely on it doing so for later releases
> or other slightly different uses.

thats good to know,..

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 -fno-schedule-insns2 -march=486
 // produces correct 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:       c7 45 f8 00 00 f0 7f    movl   $0x7ff00000,0xfffffff8(%ebp)
 8048380:       c7 45 fc 00 00 f0 7f    movl   $0x7ff00000,0xfffffffc(%ebp)
 8048387:       51                      push   %ecx
 8048388:       8b 45 fc                mov    0xfffffffc(%ebp),%eax
 804838b:       50                      push   %eax
 804838c:       8b 55 f8                mov    0xfffffff8(%ebp),%edx
 804838f:       52                      push   %edx
 8048390:       68 84 84 04 08          push   $0x8048484
 8048395:       e8 ee fe ff ff          call   8048288 <_init+0x38>
 
 // 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.


 so i tried a diffrent example.

int main()
{
        unsigned long long Value = 0x7FF000007FF00000;
        double *ValueD = (double *)&Value;

        //(*ValueD) == nan(0x07ff00000)
        printf("Value = %g\n",(*ValueD));

        return 0;
}

// gcc 3.3.4 -O3 -march=486
// produces correct result

 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:       50                      push   %eax
 804837a:       68 00 00 f0 7f          push   $0x7ff00000
 804837f:       68 00 00 f0 7f          push   $0x7ff00000
 8048384:       68 84 84 04 08          push   $0x8048484
 8048389:       e8 fa fe ff ff          call   8048288 <_init+0x38>

which works,..

any pointers to 'type based aliasing rules' ? docs for simple folk ?

regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**********************************************************************
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050   Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com  Admin: post@serck-controls.co.uk
A subsidiary of Serck Controls Pty. Ltd. Reg. in England No. 4353634
**********************************************************************
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.


This message has been checked by MessageLabs
******************************************************************

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

[Giovanni Bajo]

Matthew J Fletcher <mfletcher@serck-controls.co.uk> wrote:

> docs for simple folk ?


Don't play tricks with pointers, period. A little longer: do not access an
object using a pointer to a type different from its natural type. You
defined two longs (or one long long) and were accessing them through
double*. This is invalid. Only exception: you can use char* to access
everything.

If you need to use such things, try -fno-strict-aliasing which will make
your code work. It is generally a bad idea because many optimizers will run
crippled when you disable strict aliasing.
-- 
Giovanni Bajo

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

[Dave Korn]

> -----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....

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

[Andrew Haley]

Matthew J Fletcher writes:
 > On Friday 26 Nov 2004 2:27 pm, Nathan Sidwell wrote:
 > 
 > any pointers to 'type based aliasing rules' ? docs for simple folk ?

You really need to read Section 6.3.2.3 in the standard, but I'll give
you the short form:

  Except for char*, which is a special case, you may not convert
  between pointers to incompatible types and then reference the result.

  gcc has a special extension which allows you to put different types
  into a union, write as one type and then read as another.

Andrew.