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

[Mikael Vidstedt]

On 2014-05-28 04:44, Lois Foltan wrote:
> Hi Mikael,
>
> Looks good.  One question concerning a change in 
> nativeInst_sparc.cpp.  It seems that in most cases "0x%x" was changed 
> in favor of INTPTR_FORMAT, but in NativeMovConstRegPatching::print() 
> you did the opposite change, INTPTR_FORMAT to "0x%x".  Just curious if 
> there was a reason for that?  It would be more consistent for example, 
> with your change to NativeMoveConstReg::print(), if it was left as an 
> INTPTR_FORMAT.

In the cases where I changed INTPTR_FORMAT to 0x%x it is because the 
argument is in fact an int. While I could upcast to an intptr_t instead 
I personally think that is more confusing than it is helpful.

Cheers,
Mikael

>
> Minor - copyrights on all files need to be updated.
>
> Thanks,
> Lois
>
> On 5/27/2014 6:22 PM, Mikael Vidstedt 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
>>
>