This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: V3 PATCH: numeric_limits<> support, fix PR/3865
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Richard Henderson <rth at redhat dot com>,Gabriel Dos Reis <gdr at integrable-solutions dot net>,gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Mon, 2 Sep 2002 12:22:48 -0700
- Subject: Re: V3 PATCH: numeric_limits<> support, fix PR/3865
- References: <m38z2sxcnk.fsf@soliton.integrable-solutions.net> <20020831010710.GC1501@redhat.com> <m3n0r27znn.fsf@soliton.integrable-solutions.net> <20020901220904.GB8139@redhat.com>
On Sun, Sep 01, 2002 at 03:09:04PM -0700, Richard Henderson wrote:
> > 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.
It might make sense to permit entry of infinity and NaN as hexadecimal
floating constants. I could go two ways on that:
- Remove the code which prevents you from writing a NaN or infinite
bit pattern as a bare hexadecimal floating constant:
0x0.0p+1023 # infinity
0x8.0p+1023 # quiet NaN (non-MIPS)
0x4.0p+1023 # signaling NaN (non-MIPS)
- Define new syntax (staying within the grammar of a pp-number):
0x0.0p+INF # infinity
0x0.0p+NAN # qNaN
0x0.0p+QNAN # same
0x0.0p+SNAN # sNaN
In this scheme, the mantissa would be ignored in the first case and
splatted into the mantissa field in the latter three, except that you
couldn't touch the high bit. I don't think any confusion arises with
type suffixes. It has the advantage of allowing the same input to
work on MIPS and non-.
Actually I think you can get infinity right now by writing a hex
float constant that overflows, but only with warnings.
zw