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

[Roger Sayle <roger at eyesopen dot com>]

> | Anyway, I was thinking about how to define your booleans.  Seems like
> | the following would work:
> |
> |     bool has_infinity = __builtin_huge_val() / 2 == __builtin_huge_val();
> |     bool has_qnan = __builtin_nan("") != __builtin_nan("");
> |     bool has_snan = has_qnan;
>
> The above seems to imply that if the system supports a QNaN then, it
> also supports SNaN.  Is that the case for all the plateform GCC supports?
> What if -fno-signaling-nan is specified?

Perhaps

#ifdef __SUPPORT_SNAN__
bool has_snan = has_qnan;
#else
bool has_snan = false;
#endif

My proposed solution is to use 0.0 as a rogue value to indicate that
the current mode doesn't have a qnan, snan or infinity.

bool has_qnan = !(__builtin_qnan("") == 0.0);
bool has_snan = !(__builtin_snan("") == 0.0);
bool has_infinity = __builtin_infinity() != 0.0;

Alternatively, we could compare the bits of __builtin_qnan and
__builtin_snan as machine words (i.e. not a floating point comparison)
to determine if they are represented the same way.

Otherwise I agree that we might also need __builtin_has_snan{,f,l} to
determine whether we support signaling NaNs.

Roger
--