RFR: 8019779 JDK 8 build failed due to hotspot crashed on Solaris 10u10 sparcv9/sparc with SS12u3 compiler

[Vladimir Kozlov]

On 7/25/13 11:20 AM, Lois Foltan wrote:
> Hi Vladimir,
>
> Thank you again for your review.  I do have an update.  The change is
> currently on hold in order to further analyze the performance impact of
> reducing the optimization level for these two files.

Was you able to narrow down the code which is compiled incorrectly? May 
be you can avoid the problem by changing that code slightly without 
performance impact.

Thanks,
Vladimir

>
> Thanks,
> Lois
>
> On 7/24/2013 12:34 PM, Vladimir Kozlov wrote:
>> Thank you, Lois, for clarification.
>>
>> Changes are good.
>>
>> Thanks,
>> Vladimir
>>
>> On 7/24/13 9:20 AM, Lois Foltan wrote:
>>>
>>> On 7/24/2013 11:37 AM, Vladimir Kozlov wrote:
>>>> Lois,
>>>>
>>>> Usually such problems happened only with fastdebug build. You lowed
>>>> optimization level for product and optimized
>>>> builds. Did it also fail with these versions? Sorry, I can't see bug
>>>> report.
>>>>
>>> Hi Vladimir,  thank you for your review.  The bug was originally
>>> reported against a fastdebug build, however, I was also
>>> able to easily reproduce the failure with the product build as well.
>>> Thus the necessity of making this change for
>>> fastdebug, optimized and product.
>>>
>>>> Also you kept lower opt level for jvmtiClassFileReconstituter.o (\>=
>>>> 510). Does it still have problem with SS12u3?
>>>>
>>> That is unknown, so I chose the safer route to continue to include
>>> the optimization reduction for
>>> jvmtiClassFileReconstituter.o for SS12u3. There also seemed to be
>>> some historical precedence within the make files to
>>> use (\>=<compiler version #>)  for past compiler version #'s when
>>> bumping up to a new compiler version. Certainly, if
>>> the C++ compiler optimization bug that plagued
>>> jvmtiClassFileReconstituter.o is fixed, then it can be easily be changed
>>> back to just reduced for 510.  However, I don't know if we can make
>>> that assertion at this point.
>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> On 7/24/13 7:49 AM, Lois Foltan wrote:
>>>>> Please review the following fix:
>>>>>
>>>>>      open webrev at http://cr.openjdk.java.net/~hseigel/bug_8019779
>>>>>
>>>>> Bug: JDK 8 build failed due to hotspot crashed on Solaris 10u10
>>>>> sparcv9/sparc with SS12u3 compiler
>>>>>
>>>>>      bug link at https://jbs.oracle.com/bugs/browse/JDK-8019779
>>>>>
>>>>> Summary of fix:
>>>>>
>>>>>      The JDK 8 build on Solaris using the new SS12u3 (CC V5.12)
>>>>> compiler
>>>>>      failed with a Hotspot crash at the point the build executes rmic.
>>>>>      This crash was tracked down to a C++ compiler optimization issue
>>>>>      when two specific files are compiled with -xO4.  As a work
>>>>> around fix,
>>>>>      knock down the optimization level of these two files
>>>>> specifically for
>>>>>      SS12u3. This bug will be reported/transferred to the C++
>>>>> compiler in BugDB.
>>>>>
>>>>> Test Builds:
>>>>>     Based on jdk8/build forests:
>>>>>      JDK 8 full build with C++ SS12u1 with
>>>>> --with-debug-level=[release and fastdebug] on Solaris sparc
>>>>>      JDK 8 full build with C++ SS12u3 with
>>>>> --with-debug-level=[release and fastdebug] on Solaris sparc
>>>>>
>>>>>     Based on hotspot-rt:
>>>>>      Built Hotspot fastdebug, optimized, product with C++ SS12u1 on
>>>>> Solaris sparcv9 and Solaris Intel
>>>>>      Built Hotspot debug, fastdebug, optimized, product with C++
>>>>> SS12u3 on Solaris sparcv9 and Solaris Intel
>>>>>
>>>>> Tests:
>>>>>     JDK 8 full release built with C++ SS12u3 on Solaris sparc - ran
>>>>> Hotspot's jtreg tests
>>>>>     JDK 8 full fastdebug built with C++ SS12u3 on Solaris sparc -
>>>>> ran JCK full test suite
>>>>>     Hotspot fastdebug built with C++ SS12u3 on Solaris sparcv9 -
>>>>> ran vm.quick.testlist
>>>>>
>>>>>
>>>>> Thank you,
>>>>> Lois
>>>
>