Bug 63621 - gcc emits wrong code when using -O2
gcc emits wrong code when using -O2
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.2
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-16 09:49 EDT by Yoav Zach
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-18 07:34:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
source code of test that demonstrate the bug (592 bytes, text/plain)
2002-04-16 09:50 EDT, Yoav Zach
no flags Details

  None (edit)
Description Yoav Zach 2002-04-16 09:49:18 EDT
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 09:50:52 EDT
Created attachment 54044 [details]
source code of test that demonstrate the bug
Comment 2 Jakub Jelinek 2002-04-16 11:02:22 EDT
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 02:54:15 EDT
I've compiled with -fno-strict-aliasing, but still - the problem remains.
Comment 4 Jakub Jelinek 2002-04-18 05:55:25 EDT
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 07:34:37 EDT
Sorry - a silly mistake of mine. The bug should be closed.

Note You need to log in before you can comment on or make changes to this bug.