Optimizer bug (/Og) with the 64-bit 2010 Beta 2 compiler. - by DennisB5

Status : 


Sign in
to vote
ID 512552 Comments
Status Active Workarounds
Type Bug Repros 1
Opened 11/19/2009 10:06:59 PM
Access Restriction Public


The 64-bit 2010 Beta 2 compiler when used with /Og incorrectly generates an excecutable  that results in an "Access Violation" (with my sample program).

My small sample C++ program clearly highlights the issue. That sample is contained as an attachment (foo.cc).

Note, the 32-bit 2010 B2 compiler is fine with /Og (no Access Violations).
Likewise, disabling /Og (with the 64-bit compiler) also results in a successful 
Sign in to post a comment.
Posted by DennisB5 on 5/12/2010 at 6:11 PM
We know of two places in our code base that exhibit the bug, and we know how to jiggle
the code to work around the issue in those two places.

However, it is the unknown instances that concern us, every exceptional path in the code
base would need to be tested and verified (which is too large a task).

Hence, we currently use /O2 minus /Og level optimization instead of straight /O2 (which is
reasonable but not desirable).

A fix in the first SP of VS 2010 is a good outcome for us. Thanks, we do appreciate that you
have looked at this issue (and a fix is coming).

Posted by Microsoft on 5/11/2010 at 5:32 PM
Hi. I'm sorry that your product's performance is being impacted by this bug.

If the occurrences of this bug in your source is not too prevalent, I can suggest a workaround.

If you know exactly where the bug occurs, you can wrap the definition of that function with a pair of #pragma optimize to selectively turn off optimization for that function only. You will be able to turn on optimization at large and gain back most of the performance.

#pragma optimize( "", off )

void foo()
    // bug triggering code
#pragma optimize( "", on )


I gather from your bug report that you already isolated the bug-triggering code pattern in your source. Good luck.

Seunghun Thomas Lee
Posted by DennisB5 on 4/15/2010 at 12:33 AM
Thank you, that is superb news indeed.

We look forward to Service Pack 1 of VS2010 very much. Thanks,

Posted by Microsoft on 4/14/2010 at 7:30 PM
Thank you for reporting the issue. We are actively working on a fix. The fix will be in the VS2010 Service Pack 1.

Thank You.

VC++ Code Generation and Tools Team.
Posted by DennisB5 on 1/7/2010 at 3:15 PM
Hello VC++ team,

When you say,

> We will be fixing it and it will be available in the following release.

do you mean VS2012 (or 13/14 whenever), or, VS2010+first-service-pack?

It sounds like the former (which means we will have to wait for around 2 or 3 years). Hopefully the latter (for us) as that would be much sooner. Clarification would be appreciated.

Thanks for looking at this item.

Note, we did encounter this issue two times in our production code; hence we are forced to not use optimization level 2 (which does effect the performance of our product).

Posted by Microsoft on 1/7/2010 at 12:59 PM
Hello, Thanks for reporting this bug. We have identified this bug but its too late to be included in VS2010. We will be fixing it and it will be available in the following release.

VC++ Team.
Posted by Neil57 on 11/25/2009 at 5:03 PM
The absence or presence of the empty try/catch block at the beginning of func() has a massive affect of the code that gets generated by the compiler to handle the destruction of the auto_ptr. I couldn't really understand exactly what the compiler was generating, but my (uneducated) guess is that that is where the problem is occurring.
Posted by Microsoft on 11/20/2009 at 10:51 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you