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 jos...@codesourcery.com
