These routines were produced by someone who is not a great authority on
floating point, and may not be entirely correct.  Where possible I tested
the special cases for routines.

The directory testieee contains test programs for IEEE-format machines.
I took a stab at making them work on the vax, but gave up as dealing with
exceptions (e.g. underflow, overflow, reserved operand) was just too tedious.

Note: it is possible to build a library with MACHINE=ieee but a couple
of warnings:

	Be careful when compiling floor.c.  These routines rely on
	certain variables being only double precision.  If these
	variables are placed in 68881 registers, they will be extended
	precision and the routines will produce incorrect results.
	Unless your compiler does its own register allocation, this
	is not likely to be a problem as none of the variables in
	question are declared "register".  If you are using GCC
	you can specify -ffloat-store to avoid this problem.

	The C version of drem() in ieee/support.c appears to compute
	the incorrect results for drem(+-1, +-2).  It yields 1 when
	it should be -1 and -1 when it should be 1.  "should be" is
	based on what the VAX version yields and by cranking through
	the formula.

If you do build using MACHINE=ieee and run the tests in testieee you
will note that some routines return errors:

	floor/ceil/rint report that they got 0 when expecting -0.
	Don't really know which is correct, is floor(-0) == 0 or -0?
	For C it shouldn't really matter since 0 is the same as -0
	in comparisons.

	scalb(-1, -2100) returns 0 instead of -0.  2 ** -2100 is
	effectively 0 but -anything * 0 == -0 according to the 68881.
	Similarly for scalb(-pi, 2100).  It returns INF instead
	of -INF.  2 ** 2100 is effectively INF but -anything * INF
	is -INF.  What is correct?

	drem(+-1, +-2) fails as mentioned above.  This is a real error.

----
Mike Hibler
U of Utah CS Dept.
mike@cs.utah.edu