[Top] [All Lists]

Re: GCC bug (was Re: Recently, ...)

Subject: Re: GCC bug (was Re: Recently, ...)
From: Systemkennung Linux <>
Date: Fri, 22 Dec 1995 12:40:45 +0100 (MET)
In-reply-to: <> from "Kai Harrekilde-Petersen" at Dec 22, 95 09:04:39 am

> > Btw - on the gcc mailinglist is a discussion about a GCC bug that
> > may be worked around by using -fno-strength-reduce.  Since I don't
> > have example code that shows the bug - does anybody of you know
> > if the bug also affect other architectures, especially MIPS?
> As far as I can tell, the bug could affect *all* architectures, since
> the bug is an overly-aggressive optimization in the arch-independent
> part (the buggy function is maybe_eliminate_biv_1() in loop.c).
> There have been posted code that exhibits the bug on the kernel list
> yesterday.  I have it at home, but I'm headed straight for my family
> in Copenhagen (I'm in Aarhus) after work, so I wont have time to send
> it out before I come back in january.
> Actually, a possible fix (by switching off the buggy code in gcc) was
> posted on gnu.gcc.bug already in *September*.  However, it did not
> make it into 2.7.1 or 2.7.2 -- I might note that the bugfix was sent from
> Germany, and it *appears* that FSF is rather slow to put in code / bug
> fixes that comes from Europe :-/

Well, I can't get rid of the impression the FSF is a very burocratic
institution.  This this the core of the problem.  The copyright assignments
are just one example.  On the other side I think the legal situation in
the US makes it mandantory for the FSF to behave like this ...

Well, yesterday I grep(1)-ed through a news server outside of
- et voila - I found two fixes and a piece of code to demonstate the bug.
One of the articles also contained a bit of background.  I append it below.

After reading the GCC code I'm pretty shure that this bug will also affect
MIPS.  I've also tested the example code below.  GCC fails to to optimize it
for Intel targets, but works fine for MIPS, 68k and Sparc.



Article: 10052 of gnu.gcc.bug
From: (Richard Henderson)
Newsgroups: gnu.gcc.bug
Subject: gcc 2.7.2 i386 strength-reduce bug fix
Date: 19 Dec 1995 21:49:42 -0500
Organization: GNUs Not Usenet
Lines: 71
Distribution: gnu
Message-ID: <>

The strength-reduction optimization in gcc 2.7.2 (and earlier) can
produce incorrect code on the i386 platform.

The problem is that the giv chosen to eliminate a biv may overflow,
causing comparisons to fail.  The temporary solution is to simply
prevent the elimination.  A more complete solution would use initial
and final value information to assert that the replacement remains in
range for the type.

Another way the optimization might be retained is if the loop is
transformed to:

        if (x < end) { do { ... } while (x != end); }

Naturally, there are some severe restrictions on when this might be
used, but a number of simple ones (such as the example below) that
could benefit.

Here is an example that reproduces the bug:
int A[3];
unsigned int B = 3;
void printit(void)
    int i;
    for(i = 0; i < B; i++)
        printf("A[%d] = %d\n", i, A[i]);
int main()
    int i;
    for(i = 0; i < B; i++)
        A[i] = i-3;
    return 0;

Here is a patch that defeats the elimination of a biv involved in a
*** loop.c.orig Tue Oct  3 11:17:16 1995
--- loop.c      Tue Dec 19 19:38:29 1995
*************** maybe_eliminate_biv_1 (x, insn, bl, elim
*** 6119,6124 ****
--- 6119,6127 ----
+       /* Unless we can assert that the replacement giv does not 
+          overflow, we cannot (simply) eliminate the biv. */
+ #if 0
        if (CONSTANT_P (arg))
          /* First try to replace with any giv that has constant positive
*************** maybe_eliminate_biv_1 (x, insn, bl, elim
*** 6264,6269 ****
--- 6267,6273 ----
+ #endif
        /* If we get here, the biv can't be eliminated.  */
        return 0;


<Prev in Thread] Current Thread [Next in Thread>