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

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| 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.

Noet however that C++ doesn't follow the same binding like C.
C99 deliberatly ignores signaling NaNs it its modified version of
IEEE-754. C++ doesn't do that.  For C++,
numeric_limits<float>::signaling_NaN() should return an SNaN if
numeric_limits<float>::has_signaling_NaN is true; that is also the
case if numeric_limits<float>::is_iec559 holds  -- C++ uses LIA-1.

| 
| 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?

If the system can have a positive infinity then we set
numeric_limits<>::has_infinity to false and I don't think we're 
permitted to issue a diagnostic:

18.2.1.5/1
  All members shall be provided for all specializations. However, many
  values are only required to be mean-ingful under certain conditions
  (for example, epsilon() is only meaningful if is_integer is
  false). Any value that is not   meaningful   shall be set to 0 or
  false. 

Also, in C++, INFINITY is in the user namespace and we can't use it in
the library.

-- Gaby