Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!europa.clark.net!news.mathworks.com!news1.best.com!news.idiom.com!nntp2.ba.best.com!nntp1.ba.best.com!not-for-mail
From: dillon@flea.best.net (Matt Dillon)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: FreeBSD 221 math problem, help
Date: 3 Jun 1997 11:09:06 -0700
Organization: Best Internet Communications, Inc. - 415 964 BEST
Lines: 53
Message-ID: <5n1mk2$bll$1@flea.best.net>
References: <01bc6afa$0dd23720$3976c9ce@amuancw110> <5munmg$kl9@uwm.edu>
NNTP-Posting-Host: flea.best.net
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:42232
:In article <5munmg$kl9@uwm.edu>, Jason Bacon <bacon@cs.uwm.edu> wrote:
:>Tim Brown (Tim.Brown@ctg.com) wrote:
:>: I am getting a math error (FPE) in some pretty old code. The code works
:>: basically everywhere but freebsd 221. It even seems to work on older
:>: freebsd systems.
:>
:>: The code is:
:>
:>: -216 + 5 -1316 *40 / (40 * -.00012120)
:>
:>: I have broken it down like so to narrow it down:
:>
:>: double x = -217 +5 -1316 *40;
:>: double y= 40 * -.00012120;
:>: double a = x/y;
:>
:>: I ran this and when I got the FPE while in gdb, y was 0. Why??
:>: It seems that "y" was rounded off to 0. All other OS's I have run this on
:>: (AIX, SunOS, older freeBSD, others) do not have this problem. Is there a
:>: magical gcc command line option I need to use?
:>
:>Are you compiling with optimizations? If so, try shutting them off.
:>
:>-Jason
Be careful in regards to floating point return values. If you do not
have the correct prototype, and do something like this:
in file #1:
fubar();
in file #2:
double
fubar(void)
{
...
return (...);
}
Then you will get a mostly RANDOM fp fault due to the way the pentium
fp unit works... because the fp return value is 'pushed' onto an fp
stack of sorts, and the call to the routine in the first file does not
realize that it has to pop it if there is no prototype for the function.
The actual seg fault will occur during some future FP operation after
the bogus call returns.
This may or may not be your problem, but whenever I get 'impossible' core
dumps relating to FP stuff, this is the first thing I look for.
-Matt