Re: inlining + optimization = nuisance bugs

darcy@usul.CS.Berkeley.EDU (Joseph D. Darcy)
13 Aug 1998 22:04:34 -0400

          From comp.compilers

Related articles
inlining + optimization = nuisance bugs qjackson@wave.home.com (Quinn Tyler Jackson) (1998-06-18)
Re: inlining + optimization = nuisance bugs bill@amber.ssd.csd.harris.com (1998-06-19)
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)
[23 later articles]
| List of all articles for this month |
From: darcy@usul.CS.Berkeley.EDU (Joseph D. Darcy)
Newsgroups: comp.compilers
Date: 13 Aug 1998 22:04:34 -0400
Organization: University of California, Berkeley
References: 98-08-056
Keywords: C++, optimize, comment

"Quinn Tyler Jackson" <qjackson@wave.home.com> writes:


[mysterious bug in C++ complex class resolved after using the "improve
floating point consistency" compile flag]


Compiler documentation...


>By default, the compiler uses the coprocessor's 80-bit registers to
>hold the intermediate results of floating-point calculations. This
>increases program speed and decreases program size. However, because
>the calculation involves floating-point data types that are
>represented in memory by less than 80 bits, carrying the extra bits of
>precision (80 bits minus the number of bits in a smaller
>floating-point type) through a lengthy calculation can produce
>inconsistent results.


On the x86 it is possible to write out 80 bit double extended values
to memory, although writing out 64 bit double values is faster.


>To trust or not to trust?


>Quinn Tyler Jackson


>[It's pretty cheezy, but I have to admit that precision problems like this
>are a chronic problem in floating point code. -John]


Extended precision floating point gets a bad name precisely because
languages and compilers don't give a name to that format. Some
compilers use extended precision without the knowledge or consent of
the programmer, leading to confusing results. If the compiler in
question mapped the x86's double extended format to the long double
type, the programmer could indicate when and where extended precision
should be used. Even if not used by general programmers, having
extended precision makes implementing the math library easier.


These kinds of unwanted extra-precision bugs are not new; the 680x0
based Sun III compilers could introduce the same sort of surprises
(these surprises also appeared even earlier on the GE635). In an
effort to speed up Java's floating point the x86, Sun is proposing to
allow these precision anomalies into Java
(http://java.sun.com/feedback/fp.html). If you want to let Sun know
that isn't such a great idea, they have an email address for comments,
javasoft-spec-comments@eng.sun.com.


-Joe Darcy
darcy@cs.berkeley.edu
[I've never understood why people are so eager to have fast wrong
answers. -John]
--


Post a followup to this message

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