Bug 10684 - [3.3/3.4/4.0 regression] register variable update disappears when using -O
Summary: [3.3/3.4/4.0 regression] register variable update disappears when using -O
Status: RESOLVED DUPLICATE of bug 7871
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.2
: P2 minor
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
: 13414 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-08 16:06 UTC by joerg-cyril.hoehle
Modified: 2004-09-13 14:15 UTC (History)
4 users (show)

See Also:
Host:
Target: i486-suse-linux
Build:
Known to work: 3.1
Known to fail:
Last reconfirmed: 2003-12-03 08:22:54


Attachments
bugO.c (803 bytes, application/octet-stream)
2003-05-21 15:17 UTC, joerg-cyril.hoehle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description joerg-cyril.hoehle 2003-05-08 16:06:01 UTC
Using -O2 or -O1, a case is exhibited where an update to a global register variable disappears from the assembly output.

Release:
3.2 (also seen with 3.0)

Environment:
Linux sql-server 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown
Suse-Linux 8.1, using binary distribution of gcc from CD-ROM.

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.2/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux
Thread model: posix
gcc version 3.2
[Bug was also seen for 3.0]

How-To-Repeat:
In the attached program the function convert_from_foreign_array_fill() is miscompiled.

$ gcc -O0 bugO.c; a.out ; echo $?
0
$ gcc -O2 bugO.c; a.out ; echo $?
1

Please look at the code generated by gcc -O2 -S bugO.c for convert_from_foreign_array_fill() and search for lines matching ebx.
You'll find three of them, but 4 in the -O0 case.

The
        addl    $4, %ebx
disappeared. That was the update part of pushSTACK().

Please add this sample program to your testsuite.
Comment 1 Jim Wilson 2003-05-08 16:39:10 UTC
From: Jim Wilson <wilson@tuliptree.org>
To: gcc-gnats@gcc.gnu.org
Cc: Joerg-Cyril.Hoehle@T-Systems.com, gcc-bugs@gcc.gnu.org, bruno@clisp.org,
 sds@gnu.org
Subject: Re: optimization/10684: register variable update disappears when using
 -O
Date: Thu, 08 May 2003 16:39:10 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10684
 
 This is related to PR c/7871 which I have already done a lot of analysis 
 work on.  There appear to be multiple bugs in the handling of global 
 register variables, and they have been there since the gcc-3.0 release.
 
 Jim
Comment 2 Christian Ehrhardt 2003-05-08 18:52:25 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed, still present in 3.4-cvs. This is a reduced testcase:
    
    register int STACK __asm__("%ebx");
    static void (*p) ();
    void f ()
    {
            STACK += 1;
            p ();
            STACK -= 1;
    }
    
    Looking at the assembly shows that STACK += 1 ist lost if compiled
    with -O. The problem seems to be that life analysis adds a REG_DEAD
    note to the call to (*p) which makes STACK += 1 a dead store.
    
       regards  Christian
Comment 3 Andrew Pinski 2003-06-07 19:22:31 UTC
It still happens on the mainline (20030607):

It happens between *.20.life and *.21.combine.
Comment 4 Jim Wilson 2003-06-08 04:03:11 UTC
Subject: Re:  register variable update disappears
	when using -O

On Sat, 2003-06-07 at 12:22, pinskia@physics.uc.edu wrote:
> It still happens on the mainline (20030607):

I haven't checked in any patches for this problem yet.  Everything I
have tried so far has broken something else.  This is turning out to be
a rather involved problem.  I haven't worked on this in a month, I am
hoping that I will have time to work on it again before the end of June.

Jim


Comment 5 Andrew Pinski 2003-08-20 04:16:46 UTC
I think this is related to bug 11413 and bug 7871.
Comment 6 Wolfgang Bangerth 2003-08-29 18:07:18 UTC
This has incorrectly not been marked as a regression, see  
  http://gcc.gnu.org/ml/gcc/2003-08/msg01744.html 
Done hereby. 
W. 
Comment 7 Andrew Pinski 2003-12-16 20:05:27 UTC
*** Bug 13414 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2004-01-10 07:04:06 UTC
global registers are evil.
Comment 9 Andrew Pinski 2004-01-13 04:31:09 UTC
this is also a regression from 3.0.4.
Comment 10 Andrew Pinski 2004-01-13 04:37:02 UTC
Okay, I found out when it started to happen:
between 3.2 20020601 and 3.2 20020713 (sorry I cannot reduce the time frame now but it would 
be easy using the regressions scripts in contrib).
Comment 11 Andrew Pinski 2004-01-14 17:49:23 UTC
Related to bug 7871 (they really might be both caused by the same patch).
Comment 12 Eric Botcazou 2004-02-03 07:46:44 UTC

*** This bug has been marked as a duplicate of 7871 ***