@@ -26,10 +26,12 @@
+#if defined(WIN32) && (defined(_MSC_VER) && (_MSC_VER < 1600))
// Windows AMD64 Compiler Hangs compiling this file
// unless optimization is off
#pragma optimize ("", off)
The same error was seen in sharedRuntimeTrig.cpp, also due to
the pragma disabling optimisation. In that case rather than
a hang it was bad code generated.
In this case, the wrapping of the pragma in "_M_AMD64" appears to
have made it specific to running on AMD64 hardware. I find that
this is there back in JDk 1.5.0 code, so this probably refers
to the VS2005 vintage compiler in the April 2005 SDK.
I'm actually a bit surprised that the compiler hang is dependent
on the actual chip on which its executing. Must be some really
deep problem. Could be its even specific to early chip revisions.
I think it appears safe to skip this on VS2010 as the submitter
reports no hang with VS2010, and that's important since we'll
get a build failure due to the following VS2010 breaking change :
* The revised /GS compiler option guards against buffer overruns more comprehensively than in earlier versions. This version might insert additional security checks in the stack that might decrease performance. Use the new __declspec(safebuffers)keyword to instruct the compiler to not insert security checks for a particular function.
In the unlikely case we subsequently discover it also generates bad code with VS2010,
then I think we can use the same approach as in sharedRuntimeTrig.cpp and
as recommended by Microsoft ( __declspec(safebuffers)).
I had said we likely needed to test that on AMD64 hardware to find out
exactly which functions need it, but of course we can just temporarily
remove the _M_AMD64 for that discovery process, if we find it to be necessary.
We could do the same if we discover that the hang is on specific build
hardware we are still using, but in that case I think it would be smarter to use
newer build hardware rather than hobble the JVM.