Re: inlining + optimization = nuisance bugs

"Quinn Tyler Jackson" <qjackson@wave.home.com> writes:
> 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.


> 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 wonder if you are jumping to conclusions. Sounds like you are
assuming that it must be the compiler that is broken, rather than your
code. (If you have truly tracked this down to a compiler bug, please
forgive me and ignore this message.)


We have had several instances in the past where customers complained
that our compiler was broken because their code didn't work when they
optimized it but worked fine if they did not optimize. Being dutiful
servants of our customers, we spent many man-hours tracking down these
discrepancies, only to find that it was the customer's code that was
broken. These problems usually resolve into a case of the language
standard saying "behavior is undefined if you do thus-and-such", but
nothing bad happens unless the optimizer is on. In fact, many such
statements in language standards are there precisely for optimizers to
take advantage of.


Other possible causes of such problems (some of these are things I
have actually seen happen in customer code, and in some cases, in my
own code!) are:


    * Using a variable that was not given a value. The code might luck out
        and work because the variable happens to be allocated to a space that
        was previously zeroed, say, but when the optimizer rearranges things
        or helps the variable into a register, the code behaves differently.


    * Passing the same array as two different arguments to the same
        function/subroutine in Fortran. The standard says this is not allowed,
        but users sometimes do it anyway. It usually doesn't matter unless you
        optimize, and even then, it might only matter if the optimizer is able
        to take advantage of the (alleged) knowledge that the two arrays are
        not aliased.


    * In C/C++, modifying a "const" object through a pointer by casting away
        const. The optimizer may have taken advantage of knowing the value of
        this const object and cause your program to behave differently.
--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.ccur.com
--

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