greg@suntan.viewlogic.com (Gregory Larkin) (06/06/91)
Hi there, I am using Peter Housel's floating point package installed in V1.5 with Earl Chew's stdio. It's all working well, but... I recently acquired the latest version of the "Enquire" program. It measures how accurate your compiler is by doing several tests, including floating point accuracy tests. While the program is running, it gets to a certain point and the message: "Floating pt. overflow" is displayed. The program is using the signal() call to trap overflows (I think, I don't a lot about signals), yet the overflow is not trapped. I think that the program assumes that if SIGFPE is defined that it will be able to continue correctly in the event of an overflow. Yet it does not. Does the FP package just exit upon overflow instead of sending a SIGFPE? Could someone enlighten me on this chain of events upon receiving a floating point overflow? (Also, setjmp/longjmp are used with the signal() call to trap the overflow) Thanks, -- Greg Larkin (ASIC Engineer)|"This is a fragile ball we are living on; Viewlogic Systems, Inc. |it's a miracle and we are destroying it.." 293 Boston Post Road West |Peter Garrett, Midnight Oil Marlboro, MA 01752 (greg@Viewlogic.COM)
evans@syd.dit.CSIRO.AU (Bruce.Evans) (06/06/91)
In article <1991Jun5.205138.2909@viewlogic.com> greg@suntan.viewlogic.com (Gregory Larkin) writes: >I am using Peter Housel's floating point package installed in >... >I recently acquired the latest version of the "Enquire" program. >... >"Floating pt. overflow" is displayed. The program is using >the signal() call to trap overflows (I think, I don't a lot about >... >Does the FP package just exit upon overflow instead of sending a >SIGFPE? Could someone enlighten me on this chain of events upon Yes, it just exits, and this is not useful. I fixed it by replacing the library .fat and .trpilin by .define .trpilin .define .fat .fat: .trpilin: sub ax,ax | zero div ax | divide by 0 to generate SIGFPE j .trpilin | repeat This made enquire work well enough to debug the FP package further 8-). It had a couple of minor rounding bugs. However, this is not quite right using ACK (I actually used a modified version with gcc) because the ACK library uses .fat and .trp for other purposes. So, rename these functions .gensigfpe everywhere they are called in the FP package. There may be further things to change if the ACK compiler generates them for other FP errors. -- Bruce Evans evans@syd.dit.csiro.au