Last night I checked in ieee 754 floating point completion code.  Most
users and most programs will not be affected by this.

There are presumably a few programs in pkgsrc that have SIGFPE problems
on alpha. Somewhere, there might even be one that actually uses some
754 features. If you are interested in some such thing, please keep reading,
otherwise, you can safely ignore this announcement.

All alpha operating systems, not just NetBSD, by default generate fast,
finite-operand-only floating point code that works in the traditional
RISC/Vax/Cray/IBM way, generating SIGFPE on division by zero, overflow,
and other problem cases usually created by program errors.

The new code implements the IEEE 754 (PeeCee-like) behavior for those
programs compiled with -mieee, and it in theory will not change _anything_
except the behavior of those few programs so compiled.

In practice, -mieee mode is used not for any mathematical purpose, but
simply to cause large programs developed and run mainly on the pc to continue
running, like they do on the pc, even when they do dumb things like eat
random data as floating point inputs or divide by zero. Since no one wants
to debug, say, a giant database pkg to find why it cores with SIGFPE when
not run on a pc, this is potentially a useful feature, especially since
the use of FP in this type of program is often for runtime statistics, jpeg
decoding, or other things for which the exact output is unimportant anyway.

In other words, it changes the floating point model from:

	garbage-in, SIGFPE-out
to
	garbage-in, garbage-out

or, to be charitable:

	garbage-in, infinities- and NaNs-out

It's probably worth trying any application that previously died with SIGFPE,
but only after recompiling it. I'll see what I can do about updates to
cc(1) and writing a man page for all this stuff.  Since all the alpha cpu's
differ in how dependent they are on the kernel FP code, it might be useful
to get some per-cpu results on src/regress/lib/libc/ieeefp/testfloat/.  Be
sure to update your libc first, and expect that sqrt won't set the inexact
flag.  (Our libm right now is not built with -mieee.) Right now
float64_to_int32_round_to_zero sets two flags, but I'm about to fix
that.

Here are some usage guidelines:

CASE				SUGGESTIONS
---------------------------	--------------------------------------------

your program runs fine		declare victory

SIGFPE				cc -mieee

it is not numerically		cc -mieee OR simply:
intensive, and uses FP only		#include <signal.h>
for stats, graphics output,		signal(SIGFPE, SIG_IGN);
other non-critical cases, or
the FP errors don't seem to
be important

the program is a 754		cc -mieee-with-inexact -mfp-rounding-mode=d 
conformance test

it calls fpsetround(3)		cc -mfp-rounding-mode=d
with some argument other
than FP_RN (it wants to change
the rounding mode dynamically)

You want it to work with	#include <signal.h>
NetBSD/alpha 1.5, 1.5.1,	signal(SIGFPE, SIG_IGN);
or earlier
............................................................................

    // ross