Re: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests

[igor.ignatyev@oracle.com]

Got it. It would be nice to add 8022395 to the @bug tag of the tests, but since these tests are from jdk, it can lead to additional efforts, so it's not really necessary. I'm not sure that we have a corresponding noreg- label for it, but if it exists please add it into the issue.

Thanks.
-- Igor

----- Reply message -----
From: "Christian Thalinger" <christian.thalinger at oracle.com>
To: "Igor Ignatyev" <igor.ignatyev at oracle.com>
Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
Subject: [8] RFR (XXS): 8022395: java.util.zip.ZipException: Not in GZIP format in JT_JDK/test/java/util/zip/GZIP tests
Date: Sat, Jan 18, 2014 01:21

The bug was found with an already existing regression test in the JDK.  I don’t think we have to duplicate that test somewhere else.

On Jan 17, 2014, at 1:04 AM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:

> Hi Chris,
> 
> What about regression test for this? As I understood from your comment[1], you have it, but the webrev and changeset don't contain it.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8022395?focusedCommentId=13447393&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447393
> Igor
> 
> On 01/17/2014 04:25 AM, Christian Thalinger wrote:
>> Thank you, Vladimir and Igor.  I’m going to push this to jdk9 too.
>> 
>> On Jan 16, 2014, at 3:48 PM, Igor Veresov <igor.veresov at oracle.com
>> <mailto:igor.veresov at oracle.com>> wrote:
>> 
>>> Looks fine.
>>> 
>>> igor
>>> 
>>> On Jan 16, 2014, at 1:49 PM, Christian Thalinger
>>> <christian.thalinger at oracle.com
>>> <mailto:christian.thalinger at oracle.com>> wrote:
>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8022395
>>>> http://cr.openjdk.java.net/~twisti/8022395/webrev.00
>>>> 
>>>> 8022395: java.util.zip.ZipException: Not in GZIP format in
>>>> JT_JDK/test/java/util/zip/GZIP tests
>>>> Reviewed-by:
>>>> 
>>>> C1's instrinsic for java.util.zip.CRC32.update(int b) on x86 destroys
>>>> the input value b but the register is not marked to be destroyed.
>>>> This can lead to a wrong value if CRC32.update is inlined.
>>>> 
>>>> The fix is to mark the LIRItem to be destroyed.  This will make C1 to
>>>> insert a spill move.
>>>> 
>>> 
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140118/9c6cb85e/attachment.html