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<stdio.h>


#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<stdio.h>


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