This is the mail archive of the 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)

On Aug  1, 2001, Gabriel Dos Reis <> wrote:

> Alexandre Oliva <> writes:
> | On Aug  1, 2001, Gabriel Dos_Reis <> 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

Indeed, I failed to quote the other relevant part.  Linus wrote:

> Now, in order for the original to _not_ have been close to zero,
> we're talking about 'a' being at the very limits of the number
> space.

It appears to me that 0.5 * DBL_MAX is indeed at the very limits of
the number space.  So, I still fail to see the difference.

> 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.

But he was explicitly talking about x86's extended precision when he
made this argument.

> 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.

I see.  Anyway, it's still true that 0.5 * DBL_MAX is ``at the very
limits of the number space'', so all bets about numbers being ``far
from overflowing'' are off, and optimizations that rely on this
assumption are indeed likely to break programs.

As we have seen, not all FP programs work in ranges close to overflow
limits, so these could benefit from such optimizations M-backspace

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

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