24

I'm reviewing a C++ MFC project. At the beginning of some of the files there is this line:

#pragma optimize("", off)

I get that this turns optimization off for all following functions. But what would the motivation typically be for doing so?

Stokke
  • 1,871
  • 2
  • 13
  • 18
  • 4
    Maybe the programmer liked a reliable stack trace when the program bombs. Maybe he tried to work around a code optimizer bug. Maybe he didn't know what he was doing and applied cargo cult. – Hans Passant Mar 13 '15 at 13:34
  • 1
    Another reason would be to obfuscate the resulted binary. To make reverse engineering harder (of course if the source code is open this is pointless). – freakish Jan 08 '18 at 09:55
  • @freakish it seems that `Themida` is relaying on this when trying to obfuscate a return statement within a `VM` see [screenshot](https://i.stack.imgur.com/Hn4of.png) from the documentation – itsho May 21 '19 at 10:23

5 Answers5

42

I have used this exclusively to get better debug information in a particular set of code with the rest of the application is compiled with the optimization on. This is very useful when running with a full debug build is impossible due to the performance requirement of your application.

Ray
  • 721
  • 5
  • 8
25

I've seen production code which is correct but so complicated that it confuses the optimiser into producing incorrect output. This could be the reason to turn optimisations off.

However, I'd consider it much more likely that the code is simply buggy, having Undefined Behaviour. The optimiser exposes that and leads to incorrect runtime behaviour or crashes. Without optimisations, the code happens to "work." And rather than find and remove the underlying problem, someone "fixed" it by disabling optimisations and leaving it at that.

Of course, this is about as fragile and workarounds can get. New hardware, new OS patch, new compiler patch, any of these can break such a "fix."

Even if the pragma is there for the first reason, it should be heavily documented.

Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
15

Another alternative reason for these to be in a code base... Its an accident.

This is a very handy tool for turning off the optimizer on a specific file whilst debugging - as Ray mentioned above.

If changelists are not reviewed carefully before committing, it is very easy for these lines to make their way into codebases, simply because they were 'accidentally' still there when other changes were committed.

JoshG
  • 775
  • 1
  • 7
  • 19
7

I know this is an old topic, but I would add that there is another reason to use this directive - though not relevant for most application developers.

When writing device drivers or other low-level code, the optimizer sometimes produces output that does not interact with the hardware correctly.

For example code that needs to read a memory-mapped register (but not use the value read) to clear an interrupt might be optimized out by the compiler, producing assembly code that does not work.

This might also illustrate why (as Angew notes) use of this directive should be clearly documented.

Dwight
  • 173
  • 2
  • 9
  • 2
    A similar case is when you want to perform an exact set of operations for cryptographic purposes. A side channel attack can measure the time/power consumption that various branches take to execute, optimizations may not be identical on two similar looking code paths thus leaking information https://en.wikipedia.org/wiki/Timing_attack – Lockyer Jul 11 '18 at 12:31
  • Or to prevent busy wait loops from being optimized out (You want the side effect of time to be retained). Also check out this page for general gotchas when attempting to clear a block of memory: https://wiki.sei.cmu.edu/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations – Gregory Kuhn Feb 11 '21 at 15:20
3

It allows you to debug in release mode.

Chris Baker
  • 31
  • 1