Possible integer overflow in LIRGenerator::generate_address on SPARC and other platforms
Doerr, Martin
martin.doerr at sap.com
Thu Sep 15 15:13:04 UTC 2016
Hi Vladimir,
thanks for taking a look. I'll provide a webrev and send a RFR.
Best regards,
Martin
-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com]
Sent: Mittwoch, 14. September 2016 20:11
To: Doerr, Martin <martin.doerr at sap.com>
Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: Possible integer overflow in LIRGenerator::generate_address on SPARC and other platforms
CC to group since I am not familiar with C1.
On SPARC generate_address() is called only from
LIR_Address* generate_address(LIR_Opr base, int disp, BasicType type) {
return generate_address(base, LIR_OprFact::illegalOpr, 0, disp, type);
}
So it is not a issue. But I agree with you in general.
On x86 LIRGenerator::emit_array_address() may have this problem.
The only explanation I see that we did not hit it is Interpreter may be more careful about checking it and throw exception.
It could be C1 check this values somewhere else.
Thanks,
Vladimir
On 9/6/16 9:21 AM, Doerr, Martin wrote:
> Hi Vladimir,
>
> I was wondering about the following code in LIRGenerator::generate_address in c1_LIRGenerator_sparc.cpp (and some other platforms):
>
> if (index->is_constant()) {
>
> disp += index->as_constant_ptr()->as_jint() << shift;
>
> It's fine to compute the constant in general, but disp is an int!
>
> Seems like the only user of this function which uses an index is Unsafe put/get where nobody has noticed it yet.
>
> Do you think we have to fix this in 9?
>
> I can open a bug if you like.
>
> Best regards,
>
> Martin
>
More information about the hotspot-compiler-dev
mailing list