Subject: gcc bug

From: root <[email-masked]>
Date: Mon, 04 Sep 1995 16:53:50 -0400

gcc 2.6.3 or 2.7.0 can generate incorrect code for the '86
architecture when used with the -O2 switch but not
-fno-strength-reduce (and by default, the kernel is compiled with just
this combination).  The following patch enables -fno-strength-reduce
all the time.  (Thanks to Jurgen Botz <[email-masked]>.)  

A test program follows.

                         - Jim Van Zandt

===================================================================
--- 1.1	1995/09/04 01:26:00
+++ /usr/lib/gcc-lib/i486-linux/2.6.3/specs	1995/09/04 15:11:29
@@ -8,10 +8,10 @@
 %{!m386:-D__i486__} %{posix:-D_POSIX_SOURCE}
 
 *cc1:
-
+-fno-strength-reduce
 
 *cc1plus:
-
+-fno-strength-reduce
 
 *endfile:
 
/*
Article 12633 of comp.os.linux.development.system:
Path: linus.mitre.org!blanket.mitre.org!agate!howland.reston.ans.net!news.sprintlink.net!in2.uu.net!news.iii.net!iii2.iii.net!not-for-mail
From: [email-masked] (Craig Shrimpton)
Newsgroups: comp.os.linux.development.system
Subject: GCC bug : Does your kernel have a time bomb?
Date: 31 Aug 1995 18:38:53 -0400
Organization: iii.net
Lines: 51
Message-ID: <[email-masked]>
NNTP-Posting-Host: iii2.iii.net
X-Newsreader: TIN [version 1.2 PL2]

Greetings,

Today a potentially serious gcc bug has been brought to my attention.  
This bug concerns the -O2 optimization flag that is supplied by default 
in the kernel distributions.  If you use -O2 optimization without also 
specifying -fno-strength-reduce, computations against arrays in loops 
can, under certain conditions, return incorrect results.  It concerns me 
greatly since this bug has gone undetected for a long time.  Its 
potential to cause wierd inconsistencies is rather astounding.  The 
following C program demonstrates the bug.  This bug will manifest itself 
whenever B >= whatever number is subtracted from i.

Please review this program and post suggestions.  I sincerely hope that 
I'm wrong about this because this situation could occur in the kernel under 
many instances.

Compile this program as follows:

gcc -O2 -o try try.c 

and then as:

gcc -O2 -fno-strength-reduce -o try try.c

The problem will become readily apparent.

-Craig

[ I've changed 'test' to 'try' to avoid conflict with /usr/bin/test -jrv ]

----------------------------- try.c -------------------------------
*/

#include <stdio.h>
int A[3];
unsigned int B = 3;

void printit(void)
{
int i;
for(i = 0; i < B; i++)
   fprintf(stdout, "A[%d] = %d\n", i, A[i]);
}

int main()
{
int i;
for(i = 0; i < B; i++)
   A[i] = i - 3;
printit();
return 0;
}