RFR (XS): 8044071: Print format/argument warnings

[Mikael Vidstedt]

I think you're right. The only use appears to be in the unit test code 
itself. I just tried #if 0'ing out everything related to 
NativeMovRegMemPatching and it builds just fine.

I filed an RFE to cover the removal of the class: 
https://bugs.openjdk.java.net/browse/JDK-8044242

Cheers,
Mikael

On 2014-05-28 16:15, Dean Long wrote:
> NativeMovRegMemPatching might be dead code.  I can't find where it's 
> used.
>
> dl
>
> On 5/28/2014 12:48 PM, Christian Thalinger wrote:
>> This made me curious because I was expecting a cast too:
>>    void NativeMovRegMemPatching::print() {
>>      if (is_immediate()) {
>> !     tty->print_cr(INTPTR_FORMAT ": mov reg, [reg + %x]", 
>> instruction_address(), offset());
>> !     tty->print_cr(INTPTR_FORMAT ": mov reg, [reg + %d]", 
>> p2i(instruction_address()), offset());
>> Turns out that NativeMovConstRegPatching::data()  returns an int:
>>
>> int NativeMovConstRegPatching::data() const {
>> #ifdef _LP64
>>    return data64(addr_at(sethi_offset), long_at(add_offset));
>> #else
>>    return data32(long_at(sethi_offset), long_at(add_offset));
>> #endif
>> }
>>
>> but on 64-bit we truncate an intptr_t:
>>
>>    static intptr_t data64( address pc, int arith_insn ) {
>>
>> That’s odd because in NativeMovRegMem we use intptr_t for offset 
>> exactly because of the non-immediate case.
>>
>> On May 27, 2014, at 3:22 PM, Mikael Vidstedt 
>> <mikael.vidstedt at oracle.com> wrote:
>>
>>> Please review the below change which addresses a number of print 
>>> format/argument mismatches when compiling linux/sparc using gcc.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8044071
>>> Webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8044071/webrev.00/webrev/
>>>
>>> Most of these are straightforward changes to INTPTR_FORMAT & adding 
>>> p2i. A couple of changes worth bringing up:
>>>
>>> * nativeInst_sparc.cpp
>>>
>>> I changed the format of the offset in mov related prints (two 
>>> occurrences) to %d, since it's really a signed decimal int. This 
>>> will hopefully reduce confusion when the offset is negative, where 
>>> previously it would have looked like a relatively large positive 
>>> offset.
>>>
>>> * macroAssembler_sparc.cpp
>>>
>>> The new code is in line with other similar patterns in the same 
>>> file, but the ugly cast should IMHO really be rewritten to cast 
>>> through a union. RFE?
>>>
>>> Cheers,
>>> Mikael
>>>
>