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

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

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

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

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