[comp.unix.ultrix] Compiler Bug in Ultrix RISC/MIPS C

mjb@acd4.UUCP ( Mike Bryan ) (11/30/89)

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.
-- 
Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802
Phone: 812/232-6051  FAX: 812/231-5280  Home: 812/232-0815
UUCP: uunet!acd4!mjb  INTERNET: mjb%acd4@uunet.uu.net
"Agony is born of desire; that's what you get for wanting." --- Moev

fred@mips.COM (Fred Chow) (12/01/89)

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)