8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I

[Vladimir Kozlov]

On x86 in 64-bit mode any 32-bit arithmetic will clear upper 32 bits. 
That is why it is not problem on x86.

On SPARC we need explicitly clear upper bits. We have special 
macroassembler instruction signx(Register d ), please use it instead of 
sra(). And it can happen in 32 bit mode since SPARC's registers are 
64-bit, so don't put it under #ifdef LP64.

You are correct about code in enc_String_Compare but for consistency I 
would suggest to do sign extension there too before next instruction 
(since chr1_reg is used later):

__ subcc(limit_reg, 1 * sizeof(jchar), chr1_reg);

One additional instruction outside a loop will not kill performance.

Thanks,
Vladimir

On 10/30/13 11:36 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8027445/webrev.00/
>
> On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn’t able to reproduce it on x86 but it’s unclear to me whether something similar could happen or not.
>
> Roland.
>