On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Of course there are cases with every optimization enabled by -ffast-math that can break existing programs. Just that we know of one case beforehand shouldn't prevent us from enabling -mrecip at -ffast-math (provided -mno-recip still works, regardless if provided before or after -ffast-math). [We'll at least get some more testing coverage this way]
Argh! Please do not make -ffast-math even more of a pain to work with than it is already. You have to enable it, on the whole compilation unit, to get anywhere near decent performance; there's no escape: either you do not turn it on and everything slows to a crawl, or you pay for not being able to inline from another unit.
Until now, the contract was: you have to deal with (and contain) NaN and infinities. Fair enough, even if tricky that remained manageable. But if i can't expect a mere division by 0, or sqrt of 0 (quite common with FTZ/DAZ on) to give me respectively an infinite and 0 and instead get a NaN (which i can't filter, you remember?) because of the NR round, that's pure madness. So please, for the love of everything's sacred, leave such stunts out of -ffast-math. PS: and it's not like such reciprocals + NR couldn't be done with intrinsics or easily handle such common case.
