Dec 192017
 
Bugs in MSC5.0 compiler.
File MSC5BUGS.ZIP from The Programmer’s Corner in
Category C Source Code
Bugs in MSC5.0 compiler.
File Name File Size Zip Size Zip Type
MSC5BUGS.TXT 5120 1995 deflated

Download File MSC5BUGS.ZIP Here

Contents of the MSC5BUGS.TXT file


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


 December 19, 2017  Add comments

Leave a Reply