RFR (S) JDK-8041623: Solaris Studio 12.4 C++ 5.13, CHECK_UNHANDLED_OOPS use of class oop's copy constructor definitions causing error level diagnostic
coleen.phillimore at oracle.com
Tue May 27 21:29:28 UTC 2014
Yes, this looks like a good solution.
On 5/27/14, 1:47 PM, harold seigel wrote:
> Hi Lois,
> Your changes look good.
> On 5/22/2014 1:40 PM, Lois Foltan wrote:
>> Please review the following fix:
>> Bug: Solaris Studio 12.4 C++ 5.13, CHECK_UNHANDLED_OOPS use of class
>> oop's copy constructor definitions causing error level diagnostic
>> Summary of fix:
>> A couple of fixes for Solaris C++ 5.13 compilation issues
>> specifically related to CHECK_UNHANDLED_OOPS support in non-product
>> JVM builds. First, the following diagnostic occurred concerning a
>> volatile oop being returned by value. C++ complained that the return
>> value failed to correctly copy construct into a temporary when
>> returning from target_volatile().
>> "javaClasses.hpp", line 1183: Error: Initializing const volatile oop&
>> requires an lvalue.
>> "javaClasses.hpp", line 1183: Error: Formal argument o of type const
>> volatile oop& in call to oop::oop(const volatile oop&) is being
>> passed volatile oop.
>> The fix required a user conversion from oop to OopDesc* with
>> immediate oop construction to provide the lvalue needed. Solaris C++
>> 5.13 also complained about the lack of an appropriate assignment
>> operator from NULL to volatile oop. Solution was to explicitly
>> construct NULL prior to assignment.
>> Built with the following versions:
>> carrs: g++ 4.4.3
>> crocker: g++ 4.4.4
>> philli: g++ 4.8.1
>> Solaris C++ 5.10 (12u1)
>> Solaris C++ 5.12 (12u3)
>> Solaris C++ 5.13 - beta
>> JPRT build & test,
>> Hotspot jtreg on Solaris,
>> Hotspot jtreg on Linux with -XX:+CheckUnhandledOops,
>> vm.quick.testlist - 2 runs one with -XX:+CheckUnhandledOops and
>> one without
>> Thank you,
More information about the hotspot-runtime-dev