Bug 25692 - Strange results with cast when using -O2 flag or not under Linux ppc64
Summary: Strange results with cast when using -O2 flag or not under Linux ppc64
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.4.4
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-06 14:14 UTC by fm
Modified: 2006-01-06 14:53 UTC (History)
55 users (show)

See Also:
Host: powerpc64-ibm
Target: powerpc64-linux
Build: powerpc64-linux RedHat 4.0
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Small sample to illustrate the problem (202 bytes, text/plain)
2006-01-06 14:19 UTC, fm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fm 2006-01-06 14:14:56 UTC
Hello,

Here is a small sample to repeat the case:

------------
#include <stdio.h>

main()
{
   double d1, *pd1;
   char *c = (char*)&d1;

   pd1 = &d1;
   ((int*)pd1)[0] = -1;
   ((int*)pd1)[1] = -1;

   fprintf(stderr,">> d1 = %lf\n", d1);

   fprintf(stderr,">> int: %d %d\n", ((int*)pd1)[0], ((int*)pd1)[1]);

   fprintf(stderr,">> c1 = %02x\n", c[0]);
   fprintf(stderr,">> c2 = %02x\n", c[1]);
   fprintf(stderr,">> c3 = %02x\n", c[2]);
   fprintf(stderr,">> c4 = %02x\n", c[3]);
   fprintf(stderr,">> c5 = %02x\n", c[4]);
   fprintf(stderr,">> c6 = %02x\n", c[5]);
   fprintf(stderr,">> c7 = %02x\n", c[6]);
   fprintf(stderr,">> c8 = %02x\n", c[7]);
}

------------

When I compile with `gcc -m64 -o b64 b64.c`, the output is correct:

>> d1 = nan
>> int: -1 -1
>> c1 = ff
>> c2 = ff
>> c3 = ff
>> c4 = ff
>> c5 = ff
>> c6 = ff
>> c7 = ff
>> c8 = ff

But when I use the optimise flag, `gcc -O2 -m64 -o b64 b64.c`, and run again the sample, there is a problem with the results. See bellow:

>> d1 = 0.000000
>> int: -1 -1
>> c1 = ff
>> c2 = ff
>> c3 = ff
>> c4 = ff
>> c5 = ff
>> c6 = ff
>> c7 = ff
>> c8 = ff

Gcc release:

Using built-in specs.
Target: ppc64-redhat-linux
Configured with: ../gcc-4.0.0/configure --prefix=/home/comp/gcctest4.0.0 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0

Environment:

Linux 2.6.9-11.EL #1 SMP Fri May 20 18:18:48 EDT 2005 ppc64 ppc64 ppc64 GNU/Linux

Best regards.
Comment 1 fm 2006-01-06 14:19:09 UTC
Created attachment 10589 [details]
Small sample to illustrate the problem

How to repeat sample
Comment 2 Andrew Pinski 2006-01-06 14:20:46 UTC
You are violating C aliasing rules as you acess d1 via an int.

*** This bug has been marked as a duplicate of 21920 ***
Comment 3 fm 2006-01-06 14:46:50 UTC
Maybe...

But I made some tests under Linux X86 and some AIX 64 bits. This code works as expected everywhere...
So, I wonder why gcc behaviour is différent under this Linux PPC64 ?
Comment 4 Andrew Pinski 2006-01-06 14:53:58 UTC
(In reply to comment #3)
> Maybe...
> 
> But I made some tests under Linux X86 and some AIX 64 bits. This code works as
> expected everywhere...
> So, I wonder why gcc behaviour is différent under this Linux PPC64 ?

Because PPC 64 schedules code more aggressively.  Anyways the code is undefined so anything can happen.