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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Richard Henderson <rth@redhat.com> writes:

| On Tue, Aug 27, 2002 at 10:35:59PM +0200, Gabriel Dos Reis wrote:
| > + #if __GCC_FLOAT_FORMAT__ == __IEEE_FORMAT__
| > + #  define __glibcpp_f32_infinity_bytes { 0x7f800000 }
| > + #  define __glibcpp_f32_has_infinity true
| > + #  define __glibcpp_f32_QNaN_bytes { 0x7fc00000 }
| > + #  define __glibcpp_f32_has_QNaN true
| > + #  define __glibcpp_f32_SNaN_bytes { 0x7f800001 }
| > + #  define __glibcpp_f32_has_SNaN true
| > + #  define __glibcpp_f32_denorm_min_bytes { 0x00000001 }
| > + #  define __glibcpp_f32_has_denorm denorm_present
| > + #  define __glibcpp_f32_is_iec559  true
| > + #endif
| 
| This is incomplete.
| 
| First, MIPS swaps the usual meaning of QNaN and SNaN encoding
| interpretations.  Don't ask me why.

Yes, I noted that one.  See my discussion with Matt Austern on that topic.

[...]

| If you know that infinities exist, it's much easier to produce
| them with (1.0f / 0.0f) than futz about with bitwise definitions.

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.

| We ought to implement the C99 nan/nanf/nanl functions as builtins,
| and allow them to be constant-folded in initializers (at least 
| when used with the explicit __builtin_ prefix).

That certainly is a project on my TODO list, scheduled for 3.x (x >= 4).

| Thus, IMO we should have
| 
| 	const float __glibcpp_float_infinity = 1.0f / 0.0f;

As noted above, this isn't practical as it makes the assumption that
division by zero is disabled.

| 	const float __glibcpp_float_QNaN = __builtin_nanf("");
| 
| 	// Well, still need to handle MIPS queerness here, but can be
| 	// done just fine with libstdc++/config/cpu headers.

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.

[...]

| Of course, you don't want to pollute the namespace by including
| <float.h> to get at FLT_MIN etc, but this is handled by having the
| preprocessor emit all the bits for float.h as __FLT_MIN__ etc.  This
| is particularly useful since now we can avoid the 9 variants of
| float.h in gcc's config directory.  And, incidentally, the 9 
| variants don't actually handle all the cases properly, so that
| would fix this outstanding bug as well.
| 
| The only part I can see right off that isn't handed like this is
| the is_iec559 predicate.  I'd guess that that should be handled
| with a type-specific macro (i.e. __FLT_IS_IEC559__=1) rather than
| by some __GCC_FLOAT_FORMAT__.  That should handle the odd case of
| the r5900.

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

-- Gaby