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*: Gabriel Dos Reis <gdr at codesourcery dot com>*Subject*: Re: What is acceptable for -ffast-math? (Was: associative law in combine)*From*: Alexandre Oliva <aoliva at redhat dot com>*Date*: 01 Aug 2001 16:07:08 -0300*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>, <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*: GCC Team, Red Hat*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>

On Aug 1, 2001, Gabriel Dos Reis <gdr@codesourcery.com> wrote: > 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 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 transformations. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me

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

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

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

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