Optimizer bug or threading bug?

[stratum]

It seems the safest option then is to disable the optimization. It would probably not impact performance in any notable way. Whether or not this is a bug with MSVC would require a much deeper look into the current PE.

It's pretty sure it wouldn't make any difference for this application. The problem is that it's not reasonable to do so for the open source dependencies that are in use because each one has its own build system so disabling the optimizer on everything is not feasible. You may say it would be paranoid to do so, and perhaps it is.

There is something else interesting about the microsoft compiler. If you use many open source packages you have to commit the binaries to subversion or git. Then the compiler sometimes complains that one of the packages was built with global optimizations enabled and using /LTCG flag on the linker would improve linker performance, and continues to build by implicitly assuming that /LTCG was given (it starts again as if /LTCG was given) with the following warning:

"MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance"

But if you specify /LTCG explicitly, then it complains that the library was built with an older version of the compiler, but it's not actually very old, only minor versions differ. If they consider versions of visual studio to be incompatible even when minor versions differ then they should reconsider real world implications of their assumptions. The fact that implicit switching to /LTCG does not involve the same version compatibility check is a bit strange also.

I have recompiled all those packages and removed the global optimization flags (/GL) on them. There is no longer suspicious warnings, and the issue remains.

[mystran]

"MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance"

Well, it certainly HAS to enable LTCG if it sees a module compiled for LTCG, because the whole point of LTCG is to delay optimisation and code-generation to the link-time, so the compiler proper just parses the source code (and I guess performs template expansions and such) and dumps the result in some intermediate form to the "object" files which then are not really traditional object files at all, since they haven't really gone through the compile backend yet... and if you're dumping internal intermediate formats, it's not hard to see why it might sometimes have to change even between point releases.

[mystran]

As "expected" this one gives correct behavior:

Code: Select all

					if (last_percent < 0.0)
						last_percent = 0.01;
					else if (last_percent > 100.0)
						last_percent = 100.0;

Ok, so you have a compiler bug then.

Who knows, the only thing I was able do with shorter code fragments extracted from the same code was to cause cl.exe to crash and couldn't reproduce the problem itself.

Well, to me that sounds like a confirmation that you're probably hitting some bug in the compile. While compiler bugs are certainly rare in comparison to simple "user errors" it's not like they never happen. Some old versions (in the 90s; probably 2.96.x or something; it was one of the "classic" versions anyway that was in use longer than your average compiler version) of gcc for example would occasionally (no idea what triggered it exactly; it was fairly rare, but not exactly "one time" either) fail to compile nested loops similar to the following correctly:

Code: Select all

for(int x = 0; x < w; ++x)
for(int y = 0; y < h; ++y)
{
  ... some stuff ...
}

It would basically compile the outer "for" as a simple "if" condition, but only when compiled as C++ (ie. I had some code back then that would compile correctly just by telling the compiler to compile as C instead) and the best part was that it would work perfectly fine if you put another {} around the inner for loop (ie. for(..) { for(...) { ... } } would always work).

[stratum]

Well, to me that sounds like a confirmation that you're probably hitting some bug in the compile. While compiler bugs are certainly rare in comparison to simple "user errors" it's not like they never happen.

Unfortunately the compiler bug that I had found was not related to the issue. It was a problem in the error recovery module which aborted itself because it wasn't able to deal with a missing type declaration. (The usual warning window that is displayed after such an abort() call followed it instead of a graceful exit)