patch to bug #86829

[Joseph Myers]

On Tue, 21 Aug 2018, Jeff Law wrote:

> The problem is our VRP implementation doesn't handle any floating point
> types at this time.   If we had range information for FP types, then
> this kind of analysis is precisely what we'd need to do the
> transformation regardless of -ffast-math.

I don't think you can do it regardless of -ffast-math simply because it 
may change the semantics and we've generally assumed that if the 
optimization might produce results different from what you get with 
correctly rounded library functions, it should go under 
-funsafe-math-optimizations.  One might try to figure out a way to split 
that option, to distinguish optimizations that might change correctly 
rounded result but keep errors small from optimizations that might produce 
results that are way off, or spurious exceptions, for some inputs.

-- 
Joseph S. Myers
joseph@codesourcery.com