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)