RFR: 8299546: C2: MulLNode::mul_ring() wrongly returns bottom type due to casting errors with large numbers [v3]

[Christian Hagedorn]

On Mon, 13 Mar 2023 14:33:15 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> C++14 5.8/3 In the description of "E1 >> E2" it says "If E1 has a signed type
>> and a negative value, the resulting value is implementation-defined."
>> 
>> However, C++20 7.6.7/3 further defines integral arithmetic, as part of
>> requiring two's-complement behavior.
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r3.html
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1236r1.html
>> The corresponding C++20 text is "Right-shift on signed integral types is an
>> arithmetic right shift, which performs sign-extension."
>> 
>> As discussed in the two's complement proposal, all known modern C++ compilers
>> already behave that way.  And it is unlikely any would go off and do something
>> different now, with C++20 tightening things up.
>> 
>> So I think relying on sign extension by right shift is fine.
>
> That comment quoted earlier from globalDefinitions.hpp could be expanded to include the above analysis.

Thanks a lot Kim for your input and the detailed comments! I've included it as a comment at the `java_shift_right()` method and updated the code to directly use `java_shift_right()` instead of `shift_right_arithmetic()`.

-------------

PR: https://git.openjdk.org/jdk/pull/11907