What is acceptable for -ffast-math? (Was: associative law in combine)
Gabriel Dos Reis
gdr@codesourcery.com
Wed Aug 1 11:36:00 GMT 2001
Alexandre Oliva <aoliva@redhat.com> writes:
| On Aug 1, 2001, Gabriel Dos_Reis <gdosreis@sophia.inria.fr> wrote:
|
| > | Now, show me a case where a/b/c -> a/(b*c) is significantly less accurate?
|
| > On a 64-bit double processor just take
|
| > b = c = 2 * sqrt(DBL_MAX);
| > a = 0.5 * DBL_MAX
|
| > a/(b*c) is 0.0 whereas a/b/c yields 0.125.
|
| I'm no expert in FP arithmetic, but it appears to me that this chunk
| of code is a materialization of what Linus wrote:
|
| > The one obvious case is (b*c) overflows and turns into Inf, at which
| > point the end result will be +-0 with the optimization.
|
| If there is a difference, will you care to enlighten me?
You're quoting just a tiny part of his rhetorics and that can cause
confusion.
He used the argument above to derive that for a/b/c not to yeild 0.0,
a should have been very very big, which can't happen in practice.
My example is there to show that is untrue. A 64-bit double processor
isn't something uncommon and a, b, and c are both representable.
Now, if that transformation is considered only on a x86 target then
that is en entirely different debate -- but then we the discussion
started, that wasn't the assumption. That restrcition was introduced
at the very end.
This is just an example of where quick extrapolation doesn't work.
-- Gaby
More information about the Gcc
mailing list