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

[Kim Barrett]

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

>> @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.

That comment quoted earlier from globalDefinitions.hpp could be expanded to include the above analysis.

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

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