Re: inlining + optimization = nuisance bugs

"Alain Coetmeur" <>
24 Jun 1998 00:10:48 -0400

          From comp.compilers

Related articles
why not inline all functions? (Mark Sanvitale) (1998-06-09)
Re: why not inline all functions? (Thomas Niemann) (1998-06-11)
inlining + optimization = nuisance bugs (Quinn Tyler Jackson) (1998-06-18)
Re: inlining + optimization = nuisance bugs (1998-06-19)
Re: inlining + optimization = nuisance bugs (Alain Coetmeur) (1998-06-24)
Re: inlining + optimization = nuisance bugs (Quinn Tyler Jackson) (1998-08-10)
Re: inlining + optimization = nuisance bugs (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) (1998-08-17)
Re: inlining + optimization = nuisance bugs (1998-08-19)
[25 later articles]
| List of all articles for this month |

From: "Alain Coetmeur" <>
Newsgroups: comp.compilers
Date: 24 Jun 1998 00:10:48 -0400
Organization: Compilers Central
References: 98-06-032 98-06-065 98-06-089 98-06-116
Keywords: optimize, practice

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

Post a followup to this message

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