Be VERY careful when using the MSC5 compiler. The optimizer is generating a LOT of bad code in places. In some cases you can disable enough of the optimizer to force it to generate good code, but in other cases one must simply rewrite code to trick the compiler into doing the write thing. The problems appear to be with large memory models. All C code was compiler with "Alfu" memory model. In the next two messages I will show two code samples that generated bad code. The samples are simplified extracts that demonstrate a compiler bug.. This demonstrates a bug in the loop optimizer. The cast to a CHAR * is what confused the optimizer... The code is large memory model compiled with "Alfu". The bug is correctable by disabling the loop optimizer. #include #define GETSEGPTR(xseg,xoff) ((char *) (((long) xseg <<16) | xoff)) #define WHATEVER 20 void fortran badcode(buffer,unpointer) char *buffer; unsigned *unpointer; { char *ptr; unsigned segval, get_a_segval(); int i; segval=get_a_segval(); for(i=0; i< WHATEVER ; i++) { do_something( GETSEGPTR(segval,0)); segval+=16; } } It does not matter what the called routines do, The compiler does not generate the code to add 16 (seg size) to the variable SEGVAL.. Below is the asm that the compiler generates.... *** 000024 be 14 00 mov si,20 *** 000027 81 46 fe 40 01 add WORD PTR [bp-2],320 ;segval $L20000: ;|*** { ; Line 20 ;|*** do_something(GETSEGPTR(segval,0)); ; Line 21 *** 00002c ff 76 f6 push WORD PTR [bp-10] *** 00002f ff 76 f4 push WORD PTR [bp-12] *** 000032 9a 00 00 00 00 call FAR PTR _do_something *** 000037 83 c4 04 add sp,4 ;|*** segval+=16; ;|*** } ; Line 23 *** 00003a 4e dec si *** 00003b 75 ef jne $L20000 ;|*** } In this above loop, segval is never changes at all... Nice huh? The code sample below is even more terrifying since the compiler is not generating badly optimized code so much as it is just generating BAD code. Below is a sample of a C routine that the compiler will kill you on. This code was compiled with "Alfu". The only way to correct the compiler was to disable intrinsics, any other optimizer flag made no difference. #include void fortran badcode(buffer,unpointer) char *buffer; unsigned *unpointer; { char *ptr, *getaptr(); ptr=getaptr(); *unpointer = strlen(ptr); } The assignment of strlen() to *numpointer will generate bad code. It does not really matter if numptr is an unsigned int or an int by the way. Below is the asm that the compiler will generate... ;|*** ;|*** *unpointer = strlen(ptr); ; Line 13 *** 000018 c4 5e 06 les bx,DWORD PTR [bp+6] ;unpointer *** 00001b c4 7e fc les di,DWORD PTR [bp-4] ;ptr *** 00001e b9 ff ff mov cx,-1 *** 000021 33 c0 xor ax,ax *** 000023 f2 repnz *** 000024 ae scasb *** 000025 f7 d1 not cx *** 000027 49 dec cx *** 000028 26 89 0f mov WORD PTR es:[bx],cx ;|*** } In the asm above, you will note that it generates an LES twice in a row. The value loaded into ES by the first LES is clobbered by the second LES. The last instruction to load CX into ES:[BX] is invalid since ES does not NECESSARILY point to the correct data segment. If the segment value of the pointer happens to be equal to SS, the code will work, but the compiler should not assume this, especially since the code was generated with "Alfu" - which means among other things, ES!=DS.... No combination of optimizer switches could get the compiler to generate the right code for this. The routine had to be modified to load the strlen() value into an intermediate location, and from there into the final target. Under OS/2 bugs like this make themselves know fairly quickly, A bad segment value is trapped instantly by the kernel. Such Bugs are are much more difficult to locate under MS-DOS. The above bugs in the MSC 5.0 compiler can be reproduced in the OS/2 SDK compiler as well............. The 5.0 compiler is nice, and some of the new features are very handy. When the optimizer works, it generates wonderful code, but when its bad - its VERY bad. It appears as though MSC5.0 was rushed to market before it was completely debugged. daniel doman Be VERY careful when using the MSC5 compiler. The optimizer is generating a LOT of bad code in places. In some cases you can