This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What is acceptable for -ffast-math? (Was: associative law in combine)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]