Bug 63621

Summary: gcc emits wrong code when using -O2
Product: [Retired] Red Hat Linux Reporter: Yoav Zach <yoav.zach>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-04-18 11:34:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
source code of test that demonstrate the bug none

Description Yoav Zach 2002-04-16 13:49:18 UTC
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).

Comment 1 Yoav Zach 2002-04-16 13:50:52 UTC
Created attachment 54044 [details]
source code of test that demonstrate the bug

Comment 2 Jakub Jelinek 2002-04-16 15:02:22 UTC
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.

Comment 3 Yoav Zach 2002-04-18 06:54:15 UTC
I've compiled with -fno-strict-aliasing, but still - the problem remains.

Comment 4 Jakub Jelinek 2002-04-18 09:55:25 UTC
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

Comment 5 Yoav Zach 2002-04-18 11:34:37 UTC
Sorry - a silly mistake of mine. The bug should be closed.