/*
#include <stdio.h>
*/
#define SMALL_N 2
#define NUM_ELEM 4
int main(void)
{
int listElem[NUM_ELEM]={30,2,10,5};
int listSmall[SMALL_N];
int i, j;
int posGreatest=-1, greatest=-1;
for (i=0; i<SMALL_N; i++) {
listSmall[i] = listElem[i];
if (listElem[i] > greatest) {
posGreatest = i;
greatest = listElem[i];
}
}
for (i=SMALL_N; i<NUM_ELEM; i++) {
if (listElem[i] < greatest) {
listSmall[posGreatest] = listElem[i];
posGreatest = 0;
greatest = listSmall[0];
for (j=1; j<SMALL_N; j++)
if (listSmall[j] > greatest) {
posGreatest = j;
greatest = listSmall[j];
}
/*
printf("%d\n", posGreatest);
*/
}
}
printf("Correct output: 5 2\n");
printf("GCC output: ");
for (i=0; i<SMALL_N; i++) printf(" %.1d", listSmall[i]);
printf("\n");
return (1);
}
> I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc
> 2.91.66) and gcc 2.95.2 versions.
>
> I am attaching you a simplified test program ('bug.c', a really simple
> program).
Well gcc-bugs would be the better place to send it but this is a known problem
fixed in CVS gcc 2.95.3, CVS gcc 3.0 branch and gcc 2.96 (unofficial, Red Hat)
On Mon, Feb 26, 2001 at 05:15:28PM +0000, Alan Cox wrote:
> > I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc
> > 2.91.66) and gcc 2.95.2 versions.
> >
> > I am attaching you a simplified test program ('bug.c', a really simple
> > program).
>
> Well gcc-bugs would be the better place to send it but this is a known problem
> fixed in CVS gcc 2.95.3, CVS gcc 3.0 branch and gcc 2.96 (unofficial, Red Hat)
I'm not sure if it is known, at least not known to me, but definitely not
fixed in any of gcc 2.95.2, CVS gcc 3.0 branch, CVS gcc 3.1 head, gcc 2.96-RH.
Jakub
> > Well gcc-bugs would be the better place to send it but this is a known problem
> > fixed in CVS gcc 2.95.3, CVS gcc 3.0 branch and gcc 2.96 (unofficial, Red Hat)
>
> I'm not sure if it is known, at least not known to me, but definitely not
> fixed in any of gcc 2.95.2, CVS gcc 3.0 branch, CVS gcc 3.1 head, gcc 2.96-RH.
Sorry my error for assuming it was the exsting known strength reduce bug
On Mon, 26 Feb 2001, Alan Cox wrote:
> > > Well gcc-bugs would be the better place to send it but this is a known problem
> > > fixed in CVS gcc 2.95.3, CVS gcc 3.0 branch and gcc 2.96 (unofficial, Red Hat)
> >
> > I'm not sure if it is known, at least not known to me, but definitely not
> > fixed in any of gcc 2.95.2, CVS gcc 3.0 branch, CVS gcc 3.1 head, gcc 2.96-RH.
>
> Sorry my error for assuming it was the exsting known strength reduce bug
>
Script started on Mon Feb 26 12:54:20 2001
# gcc -o xxx bug.c
# ./xxx
Correct output: 5 2
GCC output: 5 2
# gcc --version
egcs-2.91.66
# gcc -O2 -o xxx bug.c
# ./xxx
Correct output: 5 2
GCC output: 10 5
# exit
exit
Script done on Mon Feb 26 12:55:21 2001
Definitely has something to do with broken optimization. No optimization,
no bug, turn on '-O2' and you have the bug.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
At 01:02 PM 2/26/01, Alan Cox wrote:
> > > Well gcc-bugs would be the better place to send it but this is a
> known problem
> > > fixed in CVS gcc 2.95.3, CVS gcc 3.0 branch and gcc 2.96 (unofficial,
> Red Hat)
> >
> > I'm not sure if it is known, at least not known to me, but definitely not
> > fixed in any of gcc 2.95.2, CVS gcc 3.0 branch, CVS gcc 3.1 head, gcc
> 2.96-RH.
>
>Sorry my error for assuming it was the exsting known strength reduce bug
It's broken in my copy of gcc.2.95.3 ...
David
On 02.26 Alan Cox wrote:
Also fails in gcc-2.96-0.38mdk (Mandrake Cooker):
rpm -q --changelog gcc
* Sat Feb 17 2001 Chmouel Boudjnah <[email protected]> 2.96-0.38mdk
- exit 0 if [ $1 = 0 ] if we are in %postun (to don't screwd up the
alternatives).
* Thu Feb 15 2001 David BAUDENS <[email protected]> 2.96-0.37mdk
- Fix build on PPC :)
* Thu Feb 15 2001 Chmouel Boudjnah <[email protected]> 2.96-0.36mdk
- Break build on PPC ;).
- Red Hat patches, Jakub Jelinek (rel74) 5 new patches :
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.2-ac4 #2 SMP Mon Feb 26 00:21:23 CET 2001 i686
On 02.26 David wrote:
> I hope you will find this information usefull.
>
> I am not in the linux-kernel list so, if posible, I would like to be
> personally CC'ed the answers/comments sent to the list in response to
> this posting.
>
> I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc
> 2.91.66) and gcc 2.95.2 versions.
>
gcc2.95.2 is sane in irix6.2, irix6.5 and solaris7sparc.
The optimizer is not in the common front-end ?
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.2-ac4 #2 SMP Mon Feb 26 00:21:23 CET 2001 i686
On Mon, Feb 26, 2001 at 11:30:13PM +0100, J . A . Magallon wrote:
> On 02.26 David wrote:
> > I think I heve found a bug in gcc. I have tried both egcs 1.1.2 (gcc
> > 2.91.66) and gcc 2.95.2 versions.
>
> gcc2.95.2 is sane in irix6.2, irix6.5 and solaris7sparc.
>
> The optimizer is not in the common front-end ?
Yes and no. There is some common code in the optimiser, but each target
has its own optimisation tricks for which the code is not shared with
other targets.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
On Mon, Feb 26, 2001 at 01:02:45PM -0500, you [Richard B. Johnson] claimed:
>
> Script started on Mon Feb 26 12:54:20 2001
> # gcc -o xxx bug.c
> # ./xxx
> Correct output: 5 2
> GCC output: 5 2
> # gcc --version
> egcs-2.91.66
> # gcc -O2 -o xxx bug.c
> # ./xxx
> Correct output: 5 2
> GCC output: 10 5
> # exit
> exit
Funny:
vherva@babbage:/tmp>/usr/bin/gcc c.c -o c; ./c ; /usr/bin/gcc --version
Correct output: 5 2
GCC output: 5 2
2.96
vherva@babbage:/tmp>/usr/bin/gcc -O2 c.c -o c; ./c ; /usr/bin/gcc --version
Correct output: 5 2
GCC output: 10 5
2.96
vherva@babbage:/tmp>/usr/bin/gcc -O6 c.c -o c; ./c ; /usr/bin/gcc --version
Correct output: 5 2
GCC output: 10 5
2.96
vherva@babbage:/tmp>rpm -q gcc
gcc-2.96-74
vherva@babbage:/tmp>kgcc c.c -o c; ./c ; kgcc --version
Correct output: 5 2
GCC output: 5 2
egcs-2.91.66
vherva@babbage:/tmp>kgcc c.c -O2 -o c; ./c ; kgcc --version
Correct output: 5 2
GCC output: 10 5
egcs-2.91.66
vherva@babbage:/tmp>kgcc c.c -O6 -o c; ./c ; kgcc --version
Correct output: 5 2
GCC output: 10 5
egcs-2.91.66
vherva@babbage:/tmp>rpm -q kgcc
kgcc-1.1.2-40
vherva@babbage:/tmp>/usr/local/bin/gcc c.c -o c; ./c ;/usr/local/bin/gcc --version
Correct output: 5 2
GCC output: 5 2
pgcc-2.95.1
vherva@babbage:/tmp>/usr/local/bin/gcc c.c -O2 -o c; ./c ;/usr/local/bin/gcc --version
Correct output: 5 2
GCC output: 5 2
pgcc-2.95.1
vherva@babbage:/tmp>/usr/local/bin/gcc c.c -O6 -o c; ./c ;/usr/local/bin/gcc --version
Correct output: 5 2
GCC output: 5 2
pgcc-2.95.1
I guess pgcc is not that buggy EVERY time. (Sorry for the off topic post, I
couldn't resist.)
-- v --
[email protected]