29 Sep 1998 15:34:38 -0400

Related articles |
---|

[17 earlier articles] |

Re: inlining + optimization = nuisance bugs zalman@netcom.com (1998-09-22) |

Re: inlining + optimization = nuisance bugs chase@world.std.com (David Chase) (1998-09-22) |

Re: inlining + optimization = nuisance bugs christian.bau@isltd.insignia.com (1998-09-22) |

Re: inlining + optimization = nuisance bugs andrewf@slhosiery.com.au (Andrew Fry) (1998-09-24) |

Re: inlining + optimization = nuisance bugs comments@cygnus-software.com (Bruce Dawson) (1998-09-24) |

Re: inlining + optimization = nuisance bugs Martin.Ward@SMLtd.Com (1998-09-26) |

Re: inlining + optimization = nuisance bugs toon@moene.indiv.nluug.nl (Toon Moene) (1998-09-29) |

Re: inlining + optimization = nuisance bugs wclodius@aol.com (1998-09-29) |

Re: inlining + optimization = nuisance bugs ralph@inputplus.demon.co.uk (Ralph Corderoy) (1998-09-29) |

Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-29) |

Re: inlining + optimization = nuisance bugs tim@wagner.princeton.edu (1998-09-29) |

Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29) |

Re: inlining + optimization = nuisance bugs dmr@bell-labs.com (Dennis Ritchie) (1998-09-29) |

[5 later articles] |

From: | Toon Moene <toon@moene.indiv.nluug.nl> |

Newsgroups: | comp.compilers |

Date: | 29 Sep 1998 15:34:38 -0400 |

Organization: | Moene Computational Physics, Maartensdijk, The Netherlands |

References: | 98-09-149 |

Keywords: | arithmetic, design |

*> [Oh, humph. If you think that floating point operations don't have a*

*> correct answer, then you definitely shouldn't be using floating point.*

*> Unfortunately, too many compiler writers seem to share this*

*> misconception. As we've said many times before, approximate is not the*

*> same as unpredictable. -John]*

Hmm, perhaps you're thinking of something else when writing "correct answer",

but I - as one of the people responsible for reviewing bug reports for g77 -

too often come across the following:

FUNCTION FINDX(X)

10 XNEW = < some computation involving X >

IF (XNEW .EQ. X) THEN

FINDX = XNEW

RETURN

ENDIF

X = XNEW

GOTO 10

END

I.e. a relaxation type computation that assumes that < some computation

involving X > has a fixed point.

This almost invariably breaks down on Intel processors, because in the

equality comparison, XNEW normally resides in a register (being recently

computed) and X is retrieved from memory.

Of course, the compiler _could_ remedy this by slowing down the whole

computation such that every floating point intermediate was stored in memory

(just singling out XNEW is too hard), but the real problem (pun intended)

with this code is much more scary:

There is no guarantee that < some computation involving X >, even if the

mathematical expression _has_ a fixed point, won't result in X and XNEW

eternally oscillating between two numbers that differ by a bit.

*I* do not know how to prove that this doesn't happen for arbitrary values of

the seed (the initial value of X) and an arbitrary < some computation

involving X >.

--

Toon Moene (mailto:toon@moene.indiv.nluug.nl)

Saturnushof 14, 3738 XG Maartensdijk, The Netherlands

Phone: +31 346 214290; Fax: +31 346 214286

g77 Support: mailto:fortran@gnu.org; egcs: mailto:egcs-bugs@cygnus.com

[Again, there are correct answers here, but they can wobble back and

forth around the limit if the limit isn't representable, so the

X = XNEW test is just plain wrong. But you probably learned that back in

your numerical analysis class. -John]

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.