This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 01 Aug 2001 20:35:53 +0200
- Cc: Gabriel Dos_Reis <gdosreis at sophia dot inria dot fr>, Linus Torvalds <torvalds at transmeta dot com>, Tim Hollebeek <tim at hollebeek dot com>, Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>, Gabriel Dos Reis <gdr at codesourcery dot com>, <dewar at gnat dot com>, <amylaar at redhat dot com>, <gcc at gcc dot gnu dot org>, <moshier at moshier dot ne dot mediaone dot net>, <tprince at computer dot org>
- Organization: CodeSourcery, LLC
- References: <20010801122417.A2509@cj44686-b.reston1.va.home.com> <Pine.LNX.4.33.0108010929020.20829-100000@penguin.transmeta.com> <15208.15111.761855.922613@perceval.inria.fr> <orr8uvzm2c.fsf@feijoada.lsd.ic.unicamp.br>
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