RFR (S) 8176580: [ppc, s390] CRC32C: wrong checksum result in some cases

Schmidt, Lutz lutz.schmidt at sap.com
Tue Mar 14 08:24:25 UTC 2017

Thank you, Zoltan!
I expect reviews from the experts in my close vicinity in the near future.

Dr. Lutz Schmidt | SAP JVM | PI  SAP CP Core (SAP JVM) | T: +49 (6227) 7-42834

On 14.03.17, 09:19, "Zoltán Majó" <zoltan.majo at oracle.com> wrote:

    Hi Lutz,
    I can sponsor the change once it's reviewed.
    Best regards,
    On 03/14/2017 09:16 AM, Schmidt, Lutz wrote:
    > Dear all,
    > may I kindly request reviews for my small bugfix? And somebody 
    > volunteering as a sponsor would be welcome as well.
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8176580 
    > <https://bugs.openjdk.java.net/browse/JDK-8176580>
    > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8176580/ 
    > <http://cr.openjdk.java.net/%7Elucy/webrevs/8176580/>
    > Almost two weeks ago, I had contributed CRC32C intrinsic 
    > implementations for ppc and s390. The arguments passed to the 
    > intrinsics differ slightly from those passed to the CRC32 intrinsics. 
    > Instead of passing the byte array length directly, it has to be 
    > calculated from the offset and the end index values.
    > This difference was not accounted for in 
    > templateInterpreterGenerator_{ppc|s390}.cpp as well as in 
    > c1_LIRGenerator_{ppc|s390}.cpp. The fix just adds the missing 
    > subtraction, and adjusts some comments. For the bug to become visible, 
    > it is necessary to calculate a CRC32C checksum from a byte array being 
    > accessed with a non-zero offset. The call to the intrinsic has to 
    > originate from the interpreter or from a c1-compiled method.
    > This change is “platform only”. No changes to shared code.
    > Thank you!
    > Lutz

More information about the hotspot-compiler-dev mailing list