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

*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.4.33.0108010929020.20829-100000@penguin.transmeta.com><15208.15111.761855.922613@perceval.inria.fr><orr8uvzm2c.fsf@feijoada.lsd.ic.unicamp.br><flvgk7hbli.fsf@jambon.cmla.ens-cachan.fr><or66c7zjj7.fsf@feijoada.lsd.ic.unicamp.br>

| > | > 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 2**(16383-64) 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 space". | > 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 different issue. -- Gaby

**Follow-Ups**:

**References**:**Re: What is acceptable for -ffast-math? (Was: associative law in combine)***From:*Tim Hollebeek

**Re: What is acceptable for -ffast-math? (Was: associative law incombine)***From:*Linus Torvalds

**Re: What is acceptable for -ffast-math? (Was: associative law incombine)***From:*Gabriel Dos_Reis

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

**Re: What is acceptable for -ffast-math? (Was: associative law in combine)***From:*Gabriel Dos Reis

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

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |