Xref: utzoo comp.unix.ultrix:2251 comp.sys.mips:322
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!gem.mps.ohio-state.edu!mips!fred
From: fred@mips.COM (Fred Chow)
Newsgroups: comp.unix.ultrix,comp.sys.mips
Subject: Re: Compiler Bug in Ultrix RISC/MIPS C
Message-ID: <32508@batman.mips.COM>
Date: 30 Nov 89 23:07:49 GMT
References: <1989Nov30.021253.23933@acd4.UUCP>
Reply-To: fred@mips.COM (Fred Chow)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 64

In article <1989Nov30.021253.23933@acd4.UUCP> mjb@acd4.UUCP ( Mike Bryan          ) writes:
>
>
>The following program reveals a bug in the Ultrix 3.1 RISC (MIPS) C
>compiler.  It will work correctly with a -O0 or -O1 flag, but will
>fail for -O2 or higher.  I've stripped the code down to the barest
>minimum possible; removing any part of the "for" loop will cause it to
>compile correctly.
>
>===== Begin Program =====
>
>char Restore_file[4][100];
>main()
>{
>    int i;
>    char cmd[100];
>
>    strcpy( cmd, "hi" );
>    for( i=0; i==0; )
>    {
>        if( strlen( cmd ) == 0 )
>	    break;
>        if( 1 )
>	    ;
>        strcpy ( Restore_file[i++], cmd );
>    }
>    printf( "#0 = '%s'\n", Restore_file[0] );
>    printf( "#1 = '%s'\n", Restore_file[1] );
>}
>
>
>===== End Program =====
>
>When the code compiles incorrectly, it acts as if the i++ in the
>strcpy() call was really ++i (pre-increment instead of
>post-increment).  We will be informing DEC of this bug tomorrow.  One
>workaround (other than not optimizing) is to change the strcpy to look
>like this:
>
>        strcpy ( Restore_file[i], cmd );
>	i++;
>
>I don't know if this is just a DEC bug, or if it affects the MIPS
>compiler in general.  I also don't know any easy way to describe the
>case which causes it, apart from saying "if it looks like the
>example".  It was the simplest case we were able to come up with.  If
>you're having problems, you might check to see if your code has
>anything in common with the above.

	We've verified this to be a bug in MIPS' compilers.  It potentially
occurs whenever an array subscript expression is passed as a parameter to
a function in a loop, and the index is the loop control variable and index
in the subscript expression is being post-incremented.  The workaround is
to take out the post-increment, as you suggested above, or put the i++ in
the "for" statement:

	for( i=0; i==0; i++)

which is the usual way that people write for loops.

	This bug will be fixed in the next compiler release.

-------------
Fred Chow (fred@mips.com)