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

[Kim Barrett]

On Thu, 23 Feb 2023 10:48:22 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> We need @kbarrett opinion on C++ code for this case.
>> I prefer to use already defined functions if they work to avoid duplication.
>
> @kimbarrett 
> 
> Looks like we've initially pinged the wrong Kim Barrett :-)

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.

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

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