ethan@esosun.UUCP (Ethan Brown) (03/05/89)
In article <10660@pasteur.Berkeley.EDU> faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) writes:
Path: esosun!seismo!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!dogwood.Berkeley.EDU!faustus
From: faustus@dogwood.Berkeley.EDU (Wayne A. Christopher)
Newsgroups: comp.lang.c
Date: 3 Mar 89 22:58:15 GMT
Sender: news@pasteur.Berkeley.EDU
Lines: 6
It seems that on some Suns, the FPU by default doesn't signal
divide-by-zero errors, but makes the result Inf or NaN. Is there a way
to make it give a floating point error? Does gcc have a flag for
this? How about the MIPS compiler, which has the same behavior?
Wayne
Wayne:
I found similar problems on a Sun 4 when testing a FORTRAN program I'm
currently working on. After the program terminated (normally, by the
way) I got some warnings about IEEE exceptions raised but not cleared.
It seems that only SOME of the IEEE exceptions cause program
termination.
There are some manual sections explaining how to set up your own
IEEE exception handler (c.f. f77_ieee_environment.3f (there is probably
an equivalent entry for C)) that were very helpful. After becoming familiar
with the IEEE exception handling functions you should be able to trap
your divide-by-zero conditions.
Hope this helps,dgh%dgh@Sun.COM (David Hough) (03/06/89)
The default mode of ANSI/IEEE 754 and 854 arithmetic is non-stop:
floating-point exceptions (inexact, underflow, overflow, division by
zero, invalid operand) set flags and produce standard default
results, but computation is not terminated or interrupted.
Programs that are written with IEEE arithmetic in mind generally
find that the default results are appropriate.
All general-purpose implementations provide some kind of alternative
that allows selective trapping on any or all of the exceptions.
On Suns running SunOS 4.0 or later, see ieee_handler(3m).
Since the default allows one to run through all kinds of trouble
in a buggy program without termination, I provided a retrospective
message at the end of Fortran programs compiled under Fortran 1.1
or later. This message to standard error informs you that some
of the IEEE exceptions occurred and the status flags weren't reset.
I described the Sun implementation tersely in a Floating-Point
Programmer's Guide Addendum which was somewhat obscured in the
SunOS 4.0 documentation crate by being included in the
Software Read This First - Programmer's Guides Minibox
part number 800-1789.
David Hough
dhough@sun.com
na.hough@na-net.stanford.edu
{ucbvax,decvax,decwrl,seismo}!sun!dhoughgwyn@smoke.BRL.MIL (Doug Gwyn ) (03/06/89)
In article <92543@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes: >Programs that are written with IEEE arithmetic in mind generally >find that the default results are appropriate. That is tautological. Programs NOT written with IEEE arithmetic in mind may very well produce undetected nonsense (instead of silly but detectable behavior, like a core dump). The whole IEEE arithmetic approach has both proponents and opponents, reasonable people all, and this is not the place to argue its merits. I'm glad to see that at least SOME indication that exceptions were triggered is available under the latest Sun Fortran. P.S. Thanks to D. Hough for his help in improving the ANSI C floating-point specs.
fieland@hobbiton.prime.com (03/07/89)
You might be interested in a few facts about the Mips fortran
compiler. Sometimes constant folding in the front end of the
Mips fortran compiler results in Inf or NaN being assign to the
variable at compile time, as in
r = 0.0/0.0
or
r = 1.0 / 0.0
Unfortunately, even compiling with optimization level zero (no optimization)
doesn't turn this off. However,
r1 = 0
r = 0 / r1
does seem to be calculated at execution time.khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering) (03/07/89)
In article <331@kvasir.esosun.UUCP> ethan@esosun.UUCP (Ethan Brown) writes: > >In article <10660@pasteur.Berkeley.EDU> faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) writes: > > Path: esosun!seismo!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!dogwood.Berkeley.EDU!faustus > From: faustus@dogwood.Berkeley.EDU (Wayne A. Christopher) > Newsgroups: comp.lang.c > Date: 3 Mar 89 22:58:15 GMT > Sender: news@pasteur.Berkeley.EDU > Lines: 6 > > It seems that on some Suns, the FPU by default doesn't signal > divide-by-zero errors, but makes the result Inf or NaN. Is there a way > to make it give a floating point error? Does gcc have a flag for > this? How about the MIPS compiler, which has the same behavior? > > Wayne > >Wayne: > I found similar problems on a Sun 4 when testing a FORTRAN program I'm >currently working on. After the program terminated (normally, by the... I suspect that dgh will post something (or has, the net acts as a time warp of sorts) the fact of the matter is that this is what SHOULD happen. IEEE arithmetic sez so. To get the behavior you desire (if you have SunOS 4.+), add the following line of code to your main program. i = ieee_handler("set","common",SIGFPE_ABORT) Now your sun will act like a pre-ieee machine, and dump core when anything nasty happens. Of course, you can get much better results by being clever and letting nature take its course, and check in key places.... Cheers. khb Keith H. Bierman It's Not My Fault ---- I Voted for Bill & Opus
chris@mimsy.UUCP (Chris Torek) (03/07/89)
In article <92698@sun.uucp> khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering) writes: >To get the behavior you desire (if you have SunOS 4.+), add the following >line of code to your main program. > > i = ieee_handler("set","common",SIGFPE_ABORT) > >Now your sun will act like a pre-ieee machine, and dump core when >anything nasty happens. I would prefer that this be the default behaviour, and that a call should be required to get standard IEEE operation. This has the advantage of producing a compile-time (or link-time) error when the program is moved to another machine which does not support IEEE arithmetic. Defaults should always be the most useful mode, but `most useful' depends on the application and the programmer, and having experienced porting problems, I am biased towards `most useful' => `least likely to surprise'. >Of course, you can get much better results by being clever and letting >nature take its course, and check in key places.... Assuming, of course, that you are willing to restrict yourself to IEEE- capable machines. This is not an unreasonable binding: F.P. arithmetic tends to be quite machine dependent, and IEEE is probably the best available compromise. But whatever you choose, it should be made clear. Simply assuming that IEEE behaviour will occur is dangerous. Commenting that it is required is better, but still leads to surprises (many people never look at the code they use, and most should never *have* to). Thus, for my own protection, I would like to have to call a function, or set a compile-time switch or similar, to get IEEE-compliant arithmetic. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
evil@arcturus.UUCP (Wade Guthrie) (03/09/89)
Thinking of how I get when I have been coding for a particularly long stint in the context of the following: In article <92698@sun.uucp> khb@fatcity.Sun.COM > i = ieee_handler("set","common",SIGFPE_ABORT) I can't help but think of a sound I make when encountering the bug-that- broke-the-camel's-back (specifically, "ieee", pronounced (rather loudly) "eye-eeeeeeeeee"). It is nice to note that someone has an ieee_handler to service appropriately such interjections. Wade Guthrie evil@arcturus.UUCP Rockwell International Anaheim, CA (Rockwell doesn't necessarily believe / stand by what I'm saying; how could they when *I* don't even know what I'm talking about???) [and, yes, I am familiar with the Institute of Electrical and Electronics Engineers (or there abouts)]