inlining + optimization = nuisance bugs

>Inlining a procedure exposes the procedure's body to the surrounding
>code, allowing for classical optimizations to take place. One of the
>benchmarks in our test suite terminated with a divide-by-zero exception
>after inlining. A matrix-multiplication function was inlined. The
>optimizer could then determine that there was no use of the calculation,
>so the code was eliminated. Thus, it took zero time to do the
>calculation. The divide-by-zero error occurred when dividing elapsed
>time into a constant. At any rate, we had qualms about reporting
>benchmark figures for such a result.


My CShuComplex class declares most of the member functions inline, but
when the MSVC++ compiler has optimizations turned on, the code breaks
at runtime because it optimizes something or other into oblivion.
Inline in combination with aggressive optimization has done similar
things to me on several builds, and so, as a general rule, I turn off
all aggressive optimizations when I inline, since I have found that
this kind of compiler-introduced bug is difficult to associate with a
specific member function. I prefer to have my release build function
identically to my debug builds, minus the performance hit that a
typical debug build introduces.


Cheers,


Quinn
[Bugs in a Microsoft product? Hard to believe. -John]






--

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