This is the mail archive of the
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 <gdosreis at sophia dot inria dot fr>
- Date: Wed, 1 Aug 2001 22:20:28 +0200 (MEST)
- Cc: Gabriel Dos Reis <gdr at codesourcery dot com>, Gabriel Dos_Reis <Gabriel dot Dos_Reis 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>, <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>
- References: <20010801122417.A2509@cj44686-b.reston1.va.home.com><Pine.LNX.email@example.com><firstname.lastname@example.org><email@example.com><firstname.lastname@example.org><email@example.com>
| > | > 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:
More accurately he 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. 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. And remember that on x86 register
arithmetic - regardless of precision setting - the exponent is 15 bits. So
in order to get the overflow, AND to get a original value that wasn't zero
(ie to get an error), 'a' would have had to be on the order of
which won't even _fit_ in a double anyway (the -64 is to take even
denormals into account, but others have said that flush-to-zero would have
been acceptable anyway by default). Did I mis-do my calculations.
Emphasis is not mine. Please note, what he showed: That the
situation (i.e. a/b/c) couldn't have been well-formed in the first
place. For x86, that may be true. But that is a specific case.
| > 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.
I don't consider 0.5 * DBL_MAX to be at the "very limits of the number
| > 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.
Yes, he was talking about x86. But again, when we started discussing
the transformation, there were no limitation to targets. Again, I
exhibit the example to show that there are out there bunch of
processors where the stance "it won't matter " isn't true. Now
if the transformation were to be restricted to x86, then that is a