V3 PATCH: numeric_limits<> support, fix PR/3865

[Richard Henderson]

On Sun, Sep 01, 2002 at 12:49:32PM +0200, Gabriel Dos Reis wrote:
> That makes the assumption that IEEE-exception for division by zero is
> disabled.  Something I can't control.  Instead, we should just produce
> the right thing in the compiler, as a builtin.

In C, I'd be relying on the fact that this initialization *cannot*
happen at runtime, and thus must be constant folded by the compiler.

With G++, at present, I believe this would always be done at compile
time as well.  What sort of verbage does ISO C++ have regarding this?

(Testing this with 3.2,

	extern "C" int printf(const char *, ...);

	struct S
	{
	  static const float inf = 1.0f / 0.0f;
	  static const float nan = 0.0f / 0.0f;
	};

	int main()
	{
	  printf("%f\n%f\n", S::inf, S::nan);
	  return 0;
	}

we get two screwy warnings

	z.cc:5: warning: division by zero in `
	   0x00000000000000000080ff3f0000000000000000 / 0.'
	z.cc:6: warning: division by zero in `
	   0x0000000000000000000000000000000000000000 / 0.'

Not sure why we're warning here (C doesn't), but if the warning
is retained, we should fix the printing of the fp constant.
However, the constant folding happens exactly as expected; 
indeed is correctly substituted into the code directly

        movl    $.LC0, (%esp)
        movl    $0, 4(%esp)
        movl    $2146435072, 8(%esp)
        movl    $0, 12(%esp)
        movl    $2146959360, 16(%esp)
	call	printf
)

> If we were to implement QNaNs, SNaNs as builtins, then there is no
> reason we don't do it properly by handling the MIPS cas inside the
> compiler and avoid the libstdc++/config/cpu quagmire.

Eh, sort-of.  While the interpretation of the string is in-the-end
implementation defined, it is defined in terms of strtod.

At least glibc defines "" == NAN (c99 <math.h>) == the canonical QNaN.
I assume all other implementations do the same here.

Getting the SNaN is harder.  The only other sequences that glibc 
defines are strtol-parsable integers, which is dropped into the
mantessa as-is.  For non-MIPS, that means "0" is easy.

I suppose we could define "snan" (case insensitive) to do what we
want.  I'd bet that Uli would be willing to pick this up for glibc's 
strtod implementation.  We'd probably be "inconsistent" with other
libcs, but in an extremely minor way.

> I like your design better.  Can we agree on implementing that for 3.4
> rather than 3.3?

I'm not fond of having these macros become permanent.  Please
document all of them as gcc internal and that they may well be
removed in the next release.

Alternately, what if I were to do the backend work?  I'd be
fixing our current float.h inconsistencies (suitable for stage3).
The addition of __builtin_nan could be considered part of the
fix for the bug you're working on.  At which point it ought to
be only a couple lines change in libstdc++...


r~