2

I am using Visual Studio 2010. The C1001 error (internal compiler error) only occurs in the release configuration. Debug compiles fine. In this case, what should I be looking at to prevent this from happening in terms of configuration differences?

I know what an internal compiler error is, the question is what is the approach that should be taken if it is only a problem with release. Modifying the code around the line mentioned (in the error message) is not helping so far, the lines just keep changing and I'm wondering also whether that can ever be a red herring? I have tried changing the optimizations already having read some of the answers here to similar questions too.

ajeetdl
  • 1,254
  • 1
  • 13
  • 17
  • 1
    Obviously, you already have tried rebuilding from scratch? (Just checking...) – krlmlr Aug 26 '12 at 14:12
  • Maybe you can submit a bug to Microsoft Connect? – Rango Aug 26 '12 at 14:18
  • Yes I have tried rebuilding from scratch. Rango, I could do that but I was hoping that since the Debug does indeed compile without errors that for Release some modifications to the compiler options might assist with compiling in the mean time. – ajeetdl Aug 26 '12 at 14:22
  • 1
    @SkillM2: normally, the only difference between Debug and Release should be the optimization passes. It could be that some optimization pass is buggy and disabling it would work. Therefore, you should first try enabling the optimizations level a little at a time (start with `O1`, then `O2`), and then try enabling the optimizations themselves one at a time. The documentation should list which optimizations are activated by each level. – Matthieu M. Aug 26 '12 at 14:29
  • I will try that, thank you. I was not expecting such prompt replies! Unfortunately I am away and will not be able to attempt anything again for two days when I get back and have access to the code. I will update this at that time. I apologize for the delay, thanks for everyone's suggestions. – ajeetdl Aug 26 '12 at 14:35
  • @Skill M2 note that you can change compiler flags (like optimization, stack frames etc) for that particular translation unit, while leaving global project options unchanged. Besides, ensure that the code complies with the standard (even though MSVC might be less restrictive) - sometimes making the code "more standard" helps to prevent ICE. – Igor R. Aug 26 '12 at 14:54
  • Disabling the optimizations has not helped. The file and line that is outputed along with message is actually not my code, it is included because I need it. I commented out a few lines in that file but it still complains about the error ocurring on the same line even though everything is commented out, it appears my edits have no effect. – ajeetdl Aug 28 '12 at 15:09
  • @MatthieuM. MSVC uses different default preprocessor variables for debug and release builds, yielding completely different code (STL types are binary incompatible for instance). – Alexandre C. Aug 28 '12 at 19:30

1 Answers1

0

This was resolved although the 'solution' may appear unfulfilling. The file and line that the internal compiler error mentioned was not my code but from a lib I was using that was compiled in a separate solution and project. I did not realize that immediately. Soon after I commented that my change was having no effect above I tried to compile the lib code without optimizations and then attempted to recompile my code. That did not work either. In the end I just moved two lines of code from line x to line x + 20 (within the same block so it didn't matter where it was) and then built the lib again and then rebuilt my work and it worked. There is no doubt that there was some config difference between release and debug and may be if I had kept pressing I could have figured out what optimization or config was at fault but I am rushed now and just needed to have this running.

So in the end, to resolve, had something like this.

{
blah1
blah2
blah3
blah4 //the line the compiler error mentioned
blah5
blah6
blah7
blah8 
}

changed to:

{
blah1
blah2
blah3
blah6
blah7
blah8
blah4
blah5 
}

I guess any random change like this would have worked, this way just happened to work on the first attempt.

There are similar resolutions already on StackOverFlow, what threw me off for a while was the debug/release difference and the fact that the code I had to change was from a different solution and project and I had to rebuild two separate solutions.

ajeetdl
  • 1,254
  • 1
  • 13
  • 17