From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.18 i686) Description of problem: When compiling the attached test case with -O2, gcc emits code which is not correct. The test case will yield wrong results when complied with -O2. See the 'additional info' for more details. Version-Release number of selected component (if applicable): I tried two versions - 1) gcc version 2.96 20000731 2) gcc version 3.0.2 20010905 How reproducible: Always Steps to Reproduce: 1.build the attached test with optimizations off 2.run the binary 3.build the test with -O2 4.run the binary Actual Results: the output of the binaries of the two builds differ Expected Results: the output of the build with optimizations on should be the same as the build w/o optimizations Additional info: here is the c-code of the problematic function : ------------ start code -------------- static long func1(int aaa,unsigned bbb,unsigned data) { long retval; long ccc = -1l; retval = func2 (aaa, (unsigned long)bbb, &ccc); if (retval != 0) { return retval; } *(unsigned int*)&ccc = data; retval = func3 (5, aaa, (unsigned long)bbb, (unsigned long)ccc); return retval; } ---------------- end code ----------------------- here is the disassembly of the resulted code when compiled with -O2: ---------------- start disassembly -------------- 1 <func1>: 2 alloc r38=ar.pfs,11,7,0 3 adds r12=-16,r12;; 4 adds r14=16,r12 5 mov r35=-1 6 zxt4 r33=r33 7 mov r37=b0;; 8 st8 [r14]=r35 9 mov r36=r1 10 mov r39=r32 11 mov r40=r33 12 mov r41=r14 13 br.call.sptk.many b0=<func2>;; 14 mov r14=r8 15 mov r1=r36 16 mov r40=r32;; 17 cmp.eq p6,p7=0,r14 18 mov r41=r33 19 mov r42=r35;; 20 (p06) adds r14=16,r12 21 nop.f 0x0 22 mov r39=5;; 23 (p06) st4 [r14]=r34 24 nop.f 0x0 25 (p06) br.call.dpnt.many b0=<func3>;; 26 nop.m 0x0 27 mov.i ar.pfs=r38 28 mov b0=r37 29 adds r12=16,r12 30 nop.f 0x0 31 br.ret.sptk.many b0;; 32 ---------------- end disassembly -------------- r42 is the 4th param to func3 (line 19). it gets its value from r33, which holds the inital value of ccc (line 5). the value of ccc is updated (line 23) but it does not affect the valued passed to func3 (line 25).
Created attachment 54044 [details] source code of test that demonstrate the bug
When ccc's type is long, *(unsigned int*)&ccc = data; is not valid C, so gcc can do anything it wants. See info gcc about -fstrict-aliasing. Either fix your code (e.g. by accessing it through an union), or use -fno-strict-aliasing.
I've compiled with -fno-strict-aliasing, but still - the problem remains.
The problem goes away, at least on the testcase you attached: gcc -v; gcc -O2 -o x2 x.c; gcc -O2 -fno-strict-aliasing -o x2nsa x.c; gcc -o x0 x.c; ./x2; ./x2nsa; ./x0 Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) func3: req=5 aaa=3 bbb=4 ccc=ffffffffffffffff func3: req=5 aaa=3 bbb=4 ccc=ffffffff00000005 func3: req=5 aaa=3 bbb=4 ccc=ffffffff00000005 gcc -v; gcc -O2 -o x2 x.c; gcc -O2 -fno-strict-aliasing -o x2nsa x.c; gcc -o x0 x.c; ./x2; ./x2nsa; ./x0 Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.1/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=ia64-redhat-linux --with-system-zlib Thread model: posix gcc version 3.1 20020327 (Red Hat Linux Rawhide 3.1-0.24) func3: req=5 aaa=3 bbb=4 ccc=ffffffffffffffff func3: req=5 aaa=3 bbb=4 ccc=ffffffff00000005 func3: req=5 aaa=3 bbb=4 ccc=ffffffff00000005
Sorry - a silly mistake of mine. The bug should be closed.