Re: inlining + optimization = nuisance bugs

Remember a while back I made the claim that the Visual C++ 5.0
optimizer broke my complex number class code and was pretty sure it
wasn't a pointer alias or some such? Well, I was able to single step
and find the offending section -- but I couldn't for the life of me
figure out why something as simple as subtraction and comparison were
failing, so I sent the straightforward offending member function code
to a few people. All replied that the code didn't look broken.


Bill Leonard said:


>This code looks okay to me, but perhaps the problem is either somewhere
>else in the CShuComplex class, or perhaps in the places where you are using
>it. It may indeed be a compiler bug, but one needs to be pretty sure
>before reporting it as such. A good debugger might help you pinpoint
>exactly when the code goes wrong.


Bjarne Stroustrup said:


>Your program should work as written.


Andrew Koenig said:


>The code looks straightforward enough to me. Optimizers aren't supposed to
> break straightforward code :-)


Well, after tweaking each optimization in combination, I finally
located the problem. When I compile with the following optimizations on:


        Generate Intrinsic Functions
        Global Optimizations


then comparing the results of CArdaf("sinh(99)") and ::sinh(99) fails.
When I turn on "Improve floating point consistency" -- the problem
disappears. So, I looked up in the compiler documentation the following
entry:


BEGIN ONLINE HELP ENTRY


The Improve Float Consistency (/Op[–]) option improves the
consistency of floating-point tests for equality and inequality by
disabling optimizations that could change the precision of
floating-point calculations. (To find this option in the development
environment, click Settings on the Project menu. Then click the C/C++
tab, and click Optimizations in the Category box. Under
Optimizations, click Customize.)


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.


With /Op, the compiler loads data from memory prior to each floating-point
operation and, if assignment occurs, writes the results back to memory upon
completion. Loading the data prior to each operation guarantees that the
data does not retain any significance greater than the capacity of its type.


A program compiled with /Op may be slower and larger than one compiled
without /Op.


Note The /Op option disables inline generation of floating-point functions.
The standard run-time library routines are used instead. For more
information, see the /Oi option.


END ONLINE HELP ENTRY


Is there a moral to this? I consider tested code that was tested with
optimizations off to be broken the moment I turn optimizations on, and must
therefore retest it. If my test suite had not included the trig tests, the
suite wouldn't have failed.


To trust or not to trust?


--
Quinn Tyler Jackson


email: qjackson@wave.home.com
url: http://www.qtj.net/~quinn/
ftp: qtj.net
[It's pretty cheezy, but I have to admit that precision problems like this
are a chronic problem in floating point code. -John]
--

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