Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!mjbtn!raider!blakex!root From: root@blakex.RAIDERNET.COM (Blake McBride) Newsgroups: comp.lang.c Subject: Re: Turbo C++: F. P. Error: Stack Fault. Message-ID: <138@blakex.RAIDERNET.COM> Date: 26 Apr 91 01:36:05 GMT References: <1991Apr23.151734.28924@unixg.ubc.ca> Distribution: na Organization: Blake McBride, Franklin, TN Lines: 66 In <1991Apr23.151734.28924@unixg.ubc.ca> burton@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@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@blakex.raidernet.com U.S.A. ...!uunet!mjbtn!raider!blakex!root