Making -ffast-math more fine-grained?

[neroden at twcny dot rr dot com (Nathanael Nerode)]

There seem to be an increasing number of different potential "fast math"
changes. (all for floating point, right?... I hope there aren't any integer
"fast math" features)

1 * Ones which allow excess precision computations (these really should be OK
for most people, though not for testsuites)
2 * Ones which ignore correct behavior for anything with NaN or infinities
(and maybe -0.0 vs. +0.0) as intermediate computations, but behave
properly with real numbers (there's probably a class of users who would
appreciate this)
3 * Ones which slightly reduce accuracy by doing truncations instead of
rounding, etc., but where meaningful bounds on the accuracy can be computed
(I'm sure there's a class of users who would appreciate this)
4 * Ones which only work when the exponents involved are close (and are only
useful in cases which should have been coded in fixed-point arithmetic)
such as (a+b)+c => a+(b+c) mentioned by Robert Dewar recently, which are really
dangerous

I think that 1 && 2 && 3 is approximately the current meaning of -ffast-math
(correct me if I'm wrong -- maybe 1 is allowed without -ffast-math, and
disabled by some other switch?), but I'm pretty sure it would be better to
have them as three separate switches.

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/