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

[Dean Long]

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