/Od compiler option problem

[babak]

Hi

I am running a project in eVC 4.0 and I have been running into a bug
that only appears in the release build of the project. I eventually
found out that when I had the compiler option /Od set the project would
work properly but when it was not set the bug would appear.
I looked for /Od in the MSDN library but it didn't provide much help.
Can anyone help me with what in my code that could lead to this? I.e
what should I look for in my project to fix this bug?

Is it ok to have this option set in a release build? What are the
consequences of that?

Thanks for all your help.
Best regards.
/Babak

[Carl Daniel [VC++ MVP]]

babak wrote:

Hi

I am running a project in eVC 4.0 and I have been running into a bug
that only appears in the release build of the project. I eventually
found out that when I had the compiler option /Od set the project
would work properly but when it was not set the bug would appear.
I looked for /Od in the MSDN library but it didn't provide much help.
Can anyone help me with what in my code that could lead to this? I.e
what should I look for in my project to fix this bug?

Is it ok to have this option set in a release build? What are the
consequences of that?

/Od disables optimization.

If your code depends on /Od, then there are a couple possibilities:

1. There's a compiler bug in the optimizer (not unheard of).
2. Your code is relying on undefined behavior that happens to be different
when compiled with /Od (far more common).

You need to try to narrow down just exactly how/where your code fails when
compiled with optimizations. If you can reduce it down to a small,
complete, postable program that exhibits different behavior with and without
/Od, then if you post that code here, someone will no doubt be able to
determine if it's a compiler bug or if you're relying on undefined behavior.

These things can be tough to find since there are so many ways to invoke
undefined behavior in C++. A very common cause is reliance on initial
values of uninitialized variables, but there are many others.

-cd

[William DePalo [MVP VC++]]

"babak" <ba*********@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I am running a project in eVC 4.0 and I have been running into a bug
that only appears in the release build of the project. I eventually
found out that when I had the compiler option /Od set the project would
work properly but when it was not set the bug would appear.
I looked for /Od in the MSDN library but it didn't provide much help.
Can anyone help me with what in my code that could lead to this? I.e
what should I look for in my project to fix this bug?
/Od means "disable the optimizing compiler". With optimizations disabled,
the job of the compiler is simply (well, ok not simply <g>) to translate
source code to object code. It is important to disable optimizations while
debugging to keep the compiler from storing variables in registers, moving
non-varying quantities outside of loops, reordering statements etc. If it
did any of that it would be almost impossible to debug.

When optimizations are enabled the compiler may do those things and more. In
general, that's a good thing as it speeds up execution. The downside is that
it may reveal latent bugs or introduce its own.
Is it ok to have this option set in a release build? What are the
consequences of that?

Technically yes. Practically no. That's because you may not be pleased at
the resulting execution speed with optimizations disabled.

I would first try to replace Od by O1 and then O2. If either works I'd
declare success and call it a day. If neither does you may want to try
enabling optimizations on a file-by-file basis. If that works, then you
enable optimizations one at a time until it breaks. At that point you can
declare success again or you can try to find the cause.

To do that add

#pragma optimize("", off)

at the top of a source file

and

#pragma optimize("", on)

Then what you do is successfully shrink the size of the non-optimized region
(moving off lower down the file, moving on higher up) until you find the
stretch of code where optimization fails.

Then post that _short_ stretch here and someone will likely be able to
suggest a work-around.

Regards,
Will

[babak]

William DePalo [MVP VC++] skrev:

"babak" <ba*********@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

I am running a project in eVC 4.0 and I have been running into a bug
that only appears in the release build of the project. I eventually
found out that when I had the compiler option /Od set the project would
work properly but when it was not set the bug would appear.
I looked for /Od in the MSDN library but it didn't provide much help.
Can anyone help me with what in my code that could lead to this? I.e
what should I look for in my project to fix this bug?

/Od means "disable the optimizing compiler". With optimizations disabled,
the job of the compiler is simply (well, ok not simply <g>) to translate
source code to object code. It is important to disable optimizations while
debugging to keep the compiler from storing variables in registers, moving
non-varying quantities outside of loops, reordering statements etc. If it
did any of that it would be almost impossible to debug.

When optimizations are enabled the compiler may do those things and more. In
general, that's a good thing as it speeds up execution. The downside is that
it may reveal latent bugs or introduce its own.

Is it ok to have this option set in a release build? What are the
consequences of that?

Technically yes. Practically no. That's because you may not be pleased at
the resulting execution speed with optimizations disabled.

I would first try to replace Od by O1 and then O2. If either works I'd
declare success and call it a day. If neither does you may want to try
enabling optimizations on a file-by-file basis. If that works, then you
enable optimizations one at a time until it breaks. At that point you can
declare success again or you can try to find the cause.

To do that add

#pragma optimize("", off)

at the top of a source file

and

#pragma optimize("", on)

Then what you do is successfully shrink the size of the non-optimized region
(moving off lower down the file, moving on higher up) until you find the
stretch of code where optimization fails.

Then post that _short_ stretch here and someone will likely be able to
suggest a work-around.

Regards,
Will

William and Carl
Thanks a lot for your help. I will try your suggestions and get back if
the problem still exists.

Regards.
/Babak