Undefined behaviour in hotspot

[Christian Thalinger]

On Apr 25, 2014, at 11:37 AM, Dean Long <dean.long at oracle.com> wrote:

> On 4/24/2014 7:10 PM, Christian Thalinger wrote:
>> On Apr 24, 2014, at 10:33 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> On Apr 21, 2014, at 10:41 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I think the simplest and safest fix would be to make encoding() (and
>>>> all the corresponding functions) static functions which take a
>>>> Register as argument like:
>>>> 
>>>> static int encoding(const RegisterImpl* r) { assert(is_valid(r),
>>>> "invalid register"); return (intptr_t)r; }
>>>> 
>>>> This wouldn't waste any more memory and it would be fully C++
>>>> compliant at the price of a slightly more verbose usage:
>>>> 
>>>> 2577    void Assembler::push(Register src) {
>>>> 2578      int encode = prefix_and_encode(RegisterImpl::encoding(src));
>>>> 2579
>>>> 
>>>> And of course this would work with any compiler.
>>>> 
>>>> What do you think?
>>> I’d rather make Register a real C++ class with an _encoding field.  There are not that many registers used or allocated that it would make a big difference in memory usage.
>> I filed:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8041796
>> 
>> and here is an initial cut of the changes:
>> 
>> http://cr.openjdk.java.net/~twisti/8041796/webrev.00/
>> 
>> Right now it’s x86 only and of course must be done for all the other architectures as well.  By inspecting some Clang generated code it seems the resulting code is the same in most (all?) cases.
> You should be able to define an operator -> for compatibility, allowing more of the existing code to continue working.

It would probably work but I’d rather not.  It would trick people into thinking that Register is still a pointer which it isn’t anymore.  Real problems would arise if someone were to actually new a Register.

> 
> dl
> 
>>>> Regards,
>>>> Volker
>>>> 
>>>> 
>>>> On Mon, Apr 21, 2014 at 8:30 PM, Omair Majid <omajid at redhat.com> wrote:
>>>>> * David Chase <david.r.chase at oracle.com> [2014-04-21 13:53]:
>>>>>> On 2014-04-21, at 12:17 PM, Omair Majid <omajid at redhat.com> wrote:
>>>>>>> I can ping them, but honestly, I wouldn't be surprised at all if the
>>>>>>> only response I get is "no". I don't have any official communication
>>>>>>> channels with them, so my input is not any different from anyone else's.
>>>>>>> 
>>>>>>> Can you elaborate on what flag/pragma you have in mind? Just something
>>>>>>> to play nice with NULL pointers?
>>>>>> Not just null pointers.  Also optimizations that pretend that integer overflow
>>>>>> doesn't happen (i.e., optimizations that change program behavior when it
>>>>>> does) also need to be disabled.
>>>>> My knowledge of C/C++ is fairly limited, so please bear with me. There
>>>>> are a few relevant options already listed in 'man gcc':
>>>>> 
>>>>> -Wstrict-overflow=n
>>>>>          This option is only active when -fstrict-overflow is active.
>>>>>          It warns about cases where the compiler optimizes based on
>>>>>          the assumption that signed overflow does not occur
>>>>> 
>>>>> -fwrapv
>>>>>          This option instructs the compiler to assume that signed
>>>>>          arithmetic overflow of addition, subtraction and
>>>>>          multiplication wraps around using twos-complement
>>>>>          representation.
>>>>> 
>>>>> Do you mean others?
>>>>> 
>>>>> Thanks,
>>>>> Omair
>>>>> 
>>>>> --
>>>>> PGP Key: 66484681 (http://pgp.mit.edu/)
>>>>> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681