United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6953588 hotspot\src\share\vm\interpreter\bytecodes.cpp doesn't compile with VS2010 on AMD64
JDK-6953588 : hotspot\src\share\vm\interpreter\bytecodes.cpp doesn't compile with VS2010 on AMD64

Details
Type:
Bug
Submit Date:
2010-05-18
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2010-06-01
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs19 (b02)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

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
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
                                     
2010-05-18
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.
                                     
2010-05-18



Hardware and Software, Engineered to Work Together