A few questions/ocmments about floating-point.

[uunet!netcom.com!segfault!rfg]

I've been writing a few compiler test files (for C and C++ compilers)
which attempt to check for proper "conformance" to the letter and the
spirit of the IEEE floating point standard.  (I say "conformance" in
quotes because it isn't always immediately obvious what it means to
say that an implementation either does or does not conform to the IEEE
FP standards.)

Anyway, some of the results I've been getting (from various C compilers
on sparc/SunOS-4.1 and on i486/SVR4) do look rather wrong to me, but
before I leap to any unwarranted conclusions (and before I start telling
implementors to "fix" their "broken" implementations) I thought that I'd
better try to find out what "The Rules" really are with regard to support
for the IEEE 754 and 854 standards in ANSI C.

Now I already knew that the ANSI C standard itself doesn't contain any
particular rules for the special case of an "IEEE conformant" implementa-
tion of ANSI C, so (quite naturally) I looked at the NCEG's "Floating
Point C Extensions" document (which I knew contained some specific rules
for IEEE conformant ANSI C implementations).

Unfortunately, the kinds of questions I need to have answered are not
about "extensions" per se, but only about the "binding" of the IEEE 754
standard to the ANSI C standard.

Naturally, since the NCEG's "Floating Point C Extensions" document is
focused on describing new extenstions to the ANSI C standard (rather
than on specifying a "binding" of IEEE 754 to ANSI C) many/most of my
questions are not addressed at all by that document.  That's not to say
that there is no relationship between the "Floating Point C Extensions"
document and a (hypothetical?) IEEE-754/ANSI-C "binding".  In fact, the
following statement (from section 1.6 of the "Floating Point C Extensions"
document) makes it appear that this "extensions" document depends upon
the existance of some separate IEEE-754/ANSI-C "binding" document:

	"In order to comply as an implementation supporting IEEE standard
	floating-point, and implementation must conform to one, or both,
	of the IEEE standards 754 and 854 - which one is implementation-
	defined."

This statement, while being entirely reasonable, leaves open the question
of what it means for an implementation of ANSI C to "comform" to either
IEEE 754 or IEEE 854.  (The "extensions" document does provide some hints
as to what this means, but it is far from a complete specification of
"the binding".)

Anyway, I'd like to know if the NCEG membership is already generally aware
of the apparent need for a separate IEEE-754/ANSI-C "binding" document.
I'd also like to know if there have been any efforts started (either
inside or outside of the NCEG) to develop such a binding.  If such an
effort is already underway (somewhere) I'd greatly appreciate it if
someone would tell me how I could get in touch with the people who are
working on it.

==========================================================================
P.S.  Just to be a little more concrete about the kinds of things I'd like
to see specified in an IEEE-754/ANSI-C "binding" document, I'll give a
few trivial examples.  These are things that I have already written
compiler test cases for, and which various C compilers for various "IEEE
conformant" target systems seem to do in different ways.

Example #1:

		double d = 1.0e9999999;

Some C compilers for "IEEE conformant" targets will reject the above
declaration, saying that the floting-point literal is "too big" (or some-
thing like that).  Other compilers will accept this declaration and
initialize the variable with a value of +Infinity.  Which compilers are
doing it "right"?

Example #2:

		double d1 = -0.0;
		double d2 = 0.0;

		int main ()
		{
			if (d1 != -d2) printf ("Yikes!\n");
			return 0;
		}

Virtually every compiler I've tested so far will compile this into an
executable which prints `Yikes!'.  It seems that all implementations I've
tested have no trouble computing -0.0 at run time, but they all seem to
treat the `-0.0' compile-time constant initializer (of `d1') as if it
were really `+0.0'.  Can these implementations really be considered to
be strictly "IEEE conformant"?

Example #3:

Given a type `double' varible `d', the results of evaluating:

		(d >= 0.0) ? d : -d

may differ from the results of evaluating:

		fabs (d)

In particular, the former expression is almost certain to raise the IEEE
invalid operation exception if the value of `d' is a signaling NaN, whereas
the response of the library `fabs' routine to an sNaN argument is not
specified anywhere, and (in general) the `fabs' routines in existing C
support libraries DO NOT seem to raise the invalid operation exception
for sNaN arguments.  Note that the difference between these two cases can
become problematic if an agressive optimizer converts the latter expression
into the former (as may be appropriate on many architectures).  Such
difficulties could of course be eliminated if an IEEE-754/ANSI-C binding
specified that the response of the library `fabs' routine to an sNaN
argument must be to raise the invalid operation exception.  In that case,
there would be no notable semantic distinction between these two expressions,
and thus the optimization would always be permissible.


// Ronald F. Guilmette
//    domain address:	rfgasegfault.uucp
//    uucp address:	...!uunet!netcom.com!segfault!rfg