Can massive nested loops cause the linker to run endlessly when compiling in Release-Mode?

Question

I\'m compiling a very small Win32 command-line application in VS2010 Release-Mode, with all speed optimizations turned on (not memory optimizations).

This a

Answer 1

I encountered exactly this problem trying to build OSMesa x64 Release mode. My contribution to this discussion is that after letting the linker run overnight, it did complete properly.

Answer 2

Nested loops only affect the linker in terms of Link Time Code Generation. There's tons of options that determine how this works in detail.

For a start I suggest disabling LTCG alltogether to see if there's some other unusual problem.

If it links fine in Release with LTCG disabled you can experiment with inlining limits, intrinsics and optimization level.

Answer 3

Some selected answers:

Debug builds don't inline. Not at all. This makes it possible to put breakpoints in all functions. It wou

It doesn't really matter whether the linker truly runs an infinite loop, or whether it is evaluating 2^20 different combinations of inline/don't inline. The latter still could take 2^20 seconds. (We know the linker is inlining from the "Generating code" message).

Why are you using LTCG anyway? For such a small project, it's entirely feasible to put everything in one .cpp file. Currently, the compiler is just parsing C++, and not generating any code. That also explains why it doesn't have any problem: there's only a single loop in the compiler, over all lines of source code.

Answer 4

Here in my company we discovered something similar.

As far as I know it is no endless loop, just a very long operation.

This means you have to options:

1. turn off the optimizations
2. wait until the linker has finished

You have to decide if you really need these optimizations. Here the program is just a little helper, where it does not matter if the program is running 23.4 seconds or 26.8. The gain of program speed compared to the build speed are making the optimizations nearly useless. At least in our special scenario.

Answer 5

If the linker seems to be the bottle neck and both classes are pretty short, why not put all the code in a single file? Also, there is a multi-processor compilation option in visual studio under C++ general tab in the project settings dialog box. Both of these might help.

Answer 6

Have you done a rebuild? If one of the object files got corrupted, or a .ilk file (though release mode probably isn't using one, I can't be sure about your project settings), then the cleaning pass which rebuild does should cure it.

Closing and re-opening Visual Studio is only helpful in cases when the debugging (or one of the graphical designers) is keeping an open handle to the build product.

Which leads to another suggestion -- check Task Manager and make sure that you don't have a copy of your application still running.