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

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

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

I was under the impression that it was proposed __SUPPORT_SNAN__ be
defined if -fsignaling-nan is specified.  My question is what does
happen when  in addition of -fsignaling-nan being specified the port
actually does not support SNaNs?  What if it is not specified? 
RTH's previous proposal says that has_snan == has_qnan; I would like
to know whether that is true for all the plateforms GCC supports...
If so, I'm fine with it.  If it not, then we want to take the road
you're proposing below.

| #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;

This makes sense to me and happens to be in accordance with C++'s
model.  I don't know if it serves C's as well.


Thanks,

-- Gaby