Re: inlining + optimization = nuisance bugs

Bill Leonard a écrit dans le message 98-06-116...
>"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.


beware of the "Assume no aliases" Optimization which is, on all
compiler, very dangerous yet very usefull...


on msc the option vas called /Oa ...
often it is trigered by the "optimize as much as possible"
on unix I've experiences that using this option
on a whole program, and not just on a few function
certainly break all!


>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.)


to be softer, I'll say that the the code can be incompatible with the
compiler option (eg: assume no aliases!)


I agree with you anyway...


>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.


I advice using a product like Purify (I'm not a stock owner, just a
happy user)... detecting "uninitialize memory read" is on of it's
best point ...


>
> * 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.


this is my point !


> * 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.


though shalt not do this, He said !
--

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