Re: inlining + optimization = nuisance bugs

lindahl@cs.virginia.edu (Greg Lindahl)
19 Aug 1998 16:15:04 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: inlining + optimization = nuisance bugs acoetmeur@icdc.caissedesdepots.fr (Alain Coetmeur) (1998-06-24)
Re: inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-08-10)
Re: inlining + optimization = nuisance bugs cfc@world.std.com (Chris F Clark) (1998-08-10)
Re: inlining + optimization = nuisance bugs darcy@usul.CS.Berkeley.EDU (1998-08-13)
Re: inlining + optimization = nuisance bugs darcy@usul.CS.Berkeley.EDU (1998-08-13)
Re: inlining + optimization = nuisance bugs joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-08-17)
Re: inlining + optimization = nuisance bugs lindahl@cs.virginia.edu (1998-08-19)
Re: inlining + optimization = nuisance bugs jfc@mit.edu (1998-08-19)
Re: inlining + optimization = nuisance bugs joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-08-19)
Re: inlining + optimization = nuisance bugs roy@prism.gatech.edu (1998-08-20)
Re: inlining + optimization = nuisance bugs awf@robots.ox.ac.uk (Andrew Fitzgibbon) (1998-08-20)
Re: inlining + optimization = nuisance bugs bear@sonic.net (Ray Dillinger) (1998-08-22)
Re: inlining + optimization = nuisance bugs luddy@concmp.com (Luddy Harrison) (1998-09-18)
[19 later articles]
| List of all articles for this month |

From: lindahl@cs.virginia.edu (Greg Lindahl)
Newsgroups: comp.compilers
Date: 19 Aug 1998 16:15:04 -0400
Organization: a guest of Shadow Island Games
References: 98-08-085
Keywords: optimize, comment

> [I've never understood why people are so eager to have fast wrong
> answers. -John]


It's not a matter of fast, wrong answers. It's a matter of
reproducible results. If the compiler is silently using 80-bit
temporaries some of the time, and I rearrange my code slightly, or the
compiler changes how it rearranges expressions slightly, I'll
needlessly get a different answer.


This same issue is causing vendors to insert switches to disable
generation of multiply/add instructions, or to change their chips so
that multiply/add rounds exactly like a multiply followed by an add
(MIPS R8000 vs. R1000). Yes, they're losing a tiny bit of precision.
But different answers should be an option, not forced on the user.


Given that Java has these fp rules so that answers will be consistent
across platforms, it would be stupid to force inconsistent answers. If
a compiler writer wants to make additional precision consistently
available, I'm all for it. If a compiler writer wants to make it
impossible for me to validate any code to the last bit, I'll have them
shot.


-- greg
[I think we agree here. -John]
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.