Undefined behaviour in HotSpot

[Andrew Haley]

On 12/01/2015 06:43 PM, John Rose wrote:
> On Dec 1, 2015, at 8:56 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> Some of the code in C2 which checks for overflow (e.g.
>> AddLNode::add_ring) looks very wrong to me.  I am not comfortable that
>> an aggressive C++ optimizing compiler will generate the expected code
>> for this function.
> 
> Good catch.  We may need to replace some normal-looking C++ expressions
> on jint (or even "int") with more formal-looking expressions, when the JIT
> is performing static evaluation of Java expressions.
> 
> A straw man:
> 
> // globalDefinitions.hpp
> #define jint_add(x, y) jint(juint(x) + juint(y))
> #define jint_mul(x, y) jint(jlong(x) * jlong(y))

Yes, I'm trying it now.  I'm not going to use exactly this because the
cast from jlong to jint falls into the same trap: it is undefined in
the same way.

Strictly speaking there is no portable way to do this.  However, all
real compilers of which I'm aware allow the "union trick" to alias
unsigned and signed varieties of the the same integer type.  I'm
looking at that now.

> Thank you very much for poking at this.  Static evaluation of
> expressions by the JIT is a long-term source of bugs, and there must
> be other "clever" uses of overflow in our source base.

There are.  GCC now has built-in arithmetic with overflow checking so
perhaps I should use that.  I can do something with the union trick
for non-GCC and older GCC.

> P.S.  In case anybody is thinking it: IMO, it would *not* be good to
> use C++ operator overloading to make the static evaluation code look
> normal.  The special code should have a special look, even if it is
> uglier than the normal look.

Yes, I was thinking that.  Wilco.  :-)

Andrew.