What is the scope of optimizations in a compiler?

When compiler optimizes code, what is the scope of the optimizations? Can an optimization

a) span more than a set of nested braces?

b) span more than a function?

c) span more than a file?

We are chasing an obscure bug that seems to derive from optimization. Code crashes in release mode but not debug mode. And of course we are aware this could be heap corruption or other memory problem bur have been chasing this for a while now. One avenue we are considering is to selectively compile our files in debug mode until the problem goes away. In other words:

a) Start with all file compiled in release mode

b) Compile 1/2 the files in debug mode

if crash still seen, take half the release compiled files and compile in debug mode

if crash not seen, talk half the files compiled in debug mode and compile in release mode

repeat until we narrow in on suspect files

this is a binary search to narr开发者_StackOverflowow in on problem files

We are aware that if this is a memory issue, simple doing this mixed compilation may make the bug go away, but we are curous if we can narrow in on the problem files.

The outstanding question though is what is the scope of optimizations - can they span more than one file?

An optimization can do literally anything as long as it doesn't change the semantics of the behaviour defined by the language. That means the answers to your first questions (a), (b), and (c) are all yes. In practice, most compilers aren't that ambitious, but there are certainly some examples. Clang and LLVM have flags for link time optimization that allow optimizations to span pretty much the entire program. MSVC has a similar /GL flag that allows whole-program optimization.

Often the causes of these sorts of failures are uninitialized variables. Static analysis tools can be very helpful in finding problems like the one you're describing. I'm not sure your binary searching via optimizations is going to help you track down too much, though it is possible. Your bug could be the result of pretty complicated interactions between modules.

Good luck!

You can approximately identify problem files from call traces of crash in release mode. Then try to rebuild them without optimizations - this is much simpler than binary search.

To know about compiler optimization, one easy resourse could be wikipedia. It nicely explains in brief some important and wide-implemented optimizations by almost all modern compilers.

Maybe, you would like to read the wiki entry first, especially these sections:

• Types of optimizations
• Specific techniques

I think you are asking the wrong question.

It is unlikely (unless you are doing something special) that the optimizer is your problem.

The problem is most likely an uninitialized variable in your code.
When you compile in debug mode most compilers will initialize all memory to a specific pattern, so that during debugging you can see what has happened to the memory (was it allocated/ was it de-allcoated/ was it from the stack/ Was the stack popped back from etc).

Thus in debug mode any uninitialized memory has the a specific pattern that can be recognized by the debugger. The exact pattern will depend on the compiler. But this can make sloppy code work as the uninitialized pointers are NULL, integer counters start at 0 etc.

When you compile for release mode all the extra initialization is turned off. If you did not explicitly initialize the memory it is in a random state. This is what debug/release versions of an application behave differently.

The easy way to check for this is to check your compiler warnings.
Make sure that all variables are initialized before use (it will be in the warnings).