JDK-6953588 : hotspot\src\share\vm\interpreter\bytecodes.cpp doesn't compile with VS2010 on AMD64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-05-18
  • Updated: 2012-10-08
  • Resolved: 2010-06-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Description
\hotspot\src\share\vm\interpreter\bytecodes.cpp(158) : error C2220: warning treated as error - no 'object' file generated
d:\mercurial\hotspot_main\src\share\vm\interpreter\bytecodes.cpp(158) : warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function

The reason is that bytecodes.cpp is surrounded by

// Windows AMD64 Compiler Hangs compiling this file
// unless optimization is off
#ifdef _M_AMD64
#pragma optimize ("", off)
#endif

and when run with /O2 this will cause the compiler warning C4748. I don't understand why this only happens with VS2010 and not earlier compilers.

Disabling optimizations for bytecodes.cpp does not seem necessary with VS2010 compilers (I tried removing the code), but apparently is necessary with older compilers. I'm not sure how to fix this.
Comments
EVALUATION 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 : http://msdn.microsoft.com/en-us/library/bb531344.aspx * 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.
18-05-2010
SUGGESTED FIX --- a/src/share/vm/interpreter/bytecodes.cpp +++ b/src/share/vm/interpreter/bytecodes.cpp @@ -26,10 +26,12 @@ #include "incls/_bytecodes.cpp.incl" +#if defined(WIN32) && (defined(_MSC_VER) && (_MSC_VER < 1600)) // Windows AMD64 Compiler Hangs compiling this file // unless optimization is off #ifdef _M_AMD64 #pragma optimize ("", off) +#endif #endif
18-05-2010