Re: /Od compiler option problem

Tech-Archive recommends: Fix windows errors by optimizing your registry




William DePalo [MVP VC++] skrev:

> "babak" <babak.ayani@xxxxxxxxx> wrote in message
> news:1129637454.399006.291190@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 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

.



Relevant Pages

  • Re: [64-bit Delphi] A msg from Hairy (van Tassel)
    ... > TeamB members telling the poster he's got it all wrong, ... Update to D7 introduced bugs in the compiler. ... No one yet has been able to point to a bug ... optimizations, but the removal of optimizations is /not/ a bug, despite ...
    (borland.public.delphi.non-technical)
  • Re: /Od compiler option problem
    ... > work properly but when it was not set the bug would appear. ... /Od means "disable the optimizing compiler". ... It is important to disable optimizations while ... declare success again or you can try to find the cause. ...
    (microsoft.public.dotnet.languages.vc)
  • Re: large files: when ubiquitous?
    ... I was merely pointing out that the compiler cannot ... > it should NEVER make optimizations that assume that it has unique ... > Then it's a bug. ... >> to a char pointer type or changing p to be a char ...
    (comp.os.linux.development.system)
  • Re: [64-bit Delphi] A msg from Hairy (van Tassel)
    ... optimizations, ... indicates that it is a bug in the compiler, and that it's not just a ... an update, and suddenly the lines go all over the place, crossing each ... You wouldn't label that as a bug? ...
    (borland.public.delphi.non-technical)
  • Re: WaitForSingleObject() will not deadlock
    ... One is to hijack the semantics of volatile to disable compiler optimizations ... and otherwise let the compiler to agressive optimization. ... Agressive optimizations are the ones that work on the edge of the semantics of the ... Because the compiler can see into lock and unlock, it is able to reduce f ...
    (microsoft.public.vc.mfc)