[Cfp-interest] FP_EXCEPTIONAL_TEST

[David Hough CFP]

Note that any exception macro of the sort we've been talking about can't
take an early exit if it doesn't know which exceptions are interesting.
This will be important to performance.

> > It's equivalent to saving the flag set before, restoring it 
> > after, and returning as the macro value the flags that arose 
> > in compound-statement.
> > Except for underflow, which is an interesting question: 
> > should it report whether the underflow exception arose, or 
> > whether the underflow flag would
> > have been raised.     For underflow, those are not the same.

I think this specific FP_EXCEPTIONAL_TEST I mentioned in my last email is almost
equivalent to the usual flag manipulations, so it might as well be
exactly equivalent to the usual flag manipulations, and test the
underflow flag rather than the underflow exception.

The previous FP_EXCEPTIONAL macros I proposed are based on the underflow
exception rather than the underflow flag.

> In brief reply to this and Jim's question ... my concern is that in practice the
> set of 'exceptions' is likely to be larger that the set described in IEEE 754.

Portable code using FP_EXCEPTIONAL_TEST
might want to branch on zero or nonzero based on
standard flags, and local nonstandard flags would be a problem.    
But since the inexact flag will almost always be
on, I suppose it's more likely that the caller will have to 
mask out the flags of 
interest anyway, so it doesn't matter if more flag bits are defined than
the five standard ones.