This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: V3 PATCH: numeric_limits<> support, fix PR/3865
- From: Richard Henderson <rth at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, Ulrich Drepper <drepper at redhat dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Tue, 3 Sep 2002 02:43:35 -0700
- Subject: Re: V3 PATCH: numeric_limits<> support, fix PR/3865
- References: <Pine.LNX.4.33.0209021411020.24169-100000@www.eyesopen.com>
On Mon, Sep 02, 2002 at 02:30:12PM -0600, Roger Sayle wrote:
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n965.htm
Thanks. Draft or not, it looks good enough to use.
> For my two cents, I support Ulrich that adding __builtin_nan,
> __builtin_qnan, __builtin_snan and __builtin_inf to GCC would be
> a convenient starting print, upon which glibc and libstdc++ could
> portably implement the functionality described in the above draft
> standard.
Actually, looking at all this again, I don't think __builtin_qnan
is appropriate. C99 7.12.11.2/3 is quite explicit that nan/nanf/nanl
returns a quiet nan if available.
Thus I'll just go with __builtin_nan{,s}{,f,l}.
As for __builtin_inf(), on non-ieee targets, should this be more
like HUGE_VAL (return the largest value possible) or INFINITY
(which results in a diagnostic)? Perhaps the later, and do go
ahead and supply a __builtin_huge_val() as well?
r~