RFR (S): 8181872: C1: possible overflow when strength reducing integer multiply by constant
vladimir.x.ivanov at oracle.com
Thu Jun 15 16:47:04 UTC 2017
> Why c1_LIRGenerator.cpp does not have c < max_jint condition?
That's because it uses c as is: is_power_of_2(c). So, it's enough to
filter out negative values. c < max_jint is added into
strength_reduce_multiply() which does is_power_of_2(c + 1).
> Is c == 0 case handled in other place for C1?
is_power_of_2(0) == false, so nothing changes for c == 0 case in
LIRGenerator::arithmetic_op(). Also, I don't think c == 0 is observed
there, because Canonicalizer::do_ArithmeticOp() does "x*0 => 0"
> On 6/15/17 2:53 AM, Vladimir Ivanov wrote:
>> LIRGenerator tries to strength reduce integer multiply and replace it
>> with a shift when the constant has 2^n - 1, 2^n, or 2^n + 1 shape.
>> The problem is that there's only c > 0 check, but since signed integer
>> overflow is undefined in C/C++, is_power_of_2(c+1) can become true for
>> c == max_jint.
>> The fix is to always check the constant to be in bounds (0 < c <
>> max_jint) before detecting 2^n - 1, 2^n, 2^n + 1 shapes.
>> The problem is C++ compiler-specific: it was only observed on MacOS
>> with clang 8.1.0 and I wasn't able to reproduce it with 8.0.0 (or
>> earlier). I don't see official jdk9 build platforms to be affected,
>> but it seems safer to fix it in 9.
>> Testing: regression test, JPRT, RBT (hs-tier0-comp).
>> Best regards,
>> Vladimir Ivanov
More information about the hotspot-compiler-dev