Xref: utzoo comp.unix.ultrix:2248 comp.sys.mips:321 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!acd4!mjb From: mjb@acd4.UUCP ( Mike Bryan ) Newsgroups: comp.unix.ultrix,comp.sys.mips Subject: Compiler Bug in Ultrix RISC/MIPS C Message-ID: <1989Nov30.021253.23933@acd4.UUCP> Date: 30 Nov 89 02:12:53 GMT Reply-To: mjb@acd4.UUCP ( Mike Bryan ) Organization: Applied Computing Devices, Inc., Terre Haute, IN Lines: 52 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