Turbo C++: F. P. Error: Stack Fault.

[Blake McBride]

In <1991Apr23.151734.28924 at unixg.ubc.ca> burton at unixg.ubc.ca (Steve Cumming, net.leftist) writes:



>I am porting some software from UNIX to a 286 machine running DOS 3.4.
>Some of the code is produced by f2c, then hand hacked by yours truly.

>I am compiling with Turbo C++, using -f for software floating point
>emulation, and with -ff- to supress floating point optimisation,
>for reasons that should become evident.

>In addition to the usual trouble, I get floating point exceptions of
>the type mentioned in the Subject line. I can find no explanation of
>this error in the manual. The error occurs at seemingly random
>locations, though probably in the f2c'd code, in which are
>large numbers of explicit promotions and demotions from
>float to double and back. The occurance and apparent location
>of the error is dependent (seemingly) on the number and location
>of debug statements which I have scattered throught the code.
>Many of these print %f mode values.

>The program makes extensive use of the overlay manager, in
>case that is important. It also appears to be too large for
>the Turbo debugger. Sigh.

>Can anyone fill me in on what this error message
>is telling me, and suggest constructs I should be looking for?


>Many thanks.
>--
>#include "../h/disclaimer.h"        /* I am not really Phil Burton, btw. */
>burton at unixg.ubc.ca		    ... and if dinosaurs "became" birds	
>Steve Cumming, a.k.a.			what will we become?   - Anselm Hollow.
>			


	I have found the same problem.  After a great deal of time and trouble
I descovered the problem.  Believe it or not its the *= += -= /= operators!
About 2% of the time those operators generate incorrect code.  If you replace
statements like  x += y  with  x = x + y  and so on, everything will work.
I have some code with a *= which would cause the same error you described.
When I changed it everything worked ok.  Many other statements in that same
file have *= without causing any problems.  If I leave the *= problem in and
generate assembler code it can't be assembled because of an illeagal
instruction!

	I have been in contact with Borland about the problem.  I have
also sent them sample code.  They are able to reproduce the bug with the
code I sent them.  They told me that since I was able to get around the
problem (by replacing the *= += etc. operators in my 20MB of C source) that
it wasn't significant!!!  They said that they will try and have the bug
fixed in the next maintenance release (at least 6 months away).  They also
told me that I couldn't be a beta tester (to get the fixed code sooner)
because I admited to them (when asked) that I had been a beta tester
for other companies!!!

	I have MicroSoft C 6.0a and I purchased the Ergo DOS extender to
replace Borland C++ 2.0 and VROOM.......


-- 
Blake McBride				Home (615) 790-8521
3020 Liberty Hills Drive		Work (615) 790-1088
Franklin, TN  37064			root at blakex.raidernet.com
U.S.A.					...!uunet!mjbtn!raider!blakex!root