RFR(S): 8056950: Compiled code (64-bit) on SPARC should sign extend INT parameters passed on registers to runtime or native methods.

[Lindenmaier, Goetz]

Hi,

I had a look at "8056950: Compiled code (64-bit) on SPARC should sign extend INT parameters passed on registers to runtime or native methods." https://bugs.openjdk.java.net/browse/JDK-8056950  We fixed the same issue for ppc.

There are three parts to this:

1.) generate_native_wrapper(). The native wrapper should do the sign extensions for the smaller ints.
This was missing when 8056950 was opened, but fixed by "8148353: [linux-sparc] Crash in libawt.so on Linux SPARC"
in the meantime. http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1f4f4866aee0

2.)  Stubs called directly like updateBytesCRC32C. If the C2 compiler passes an int to these it is not
correctly sign extended. updateBytesCRC32C and most others are implemented in assembly, so one can
 assure proper 32-bit instructions are used.
A problem are stubs implemented in C, as montgomery_square() on ppc. On ppc we solved this with
 a trick in the platform implementations, see sharedRuntime_ppc.cpp:3445, "len = len & 0x7fffFFFF;"
Montgomery is not implemented on sparc, though. I did not find any other similar on sparc.

3.) The optoStubs generated by the C2 compiler. The C2 compiler will insert proper casts here if
  CCallingConventionRequiresIntsAsLongs is set. So this needs to be set on sparc.

I propose the folowing simple, straight forward webrev:
http://cr.openjdk.java.net/~goetz/wr16/8056950-SparcIntToLong/webrev.01/

For 2.)/montgtomery, one could think about implementing widening the type of 'len' to
long in C2, but it's currently not an issue.

Best regards,
  Goetz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160704/b9da7d6d/attachment.html>