Path: utzoo!mnetor!uunet!husc6!hao!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!cae780!tektronix!tekgen!tekigm2!marks
From: marks@tekigm2.TEK.COM (Mark D. Salzman)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MicroSoft C Ver 5.0 BUG!!
Message-ID: <2291@tekigm2.TEK.COM>
Date: 22 Dec 87 17:20:43 GMT
References: <2276@tekigm2.TEK.COM> <433@doug.UUCP>
Reply-To: marks@tekigm2.UUCP (Mark D. Salzman)
Distribution: na
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 48

In article <433@doug.UUCP> tim@doug.UUCP (Tim J Ihde) writes:
>In article <2276@tekigm2.TEK.COM>, marks@tekigm2.TEK.COM (Mark D. Salzman) writes:
## A friend of mine just discovered a bug in Microsoft C Ver. 5.0 that
## crashes the "cl" compiler . . .
## 
## double a,b = 3.0;
## main()
## {
##  a = (b * 1.7E-9) + ((b * 1.9E-9) * 1.0E-4);   /* <-- This crashes "cl" */
## }
## 
## The "cl" compiler crashes with the following error message:
## 
## run-time error R6000
## - stack overflow
#
#I'm not sure I see what is happening - you state that the compiler itself
#crashes, but that it reports a run-time error?  A stack overflow complaint
#from your running program would simply mean that you need to use exemod
#and expand the stack space.  On the other hand, if the compiler
#bombs out with a complaint like that, then it not only means a bug in
#the compiler but a bug that MS did not anticipate and wasn't checking
#for!  I don't suppose your friend would have exemod'ed cl and decreased
#its allocated stack space?
#
#	tim

It is pass #2 of the "cl" compiler itself that crashes. You can see this
by compiling the short program given above with the command:

	cl /d bugtest.c   Note: This turns on a debug mode that shows
				the command line given for each pass
				of the compiler.

We got a call back from Microsoft after my first posting and it was found
that turning on loop optimizations (/Ol) also seems to "cure" this bug.
We also tried changing the stack space of each pass of the compiler with
EXEMOD and found it had no effect on the bug.

Since there are so many ways to work around this bug, it will likely be
a low priority for Microsoft to produce a fix. However they are working
on it.

-- 
Mark D. Salzman     Phone (206) 253-5542.  |  The more complex the mind,
Tektronix Inc., P.O. Box 3500, M/S C1-937  |  the greater the need for 
Vancouver, Washington. 98668               |  the simplicity of play.
{world_at_large}!tektronix!tekigm2!marks   |       James T. Kirk