Re: How to force gcc to dump core on FP error

raynor@cs.scarolina.edu (Harold Brian Raynor) writes:
+Is there any compiler switch that will force either GCC or the MIPS C
+compiler (supplied with Ultrix) to coredump when a floating point error
+occurs?


You *may (and I stress *may*) be able to do *some* of what you want.


The DECstation you are working on contains a MIPS processor, which is
supposed to have floating-point formats and facilities which are
conformant with the IEEE 754 floating point standard. Note however that
"conformance" to this standard on the part of *any* processor isn't really
possible, because the IEEE 754 standard really contains a number of rules
which are really requirements about what a higher-level-language
programmer should see. Thus, the only way to "conform" to IEEE 754 is to
have a processor, a compiler, and a run-time library, all working in
concert to give you a high-level-language "environment" (if you will)
which looks IEEEish.


A regards to the primitives necessary to provide fast IEEE 754 conformant
features in your higher-level-language of choice, the MIPS chips certainly
provide those... as do x86 chips, mc680x0 chips, mc881x0 chips, sparc
chips, AMD 290x0 chips, and a number of other off-the-shelf processors.


The problem is that when it comes to compiler and library support for IEEE
FP exceptions and traps (especially when we are talking about C and/or
C++) the various computer system vendors haven't all universally provided
every- thing you might want in an IEEE FP environment just yet. (And
those that *have* provided something, e.g. Sun, HP, USL, haven't
necessarily all done it in a mutually compatable way which would promote
portability, but that's a whole separate can of worms to be addressed in a
separate posting.)


Anyway, what you want to do is to enable all five of the standard IEEE
floating point traps. The way you do this various from OS to OS, and I
myself was never able to figure out how to do it on a DECstation (but I
know how to do this on SunOS and on SVR4, and I almost figured it out for
AIX on an RS/6000).


Note that the IEEE 754 standard says that these traps are all supposed to
be *disabled* by default... and for most C and C++ execution environments
they *will* be disabled (by default) when your program starts up.
(Notable exceptions are C on the old Alliant machines, and maybe also C on
DEC Alphas running OSF 1.2. I had reports that the traps were incorrectly
on by default on Alliants, and I've see divide-by-zero crash a program on
Alpha/OSF 1.2.)


Next you may wish to actually do something creative like actually have
your program *catch* any of these five kinds of IEEE 754 FP errors that
arise. You can generally do that by setting up your own signal handler
for the SIGFPE signal. Note however that your SIGFPE handler will never
get called (no matter what happens) unless you enable the IEEE FP traps
(which requires a separate operation). If you enable the traps and don't
setup your own SIGFPE handler, then any IEEE exception which actually
arises during execution of your program will be translated into an IEEE
trap and that in turn will most likely be translated into a SIGFPE (by
your operating system) which will then be sent to your process. If your
program hasn't told your OS that it is ready, willing, and able to handle
SIGFPE itself, then the OS will assume that it isn't, and will crash your
programm immediately (usually giving you a core dump at the same time...
on UNIX at least).


Now, setting up a signal handler for SIGFPE is simple and portable.
Enabling IEEE traps is a different matter however. The C libraries
supplied by many system vendors simply do not provide the necessary
routines to let you do this. Others may provide the necessary library
support, but may fail to provide the necessary documentation (e.g. man
pages) so that you can figure out how to programatically enable the
various IEEE traps.


DECstations running Ultrix 4.2 were one environment where I was never able
to find adequate documentation to allow me to know how to enable the IEEE
FP traps that I *know* the underlying MIPS CPU provides. There were many
other systems in this same category. (On HP/UX A.08 on HP-PA systems, the
library support didn't exist, but I understand that it will be there in
HP/UX A.09.)


What is *really* needed is (dare I say it?) a *standard* way of enabling
IEEE traps (and a standard way of testing, setting, and clearing the five
IEEE exception flags) that all of the big vendors agree on, but this
hasn't happened yet. (Readers with a burning interest in this should make
their feelings known to the X3J11.1 Numerical C Extensions Group.)


Anyway, if you figure out how to enable the IEEE traps on a DECstation,
please let me know how to do it.


Oh yes! And before I forget, let me emphasize that simply enabling all of
the IEEE exception traps most definitely WILL NOT cause your program to
bomb out whenever an infinity or a quiet NaN crops up. No way! In the
IEEE 754 mindset, +Infinity and -Infinity are just really big numbers. So
why complain about them? In general, I believe that IEEE 754 *requires*
that operations on infinities *not* raise any exceptions. Separately,
when it comes to operating on qNaNs, I know for a fact that IEEE 754
requires that *some* operations on qNaNs proceed as if nothing bad had
happened... even when you have the traps enabled. In particular,
comparing any qNaN with *any* other number (even an identical qNaN) is
just supposed to yield a "not equal" result.


Now, to summarize...


Submitted for your approval... A man wandering aimlessly through stacks
and stacks of nearly incomprehensible and occasionally conflicting
standards documents, user's guides, man pages... hoping against hope to
make sense of it all. But little does he know that he's just crossed over
into that dark grey region that lies between the pit of mans fears and the
heights of his ambitions... between the smallest normalized number and the
smallest non-negative denorm. In short this man has wandered into...


THE IEEE ZONE!


do do, do do, do do, do do...


:-)
--
// Ronald F. Guilmette
// domain address: rfg@segfault.uucp
// uucp address: ...!uunet!netcom.com!segfault!rfg
--

Return to the comp.compilers page.
Search the comp.compilers archives again.