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.
Regards,
Lutz
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,
Zoltan
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