Bug 16471 - Optimization -O1 leads to incorrect code
Summary: Optimization -O1 leads to incorrect code
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.1
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2004-07-11 07:25 UTC by Alexander Stante
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux
Target: i686-pc-linux
Build:
Known to work: 4.0.0
Known to fail: 2.95.3 3.0.4 3.2.3 3.3.3 3.4.0
Last reconfirmed:


Attachments
preprocessed file (3.39 KB, application/x-bzip)
2004-07-11 07:44 UTC, Alexander Stante
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Stante 2004-07-11 07:25:39 UTC
I encountered a problem with the generated code if the -O1 switch is on. Suppose
the following code:

#include <stdio.h>

int main()
{
    int x=10;
    const int y[1] = {(x + x)};
    x = y[0];
    printf("%d\n",y[0]);
    return 0;
}

The correct output of the printf would be '20', but with optimization turned on
it is '40'.

I made following observations which maybe help narrowing down the cause of the
problem:
If you add a additional "x = y[0]" assignment just before the printf() the
result will be '80', if you just again the statement you will get '160'. It just
 like that the (x + x) expression is evaluated and assigned internally more
often. If you change (x + x) into (x * x) you will get as wrong results 10000,
100000000 and so on depending how often you write the "x = y[0]" statement. 
Furthermore the values of x and y[0] are not equal if you read somwhere later
from x, for example with a modified printf() statement which outputs both values. 

If you check the assembler output you can see that the calculation of (x + x) is
made at compile time to optimize the code (movl    $40, 4(%esp)):

main:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $8, %esp
    andl    $-16, %esp
    subl    $16, %esp
    movl    $40, 4(%esp)
    movl    $.LC0, (%esp)
    call    printf
    movl    $0, %eax
    leave
    ret

The full command line for compilation was: 
$ /usr/local/gcc-3.4.1/bin/gcc -O1 test.c

gcc Version:
$ /usr/local/gcc-3.4.1/bin/gcc -v
Reading specs from /usr/local/gcc-3.4.1/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=/usr/local/gcc-3.4.1/
Thread model: posix
gcc version 3.4.1

I tested the code above against three other compilers (arm and m68k targets)
with the same result in code generation (wrong calculated value of y[0] at
compile time), here the versions:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.3/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.3 (Debian 20040401)

$ arm-agb-elf-gcc -v
Reading specs from /usr/local/devkitadv/lib/gcc-lib/arm-agb-elf/3.1/specs
Configured with: ../gcc-3.1/configure --prefix=/usr/local/devkitadv
--target=arm-agb-elf --with-cpu=arm7tdmi --without-local-prefix --with-newlib
--with-headers=../newlib-1.10.0/newlib/libc/include/ --with-gc=simple
--enable-multilib --enable-interwork --enable-languages=c++
--enable-targets=arm-elf,arm-coff,arm-aout --disable-threads -v
Thread model: single
gcc version 3.1 (Linux DevKit-Advance by Tom Badran tb100@doc.ic.ac.uk)

$ m68k-neogeo-elf-gcc -v
Reading specs from
/home/ice/Projekte/devkitng/bin/bin/../lib/gcc-lib/m68k-neogeo-elf/3.3.2/specs
Configured with: ../../gcc-3.3.2/configure --target=m68k-neogeo-elf
--prefix=/home/ice/Projekte/devkitng/bin/
Thread model: single
gcc version 3.3.2
Comment 1 Alexander Stante 2004-07-11 07:44:16 UTC
Created attachment 6720 [details]
preprocessed file
Comment 2 Giovanni Bajo 2004-07-11 12:52:06 UTC
Confirmed with every compiler since GCC 2.95 up to 3.4.1, but already fixed in 
mainline with the recent tree optimizers.

As this bug is not a regression, and it is fixed in mainline, there is no 
chance to have a fix for the 3.3 or 3.4 serie.